Ja, de vil skjule at de indsamler data, der delvist identificerer din computer. De gør sig bare ikke særlig umage.
I Mac OS X udgaver er der ihvertfald både en cAES256, SHA256 og en HMAC_SHA256, så det er nok rigtigt (lærte lige otool og otx dér)
Det tyder på at appletten derved indsamler data, der potentielt ville kunne knytte brugen af NemID til en bestemt maskine - det kunne jo gode ekstra indicier hvis eller hvis en tvist opstår om hvem, der har underskrevet hvad hvornår.
Til dem, der ikke kender begrebet: Dette er præcis problemet ved security by obscurity:
Man forsøger at skjule noget som ikke er sikkert. Den manglende sikkerhed er jo at nøglen ikke er i brugerens lomme. Tiltag som det skjulte DLL/so/dylib, som bryder ud af Java-sandkassen gør det muligt at gå efter alle amatørerne med indicier.
En rigtig angriber vil selvfølgelig kombinere anvendelsen af et TOR netværk med en passende virtuel afvikling af appletten, hvis han ikke blot bruger et kompromitteret JVM. Det ville være dumt at antage at en alvorlig angriber vidste mindre om sikkerhed og disassemblering end et par emsige Version2-læsere.
Den skjulte DLL er selvfølgelig den eneste reelle grund til overhovedet at have en applet, som jo ville være er unødvendig i det rene NemID tilfælde (men nødvendig med den gamle signatur).
Det mest fristende er vel at se hvad de native kald i Wuddlecakes gør, men det er nok krypteret på det niveau også:
final class dk.danid.plugins.Wuddelcakes { static native java.lang.String d(java.lang.String); static native java.lang.String c(java.lang.String); static native java.lang.String a(java.lang.String); static native java.lang.String f(java.lang.String); static native java.lang.String e(java.lang.String); dk.danid.plugins.Wuddelcakes(); }
Mon ikke det er et JNI DLL til KeyStore-provider understøttelse af "My Certificate Store" (via CryptoAPI), nødvendigt for at understøtte OCES certifikater, svarende til MicrosoftCryptoApiXXX.dll i OpenOCES?
Bare forklædt som GIF, for at snøre de simpleste scannere, velsagtens, fordi et DLL ser suspekt ud.
Kunne man snart få lov at se kildekoden til NemID, eller bliver den tvivlsomme sikkerhed derved for åbenlys?
Nogen, der kalder sig det navn, kommenterede angiveligt om emnet i oktober:
http://fos.au.dk/archives/491#comment-3202
Og "Who would claim to be that who was not? Hmm?" (The Untouchables, 1987)
Nu er der ikke ret meget kommunikation ud af et TV; om PHK ser Opera på DR2 eller naturfilm fra kanalkøbenhavn er vist det højeste, der kan spioneres på.
Nu kan man jo få fjernsyn med netadgang og sådan for få tusind kroner, og jeg skal love dig for at detaljeret profilering af netop TV-vaner er MANGE penge værd for dem som fordeler reklamekronerne. Steganografi + netadgang + data om fjernsynsvaner opsamlet for millioner af kunder. Scary.
Og når vi først er dér, hvorfor så ikke personalisere reklameblokkene?
Hov, det findes jo allerede - Google TV?
men derudover betragter jeg Nokia som uden relevans i markedet
Meeen, samtidig er du jo heller ikke tilfreds med markedets resultater, og undersøger jo netop muligheder, der p.t. ligger udenfor. :-)
Hvis vi kan lære noget at udviklingen inden for x86 PC platformens historie så er det at den blev drevet af hardware- og softwareudvikling i tandem - konkurrencen skaffer biligere/hurtigere hardware, software kræver standardisering - men det kræver modenhed, og ikke den type fragmentering som har været betegnende for Android (og glem Apple).
Det burde være Qualcomm, Foxconn, ARM, AMD og Intel og andre af den slags, der trykkede på for en standardisering af systeminterfaces, så de kunne normalisere konkurrencen og vi kunne få e.eks. et "Linux vs. FreeBSD vs. Windows Mobile (vs. iOS)" valg diskurs omkring mobilhardware (hvor åbenhed, features og pris var reelle konkurrenceparametre), og ikke en "Windows Mobile (med Nokia patches) vs. Android'ish (med Samsung patches)'ish vs. Android (med HTC patches)", etc.
Spørgsmålet er bare om vi nogensinde når derhen -- indtil da er det op til hver enkel at afveje risiko imod nytte.
... men er født som et templatesprog for når man arbejder med DSL'er og kodegenerering ud fra dette.
Inde i Xtend ligger Xbase sproget som er hvor alle de nævnte konstruktioner egentlig hører hjemme, og det fikse er så at man kan bruge disse sprogkonstruktioner i "egne" DSL'er, som det f.eks. kan ses her:
http://www.eclipse.org/Xtext/documentation/2_1_0/035-domainmodel-java.php
Bonussen er så at man tilmed får genereret et fuldt udviklingsmiljø (highligting, code completion, fejlmarkeringer, etc) til det udviklede DSL! Det er meget, meget smart, men en Java-killer er det altså ikke meningen, det skal være (dem er IMYM der nok af)
Jeg læste Lars F. Nielsens kommentar således at han forventede at Drupal-folkene ville hive OS (og Drupal) positive historier frem, ligesom det turde være indlysende at SiteCore ikke ville lægge en rapport ud om "Bedrager COTS skinnet?" (for at blive i symbolsproget).
Kildekritik!
@Henrik: Helt enig i at man skal kunne have en saglig debat, på et eller andet fornuftigt grundlag, men jeg tror bare ikke at den kan forventes at starte på en af leverandørernes præmisser. Nogle communities tiltrækker den slags debatter bedre end andre, og jeg vil vove den påstand at OS-fora i deres natur er mere åbne for saglig debat, afhængig af "tonen". Nogle OS-communities er ekstremt "favnende" (f.eks. Eclipse), hvor folk kun meget sjældent bliver sure på hinanden. Der kan man godt have en debat med folk der gør tingene anderledes, alene fordi der under Eclipse-paraplyen er en del "konkurrerende" projekter, og på grund af den meget høflige kultur, som smitter. Andre OS-projekter/communities har andre omgangsformer (ingen nævnt/glemt). Det er lidt sværere med de rene CS-projekter, deres communities er jo typisk kun for kunder, selvom de er uafhængige af leverandøren. Endelig er der diverse analysefirmaer (altså rigtige, ikke Gartner og den slags/sponsordrevne), f.eks. RealStory (tidl. CMS Watch), som tilsyneladende kender og følger produkterne og har diverse diskussionsfora. Men det koster.
Lad os give anecdotal evidence deres 'props': http://www.smbc-comics.com/index.php?db=comics&id=2159:-)
Jeg må indrømme at jeg finder det svært at tage rapporten seriøst medmindre jeg anskuer den som ren marketing.
Ingen (ej heller SiteCore, læs ovenfor) forventer at du anskuer den som andet end marketing.
... og udøves forskelligt alt efter om afsenderen er en salgs/markedsføringsafdeling i en virksomhed, der sælger software (den slags er jo glade for whitepapers, husk bare på den gang Version2s distribuerede sponsorerede whitepapers), eller et OpenSource projekt (som jo gerne fremviser referencer - og markante personlige holdninger).
Forskellige budgetter, forskelligt publikum, forskellig form. De beslutningstagere, der kun lytter til én leverandør og antager at den er objektiv, får den beslutning de fortjener. De fleste fagfolk kan jo berette om de nævnte faldgruber fra mange kanter, så lyt til dem også.
Tankevækkende, at Drupal kommer nemmere i medierne ved at råbe "FUD" end ved at skrive en casebeskrivelse, á la SiteCores whitepaper (målt i indsats). Al omtale er god omtale!
Øvrigt nyt: Jorden er stadig flad.
Men mon ikke det er et spørgsmål om tid før vi ser Dart på Dalvik (eller en Dart VM, der kan kodes direkte imod Android APIerne), så Google kan slippe for Java i andet udviklingsmiljøerne.
Dart er jo netop så lig Java OG JavaScript at den ville kunne erstatte begge.
Men blev de successfulde projekter blev gennemført på under ét år fra kravspec til udrulning?
... inden jul.
Den eneste løsning, der kan komme i gang inden for den tidsramme er at udbrede et system som fungerer i en region i forvejen. Og for guds skyld udrulle det i etaper, en region ad gangen, og ikke tro på big bang.
... er at der er så mange led i NemID sikkerheden:
- Postbudet
- Din postkasse
- DNS servere
- Dit nøglekort
- Din adgangskode
- CA'ers certifikatudstedelsespraksis
- Din browsers sikkerhedshuller
- Din Java versions sikkerhedshuller
- Din evne til at skelne phishingsites fra rigtige sites
- Ordlyd i bankers og det offentliges mails
Bryder ét (eller i visse sammenhænge to) af de ovennævnte led er det nok til at eksponere dig som bruger, eller den udnyttede serviceudbyder i den anden ende. At tro du kan sikre alle disse led, for alle brugere, altid er utopi.
M.a.o. er det svageste led at der ikke er end-to-end kryptering og signering i spil ved den type transaktioner. Dette kræver noget stærkere end OTP, og udelukker offentlige terminaler, og kræver trusted hardware hos klienten. Alt andet er afhængig af softwareløsninger som jo kan kompromitteres.
(Og det er så hér vi må indrømme at vi savner Stephan Engbergs tydelighed i dette spørgsmål)
I mellemtiden har vi disse mindre sikre løsninger, men de er stadig bedre for samfundet end personligt fremmøde (hvor banken står klar med en håndskriftekspert). Indtil videre.
Hver gang nogen installerer Windows på en Mac er der en enhjørning, der dør!
(Skal siges med glimt i øjet)
Smily eller ej -- udskiftning af certifikater bør være en opgave for driften, og kun driften, specielt når det er noget så banalt som webservercertifikater. De har altså være med os siden 1996, de burde ikke komme som en overraskelse.
Driften bør for dette ansvar til gengæld kræve at systemerne dokumenterer certifikaters placeringer, og helst også at de er rimelig nemme at udskifte og ikke kræver nedetid. Det kan være tricky ved klientcertifikater (fordi de kan være genkendt på forskellige nøgler i subject, eller i SAML metadata) men dog heller ikke nogen uoverskuelig opgave.
Altså i den perfekte verden...
Nitpick: SSH bruger ikke SSL, men har sin egen crypto stak, som beskrevet i RFC 4253. OpenSSH bruger OpenSSL biblioteket til sin crypto implementering, men det er et rent implementationsvalg.
Hashkollision som sikkerhedsbrist ligger vel tæt nok op ad signerings- og krypteringsemnet til at godtgøre dette - med mindre der er et emneord for envejsfunktioner...
Jesper S. Møller