Et Tu Java ?

Vi blev lovet at Java var en helt sikker og vandtæt sandkasse til at køre fremmed og sågar fjendtlig kode på vores computere.

Det var der nogen der troede på og nogen der ikke troede på.

Nu har det igen vist sig at det var "de kedelige" der havde ret, men det var sikkert en fin fin fest mens den varede og de seneste fire fem år er Java stort set det eneste sprog vi har uddannet folk I at bruge på vores uddannelser.

Forstå mig ret, der er ikke noget væsentligt i vejen med Java, men lige så lidt som primtal udregnet i syvtalssystemet afslører guds store plan, løser Java sikkerhedsproblematikken vedrørende udførsel af fremmed kode.

Dem der kan deres klassikere vil vide at at det er over 50 år siden det blev matematisk bevist at vi ikke engang kan afgøre om et vilkårligt program nogen sinde stopper og gennemskue om det er igang med at stjæle vores information er på ingen måde nemmere.

Af fulde børn og paranoide diktaturstater skal man høre sandheden nogen gange: Både Israel, Kina og Rusland har lavet deres egne private operativsystemer for at have bare en lille smule styr på hvad der lækker og hvor det lækker hen. Mit gæt er at disse har andre, men ikke færre, kodefejl end deres forbilleder, men i det mindste kan de prale af at "det er vores egne nationale sikkerhedsfejl."

Groft sagt, har vi som samfund og som individer to muligheder nu.

Enten kan vi læse Kernighans epistel og fraskrive os enhver form for computer vi ikke selv har bygget af sand fra egen grav og programmeret på hjemmelavet bøttepapir og være glade for at den kan regne primtal ud.

Eller vi kan indse at man ikke kan stjæle information som ikke er hemmelig og opgive stort set alt hvad vi troede vi havde af elektronisk privatliv.

Og hvis vi nu skal være ærlige, så har det institutionelle behov for at fremstå handlekraftigt imod en abstrakt og opblæst terrortrussel frataget os mulighed nummer 1 for længst.

Kampen om privatlivets fred er med andre ord tabt på forhånd.

Vi kan godt blive ved med at kæmpe den, bit for bit og oplysning for oplysning, men den er tabt i en verden hvor organisationer kan miste kontrollen med dybt konfidentielle informationer i bundte er af millioner individer, uden overhovedet at gøre sig umage, hverken den ene eller den anden vej.

Jeg vil godt vædde på, at inden for de næste 10-20 år dukker mindst et offentligt register med næsten alle danskere op på en FTP server et sted i Elbonien, chancerne for at de "hemmelige" overførsler imellem CSC, Kommunedata og offentlige myndigheder taber en kopi undervejs er simpelthen ikke i nærheden af nul og chancen for at en eller anden tilfældig IT-mand i langtbortistan ikke kan bestikkes er helt sikkert lig nul.

Længe inden den skæbnedag bør vi som danskere have gjort os nogle overvejelser om hvordan vi vil håndtere det.

Det kaldes "at have en beredskabsplan" og det er til tider på mode.

Men hvad kan vi skrive i den beredskabsplan ?

"Hvis CPR registeret offentliggøres på en FTP server ude i verden gør vi..."

...hvad ?

Er vi ikke nået dertil, hvor det eneste vi kan gøre er at tage Niels Bohrs gode råd og sørge for at alle, ikke kun "the bad guys" har adgang til informationerne ?

Burde vi bare åbne alle de offentlige registre og i stedet gøre forskelsbehandling på usagligt grundlag til en forbrydelse der straffes meget hårdt ?

phk

Kommentarer (38)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Torben Mogensen Blogger

I sin allerførste implementering var Java rimelig sikker. Men så ville programmørerne bruge Java til mere og mere, som det ikke oprindeligt var tiltænkt, og så blev der læsset masser af ekstra muligheder for i/o, reflection osv. på sproget. Og med det forsvandt sikkerheden.

Morale: Sikkerhed handler om det, man ikke kan gøre, og ikke om det, man kan gøre.

Men jeg er enig i din hovedpointe: Informationer, der er teoretisk set tilgængelige bør være nemt tilgængelige. Ellers får man en illusion om sikkerhed og desuden en ulighed mellem dem, der har viden eller ressourcer til at finde informationen og dem, der ikke har. De sidste ender ofte som ofre.

Thue Kristensen

primtal udregnet i syvtalssystemet

Lidt off-topic, men primtal er fuldstændigt uafhængigt af hvilken talbase man bruger. Så den talemåde giver ingen mening.

Hvis der så bare var en fast vending så kunne man argumentere for at bruge den, men der er præcist et hit på google på den sætning (denne side). Så du har tilsyneladende lige opfundet den.

Martin Kofoed

Uanset bagvedliggende teknologi (flash, java, activex, etc.), er browser-plugins til afvikling af kode bare en dårlig idé til at begynde med. Det er højprofils-angrebsvektorer, der ofte ikke holdes opdateret, selv om der skulle komme patches ud i tide ... Java på serversiden er jo uanfægtet af disse bugs.

Virtuelle maskiner i browseren må og skal væk.

Og ja, alle CPR-numre skal være offentlige ligesom det oprindeligt var tiltænkt. Engang kunne man sågar rekvirere kirkebøger med alle danskeres CPR-numre. Det var jo bare et ID ...

Thue Kristensen

Jeg ved at de arbejde med automatiseret matematisk program-validering på ITU. DVS at man kan opstille udsagnet "kommer aldrig ud af sandboksen" matematisk, så opstille et bevis for udsagnet matematisk, og så sætte en computer til at validere beviset.

Sidst jeg hørte noget, så havde de bevist at en garbage collector var korrekt.

Så det faktisk tænkeligt at man kan komme dertil at vi kan bevise med 100% sikkerhed at et en java-sandbox ikke indeholder sikkerhedshuller.

Poul-Henning Kamp Blogger
Torben Mogensen Blogger

Virtuelle maskiner i browseren må og skal væk.

Nej. Alternativet vil være, at man bliver bed om at downloade et program og køre det på ens maskine, hvilket typisk betyder med alle rettigheder. Derfor er virtuelle maskiner i browseren en særdeles god ide.

Men de skal laves ordentligt, så programmer i den virtuelle maskine ikke har adgang til andet end meget begrænsede ressourcer fra maskinen. Med en bytekodefortolker er det ikke svært at arrangere. Det er lidt sværere med native code, men Google's Native Client (NaCl) er godt på vej med en løsning. Det er først, når man giver programmer i den virtuelle maskine adgang til ressourcer, det ikke selv har oprettet, at man får problemer.

Det sætter selvfølgelig nogle begrænsninger for, hvad man kan gøre med programmer i ens browser, men det er en lille pris at betale for sikkerheden, når alternativet er at downloade og køre programmer, der har alle brugerens rettigheder.

Baldur Norddahl

Java blev designet til at være sikker og mig bekendt er der kun fundet meget få fejl som relaterer til design af den virtuelle maskine og byte code. Reflektion med mere har ikke ændret dette.

Problemet er at Java ikke er skrevet i Java. Man kan sige naturligvis er der nogle elementer som selve JVM'en der ikke kan være skrevet i Java. Men det stopper ikke her, der er titusinder af "native" API kald i Javas standardbibliotek. Langt de fleste kunne sagtens være skrevet i Java. I stedet valgte Sun at skrive det meste af standardbiblioteket i C.

De mange sikkerhedsfejl stammer herfra. Sikkerhedsmodellen kan ikke gøre så meget ved at et eller andet obskurt C bibliotek ikke validerer input korrekt. Der er for meget kode der køres udenfor sandkassen.

Efterhånden som Java har udviklet sig har man boltet flere og flere C-biblioteker på. I stedet for at implementere egne krypteringsfunktioner, så er det så meget nemmere bare at linke til et eksisterende C-bibliotek. Problemet er at man så arver alle sikkerhedsbristerne herfra, foruden de ekstra man får lavet i grænselaget til Java.

Jeg ser en løsning i Googles Native Client projekt http://code.google.com/p/nativeclient/

Ideen er ikke ny som sådan. Lad oversætteren vedlægge maskincheckbare beviser for at koden overholder spillereglerne. Verificer koden og beviset før den køres. Herefter kan selv C-kode køres på en sikker måde.

Man kan sammenligne det med operativsystemets indbyggede process separation. Forskellen er bare at her kan man gøre det meget mere fingranuleret. Programmet behøver ikke længere stole på bibliotekerne og omvendt. Et projekt som Javas JVM kunne f.eks. linke til kryptobiblioteker og få en garanti for at disse ikke laver utilsigtede OS kald eller tilgår hukommelse udenfor bibliotekets eget arbejdsområde.

I det omfang man kan opfatte Native Client som en sandkasse, kan man sige at Java vil kunne køre krypto-biblioteket indenfor sandkassen, selvom biblioteket er skrevet i C.

Det løser ikke alt men vil være et kæmpe fremskridt.

Torben Mogensen Blogger

Jep, det er også den slags ting jeg ville forske i, hvis jeg bare skulle være sikker på at få en løn-check indtil pensionsalderen :-)

Hvis det drejede sig om bevis for korrekthed i forhold til en given specifikation, ville jeg være enig. Men hvis det blot er validering af nogle enkle egenskaber, kan man sagtens gøre det. Det sker f.eks. i stort set alle oversættere, der bruger typecheck, registerallokering, fælles deludtrykeliminering osv. Man vil komme til at invalidere flere programmer end nødvendigt, men så længe de programmer, der slipper igennem filtret, er i orden, er det et mindre problem.

At vise korrekthed af garbage collection lyder som lidt mere ambitiøst end det, der er nødvendigt for sandboxing. Her skal man nok mere se på Googles NaCl, der har meget strenge regler for indholdet af maskinkodeprogrammer. F.eks. skal alle adresser valideres, inden de bruges. Hvis den foreskrevne valideringskode ikke findes, godkendes programmet ikke. Tilsvarende godkender analysatoren kun et meget lille antal systemkald.

Torben Mogensen Blogger

Samtidig løser man vel også cirklens kvadratur?

Hvis man ønsker med sikkerhed at kunne skelne sikre fra usikre programmer, er problemet ganske rigtigt lige så uløseligt som cirklens kvadratur. Men hvis man får lov til at afvise alle programmer, hvor man ikke kan afgøre, om de er sikre eller ej, så er det ikke spor uløseligt. Og hvis barren for sikkerhedsgodkendelse er sat højt nok, er det ingengang svært. Kunsten er at sætte barren tilpas lavt til, at man også kan slippe interessante og brugbare programmer igennem.

Morten Fordsmand

Og ja, alle CPR-numre skal være offentlige ligesom det oprindeligt var tiltænkt. Engang kunne man sågar rekvirere kirkebøger med alle danskeres CPR-numre. Det var jo bare et ID ...


Og ikke så meget om hvor vidt vi kan lave sikre klienter til slutbrugerne.

Problemet er bare at hvis alt hvad der skal til for at stjæle min identitet er kendskab til mit CPR-nummer, så er det meget uheldigt med det Elboniske datasæt, lige som en offentlig oplistning af min kontonumre i banken også ville gøre mig ret sårbar.

Så jeg vil give PH ret, det er vigtigere at kunne håndtere konsekvensen så tabet bliver tåleligt, frem for at forlade sin tro på at man kan forhindre tab af konfidientalitet.
Dermed dog ikke sagt at jeg har tænkt mig at offentliggøre mine data.

Baldur Norddahl

Hvis man ønsker med sikkerhed at kunne skelne sikre fra usikre programmer, er problemet ganske rigtigt lige så uløseligt som cirklens kvadratur.

Hvis man har lov til at modificere programmet er det ikke så svært. Man kan bare indsætte checks alle steder hvor der er tvivl. Eller man kan kræve at oversætteren har gjort det på forhånd.

Systemer som Native Client er stadig Turing komplette.

Poul-Henning Kamp Blogger

Dermed dog ikke sagt at jeg har tænkt mig at offentliggøre mine data.

Og det er sådan set balladen, er det ikke ?

Rent statistisk er det kun et spørgsmål om hvornår det sker pga. uheld, inkompetence eller kriminalitet.

At smide sølvtøjet ud er en høj pris at betale for at skuffe tyven, men hvis man ved at man ikke kan beskytte det imod tyveri, er det så ikke bedre på forhånd at overveje hvad metallet ellers kunne bruges til ?

Morten Fordsmand

Rent statistisk er det kun et spørgsmål om hvornår det sker pga. uheld, inkompetence eller kriminalitet.

At smide sølvtøjet ud er en høj pris at betale for at skuffe tyven, men hvis man ved at man ikke kan beskytte det imod tyveri, er det så ikke bedre på forhånd at overveje hvad metallet ellers kunne bruges til ?

Måske skulle vi se det lidt mere nuanceret og der er din sølvtøjsanalogi jo god:
- Man kan gemme det i en bankboks - relativt sikkert, men dyrt og bøvlet hvis det skal bruges.
- Man kan gøre sit hus bøvlet at bryde ind i.
- Man kan være forsikret

Bemærk at forsikringen ikke udelukker de to andre mitigeringer.

Martin Kofoed

Nej. Alternativet vil være, at man bliver bed om at downloade et program og køre det på ens maskine, hvilket typisk betyder med alle rettigheder.

Det afhænger vel af use casen? I tilfældet NemID vil alternativet vel være at implementere det i en model, der kan afvikles i en browser uden plugins? Jeg har heller aldrig kunnet finde et helt klart svar på, hvorfor en statslig authentication-løsning nødvendigvis må indebære brug af en Java Applet.

Tilsvarende ville man sikkert kunne luge ud i mange andre plugin-afhængige løsninger derude, hvis man virkelig ville.

Poul-Henning Kamp Blogger

Dårlige analogier osv...

Du har allerede deponeret dit "privacy" sølvtøj i en bankboks, men du har ingen indflydelse på hvor godt de passer på det og jeg har ikke hørt men nogen forskringer der kommer i nærheden af at dække den skade som f.eks offentliggørelse af CPR registeret ville medføre.

Så lad os lige lægge similierne tilbage i skuffen og tage sagens kerne:

Hvad skriver den statslige CIO i sin beredskabsplan, for "CPR registeret lækket på Internettet" ?

Morten Fordsmand

Hvad skriver den statslige CIO i sin beredskabsplan, for "CPR registeret lækket på Internettet" ?


Måske er det her vi har fejlen at lade det være op til CIO'en, når det burde være CEO eller CBO'ens problem.
Forretningsberedskab er for vigtigt en ting til at overlade til teknologerne.

I øvrigt ville en ordentlig analyse af den mulige hændelse, nok føre til en revurdering af det "hemmelige" CPR-nummer.

Er der i øvrigt nogen der kender historien bag ved at CPR-nummeret skulle være hemmeligt?

Martin Juhl Jørgensen

"Hvis CPR registeret offentliggøres på en FTP server ude i verden gør vi..."

Min første indskydelse ville være at bygge en bro, men

Er vi ikke nået dertil, hvor det eneste vi kan gøre er at tage Niels Bohrs gode råd og sørge for at alle, ikke kun "the bad guys" har adgang til informationerne ?

Burde vi bare åbne alle de offentlige registre og i stedet gøre forskelsbehandling på usagligt grundlag til en forbrydelse der straffes meget hårdt?

lyder temmelig godt i mine ører. Det ville i så fald klare nogle "gråzoner" hvor f.eks. en virksomhed ejer data om brugerne fra, lad os bare sige, kommunerne. Derudover kunne man så håbe på at der udover horderne af Spamware(tm) andre mere dystre softwarepakker også ville dukke nogle gavnlige softwarepakker op. Man vil helt sikkert se nogle sammenhænge man ikke har set før hvis man fik lov til at kigge alle registrene igennem på engang, det må da føre til lidt innovation.

Mads Vanggaard

For at kunne komme frem til en seriøs beredskabsplan må vi blive enige om scope af impactet.

Mit gæt på hvad den statslige CIO skriver:
1) Banker mv. kan hurtigt skifte over til at kræve pas eller kørekort ved tilgang til penge ved skranken, ændringer, ...
2) nemID kan slå CPR som bruger id fra og kræve at man skal få sin adgang på kommunen og man skal vise pas
3) posten kan kræve nemID for at ændre postadressen
4) helbredskort eller andre sociale henvendelser til kommunen, politiet, mv. kan kræve pas - online: nemID
5) tast selv koden fra SKAT nedlægges
6) PAS - dåbsattest, kørekort, forældre skal have pas til alle børn så de fleste vil have det fra starten. Man kan bruge sit nemID til at identificere sig som et ekstra check. Hvis man mister alt (inkl. sit nemID kort) f.eks. ved en brand, så må man få vidneerklæring fra familie og hvis disse ikke eksisterer så to-fire personer som alle har en relation til personen. Hvis alt alt fejler, så kan jeg ikke se hvordan man kan få en identitet.

Hvad ellers? Hvad mere er i scope? Man kan mene hvad man vil om nemID - det er ikke en had debat om dette som skal foregå her

Per Michael Jensen

Jeg har heller aldrig kunnet finde et helt klart svar på, hvorfor en statslig authentication-løsning nødvendigvis må indebære brug af en Java Applet.


Det er for at du ikke skal påstå, at der er transaktioner, du ikke har lavet. NemID har et fingerprint (CPU_ID osv.) og kan med det vise, at transaktionen er sket fra din PC.
Og så kan du jo spekulere på, hvor det placerer den almindelige bruger (dig selv) i hierakiet af sikkerhedsrisici hos NemID.

Poul-Henning Kamp Blogger

Både ja og nej.

I vores nuværende samfund vil viden om hvad der står om dig i CPR registeret være rigeligt til et utroligt effektivt identitetstyveri, op til og med at lave en addresseændring, få et nyt nemid kort og sælge dit hus mens du bor i det.

Men hvordan er situationen hvis alle ved hvad der står i CPR registeret om alle danskere ?

Hvad vinder vi og hvad taber vi, hvis det sker ?

Nicolas Guilbert Blogger

Man kommer nok desværre/heldigvis aldrig uden om, at vi grundlæggende er afhængige af sund fornuft.

Nede i banken, hos advokaten, på kommunekontoret, hos Skat osv. er de nødt til at kunne håndtere, at der også findes uhæderlige mennesker...

Intet nyt under solen, Grundtvigs folkelige oplysning er stadig en forudsætning.

Mads Vanggaard

Ja, jeg kender udemærket hvad der står i CPR registeret om mig. En gang imellem kan man blive overrasket over hvem følger en. Anyway, staten DK kan godt overleve at folk og firmaer ved at jeg er gift, hvem mine forældre er og så videre. Sålænge at de ikke kan lave ændringer, bruge disse informationer til at udgive sig for mig, så er det ikke mega vigtigt at informationerne er hemmelige. Det var derfor, at jeg listede policy ændringer til de typiske steder jeg vil forvente at informationerne vil blive forsøget misbrugt. Nøglen til at overleve offentliggørelsen af CPR registeret er at informationerne ikke kan bruges som identitet - planen skal adressere dette aspekt som hovedpunkt.

Jonas Høgh

Som sådan er det vel helt underordnet, hvad der står i CPR-registret. Som tingenes tilstand er i dag, ville det være problematisk i sig selv, alene hvis selve listen med CPR-numre blev offentliggjort. Man kommer jo rystende langt som identitetstyv blot ved at ringe til virksomheder og myndigheder, og oplyse dette.

Og lister med CPR-numre ligger jo og flyder i tusindvis af dårligt sikrede systemer hos diverse firmaer, der "lige skal have CPR-nummer", før man kan blive kunde.

Thomas Hansen

100 % sikker bliver vi aldrig med IT. Men dermed ikke sagt vi ikke kan finde nogle andre løsninger i forhold til at gøre vores liv lidt mere sikkert i forhold til IT.
( Men det kræver en anden holdning til IT )

PS. Så er det heller ikke så svært at lave en liste med gyldige CPR. nr. Det kræver ikke mere end 10-15 koder c++.

Gert Madsen

Man kommer nok desværre/heldigvis aldrig uden om, at vi grundlæggende er afhængige af sund fornuft.

Problemet er at information og viden er grundlaget for "sund fornuft".

Når ting bliver digitaliseret, så er det lykkedes os som IT-folk, eller måske mest sælgerne, at gøre det hele mystisk.

De fleste kan forstå at det ikke er en god ide at have samme nøgle til hoved-døren, cyklen, postkassen, pengeskabet og bankboxen.
Men når det bliver digitalt, så forsvinder den erkendelse (Hint: NemID).

Tilsvarende kan man godt forstå at det ikke er nogen god ide at have 100 kopier af sin nøgle liggende rundt omkring hos bekendte og forskellige firmaer. Men når det bliver digitalt/virtuelt, så er den forståelse væk.
Alle ved at man kan tømme en mands bankkonto med en telefon, og et CPRnr. Alligevel insisterer alle mulige på at registrere CPRnr. på deres kunder/kontakter.

Så selvfølgeligt vil det ske at følsomme oplysninger forsvinder, og der er behov for en beredskabsplan.
Men man kunne mindske risikoen, og begrænse følgerne, hvis IT branchen undlod at mystificere tingene, og dermed bortdømme sund fornuft.
Desværre vil det jo nok betyde farvel til meget af den dejlig hurtige profit ;-)

Henning Wangerin

De fleste kan forstå at det ikke er en god ide at have samme nøgle til hoved-døren, cyklen, postkassen, pengeskabet og bankboxen.
Men når det bliver digitalt, så forsvinder den erkendelse (Hint: NemID).

NemID er potentielt et problem, da du ikke har en fysisk enhed som giver dig adgang.

Jeg benyttet selv en pki-nøgle som giver mig adgang til en masse maskiner rundt omkring.

At disse maskiner kan lukkes op men min nøgle (uanset om det er mig der har den i hånden eller ej) er en ting, men det giver ikke indenhaveren af den pågældende maskine adgang til at kunne udgive sig som mig.

En fysisk ruko-nøgle kan let kopieres, men kan en pki-nøgle ikke bare lige.
Jeg ved godt at det teoretisk er muligt, men i praksis har jeg ikke læst om muligheder for at knække en lang rsa-nøgle.

Gert Madsen

En fysisk ruko-nøgle kan let kopieres, men kan en pki-nøgle ikke bare lige.

Det man sender når der bruges NemID, er jo ikke en PKI-nøgle. Man indtaster bare Password, og pap-kode. Og man skal stadig stole på at den PKI-nøgle, som hentes fra DanID ikke bruges til at sælge ens hus for en krone.

Så det gælder også her, at jo flere steder en sådan nøgle kan bruges (og bliver brugt), jo større risiko for misbrug.

Henning Wangerin

Det man sender når der bruges NemID, er jo ikke en PKI-nøgle. Man indtaster bare Password, og pap-kode. Og man skal stadig stole på at den PKI-nøgle, som hentes fra DanID ikke bruges til at sælge ens hus for en krone.

Enig.

Om nøgle fysisk genereres på min maskine i java-appletten eller hos danid, er også ligegyldig.

Min beskrivelse var måsek uklar. Min pki-nøgle som jeg bruger til adgangen til diverse maskiner ligger på et pki-smartcard, og kan ikke udlæses fra kortet.

Den nøgle kan jeg ikke se at der er problemer med, at den offentlige nøgle ligge mange steder ude i verden. Selvom du havde min offentlige nøgle kan du ikke bruge den til at skafft dig adgang til andre maskiner.

Min sammenligning men ruko-nøglen gik på at hvis du har en cylinger som min nøgle passer i, kan du lave en kobi af min nøgle, og dermed bruge den i de andre døre hvor den også passer.

Det er ikke muligt med en nøgle på et pkismartcard.

Sådan en nøgle har jeg tillid til. Ikke en engangs-pki-nøgle som nemid

Log ind eller Opret konto for at kommentere