Lavabit email, zero knowledge encryption?

[gtr]

Er der en med det fornødne kendskab, som kan verificere, det som jeg skriver?

Jeg har læst, hvad jeg har kunne finde om lavabit email.
Lavabit email skrev på deres hjemmeside, at indholdet på en brugers betalte konto, var zero encrypted.
Dvs kun den, der har kodeordet, kan se indholdet af kontoen.
Lavabit skrev, at metadata ikke var zero knowledge, og at lavabit på legalt krav fra myndigheder,
ville udlevere metadata, og brugerid, sidstnævnte oplyses til lavabit via modtagne betalinger.
Det formodes at Snowden havde en lavabitkonto. Us myndigheder krævede at se også indholdet af Snowden's konto.
Lavabit oplyste, at kontoindholdet var zero knowledge encrypted, og ikke kunne overdrages. Alle andre oplysninger omkring
Snowden's konto kunne, og ville blive overdraget til myndighederne.
Us myndighederne krævede herefter, at lavabit udleverede deres ssl-nøgler og certifikater. Med ssl-nøglerne ville us myndighederne
blive i stand til at dekryptere alle lavabit brugeres datastrøm mellem lavabit og brugernes computere.
Dvs us myndighederne ville blive i stand til at opfange kodeordet for en bruger, når denne logger ind på hans konto.
Lavabit nægtede at udlevere ssl-nøglerne. Vistnok ikke fordi lavabit ikke ville give myndighederne en mulighed for at
opnå adgang til Snowden's konto. Men fordi en overdragelse af nøglerne ville betyde, at myndighederne ville få kodeordet
til enhver konto, hvor brugeren havde logget sig ind på dennes konto.
På baggrund af en domstolsafgørelse så lavabit sig nødsaget til at overdrage ssl-nøglerne til myndighederne, men lukkede samtidigt
lavabit. Sandsynligvis ved at slukke serverne, eller afbryde internetforbindelsen.
Dvs us myndighederne fik ssl-nøglerne, men kan ikke bruge dem til noget.

På trods af oplysninger fra medierne om, at ssl-nøglesystemet er kompromiteret, forudsættes det, at ssl-nøglernes funktion er
sikker. Det underbygges af, at us myndighederne krævede ssl-nøglerne fra lavabit. Og det synes, at us myndighederne
ikke er i stand til at dekryptere indholdet af lavabit konti.

Konklusion.

Lavabit systemet er ikke zero knowledge, fordi enhver, der har ssl-nøglerne, kan anvende dem til at opfange en brugers
kodeord, når denne logger ind på hans konto. Indholdet af brugernes lavabitkonti forblev kun sikret, fordi lavabit
besluttede at stoppe systemet, da ssl-nøglerne blev overdraget.
Egentlig kunne lavabit, hvis de ville, til enhver tid bruge ssl-nøglerne til at begynde at opfange brugernes kodeord. Det
samme gælder for enhver, som lavabit måtte overdrage dem til.

Hvis det jeg skriver er korrekt, betyder det, at problemstillingen er generel for alle systemer, hvor der med kodeord
logges på et system, og hvor det er et mål, at brugers indhold på en konto krypteres på serverne, så kun bruger kan dekryptere det.
Disse systemer, hvor kodeordet overføres via ssl forbindelse, er ikke mere sikre, end hvordan indehaveren af ssl-nøglen,
bruger denne.

Ved systemer, hvor det er meningen, at udbyder skal kende indholdet af en brugers konto, er det ikke et problem, at
kodeordet skal overføres over en krypteret forbindelse.

Lavabit's ssl-nøgler var udstedt af godaddy. Systemet er opbygget således, at us myndigheden ikke kan få udleveret
ssl-nøglerne og certifikater fra godaddy?

Disse ssl-nøgler kan man lave dem selv? Jeg ser bort fra, at ssl-nøgler og certifikater også skal legitimere og
identificere. Spørgsmålet går på, om man der er software, hvormed man kan lave ssl-nøgler, og bruge dem på egne
systemer. Hvis man fx har en emailserver, kan man så selv lave ssl-nøgler til at bruge på den?

Et system, hvor en konto skal være zero knowledge encrypted, er kun sikkert, hvis krypteringen foregår på brugerens
computer?

Tak.

[NickyThomassen]

Er der en med det fornødne kendskab, som kan verificere, det som jeg skriver?

Dine spørgsmål er på et højt teknisk niveau, men jeg deler gerne det jeg ved

På trods af oplysninger fra medierne om, at ssl-nøglesystemet er kompromiteret, forudsættes det, at ssl-nøglernes funktion er
sikker. Det underbygges af, at us myndighederne krævede ssl-nøglerne fra lavabit. Og det synes, at us myndighederne
ikke er i stand til at dekryptere indholdet af lavabit konti.

Dette er ikke nødvendigvis korrekt, da myndighederne måske godt kan knække krypteringen. Det kunne handle om noget så simpelt, som at det er lettere at få nøglerne, end selv at knække krypteringen.

Egentlig kunne lavabit, hvis de ville, til enhver tid bruge ssl-nøglerne til at begynde at opfange brugernes kodeord. Det
samme gælder for enhver, som lavabit måtte overdrage dem til.

Det er rigtigt, men ved at bruge deres service, så stoler man alligevel på dem. De kunne fx have mailserveren på en maskine som ikke er kodet, og så sende trafikken igennem en proxyserver i udkanten af deres netværk, så modtageren tror tingende er kodet.

Det er ikke sandsynligt i det her tilfælde, men ikke desto mindre en mulighed. Derfor skal man kunne stole 100% på serviceudbydere hvis man giver dem data.

Hvis det jeg skriver er korrekt, betyder det, at problemstillingen er generel for alle systemer, hvor der med kodeord
logges på et system, og hvor det er et mål, at brugers indhold på en konto krypteres på serverne, så kun bruger kan dekryptere det.
Disse systemer, hvor kodeordet overføres via ssl forbindelse, er ikke mere sikre, end hvordan indehaveren af ssl-nøglen,
bruger denne.

Helt rigtigt.

Lavabit's ssl-nøgler var udstedt af godaddy. Systemet er opbygget således, at us myndigheden ikke kan få udleveret
ssl-nøglerne og certifikater fra godaddy?

I princippet nej, men igen, godaddy kan vel bare gemme en kopi af det udleverede certifikat, og så bruge/udlevere det? Så man skal ikke kun stole 100% på serviceudbyderen, men også godaddy, og dem som har udleveret godaddy's hovdecertifikat (eng. = root certificate) osv osv osv.

Disse ssl-nøgler kan man lave dem selv? Jeg ser bort fra, at ssl-nøgler og certifikater også skal legitimere og
identificere. Spørgsmålet går på, om man der er software, hvormed man kan lave ssl-nøgler, og bruge dem på egne
systemer. Hvis man fx har en emailserver, kan man så selv lave ssl-nøgler til at bruge på den?

OpenSSL kan sagtens lave certifikater, som kan bruges som du beskriver. Jeg bruger selv et til mit mailinterface på min hjemmeside
https://mail.aptget.dk
Prøv og besøg siden, og inspicer certifikatet.

Noget af det stærkeste OpenSSL p.t. understøtter, kan laves med følgende kommando

Kode: Vælg alt

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -nodes -days 1095

Et system, hvor en konto skal være zero knowledge encrypted, er kun sikkert, hvis krypteringen foregår på brugerens
computer?

Ikke nødvendigvis, men det kommer an på det jeg har nævnt oppe over. Hvis man kan stole 100% på serviceudbyderen, så er det sikkert nok. Problemet er som du beskriver, myndighederne kan i en række tilfælde med loven i hånden få adgang, men det gælder også private systemer, som man selv sætter op. Mange lande har skærpede love om myndigheders adgang til krypterede data.

[NickyThomassen]

Jeg har lige yderligere 3 pointer:

* Hvis du er til det, så ligger der et hav af såkaldte "def-con" videoer på Youtube. De beskæftiger sig med alt computerrelateret, og jeg kan især anbefale Moxie Marlinspikes videoer
https://www.youtube.com/watch?v=ibF36Yyeehw

Essensen i videoen er, at det meget vel kan være lettere at gå udenom kryptering når man chracker, end at bryde den.

* SSL blev officielt pensioneret i 1999 da TLSv1.0 udkom. Siden da er TLSv1.0 også blevet forældet, da den åbenbart var hullet som en si. Cirka 2/3 af webservere skønnes at understøtte SSL eller TLSv1.0 endnu. TLSv.1.1 er sikker under nogen omstændigheder, imens TLSv1.2 p.t. er den eneste krypteringsprotokol, som ikke har nogen kendte problemer der kan udnyttes i det virkelige liv. TLSv1.2's forbedringer over de foregående udgaver (se ECDHE i punkt 3) er ikke ret godt understøttet på nuværende tidspunkt; fx er der ingen mainstream stabile Linux-udgaver som tilbyder Apache og/eller OpenSSL i stabile udgaver som understøtter TLSv1.2's forbedringer (selvom Apache fx har haft understøttelse siden 2008).

* Der findes faktisk en krypteringsform som kaldes ECDHE (eng. for Elliptic Curve Diffie–Hellman [key] Exchange), som ikke opbygger den krypteret forbindelse omkring certifikatet, hvilket vil sige at det ikke længere er nok at få fat i serverens certifikat. Det er inkluderet i TLSv1.2.

Når jeg siger "understøtter forbedringerne", så handler det om, at TLSv1.2 understøtter det meste fra de forgående versioner, og så tilføjer noget nyt. I sagen med TLSv1.2, så kan man godt understøtte TLSv1.2, men ikke ECDHE og lignende krypterings suiter. I min mening en smule hjernedødt, for hvad er pointen i at fikse nogle af de tidligere fejl, og så gøre de helt store forbedringer valgfrie?

Alt i alt førte min research til, at jeg i bedste Torvalds stil gerne vil dele et stort "Fuck You" ud til dem, dem som har givet os ikke-fungerende kryptering, og til dem som siden 2008 har forhindret os i at bruge det i stabile Linux-udgaver.
http://www.youtube.com/watch?v=IVpOyKCNZYw

[gtr]

Tak for svar.

Det var heller ikke enkelt, at finde ud af opbygningen af systemet.

Ved at læse lavabit's hjemmeside fik jeg den opfattelse, at det var zero knowledge.
Men det er altså kun selve emailkontoen, der er zero knowledge.
Her gør jeg den antagelse, at softwaren virker, som lavabit oplyste på deres
hjemmeside.

På en blog var der en diskussion om lavabit's certifikater.
En mente, at når lavabit ikke gav en individuel ssl-nøgle til haver bruger,
var det iorden at tvinge lavabit til at overdrage dem, selvom alle brugeres
kodeord på den måde kunne blive opfanget.
En anden mente, det var noget vrøvl. En individuel ssl-nøgle til alle brugere,
ville blive for dyrt.
En mente, at lavabit havde valgt en fælles ssl-nøgler til alle brugere, for
at have et argument for ikke at ville overdrage ssl-nøglerne for en enkelt
bruger.

Hvis man har en open source mailserver, med zero knowledge encryption, kan man
da opbygge ssl-nøglerne således, at hver bruger selv genererer en individuel
ssl-nøgle, og brugeren alene har kontrollen over den?
Hvis det teknisk kan lade sig gøre, ville hele systemet mailserver og bruger
være zero knowledge encryption?
Men forbindelsen mellem forskellige emailudbydere ville stadig være
usikker?

Det jeg skriver, kunne måske minde lidt om https://bitmessage.org/wiki/Main_Page

"også private systemer, som man selv sætter op", skriver du. Det er
rigtigt. Men har den enkelte bruger selv kontrollen over en mailserver
eller ssl-nøgle, kan denne selv afveje, om det er at foretrække at bruge
en hammer, eller flænse ssl-nøglen.
Hvis en udbyder har rådigheden, kan dette være vanskeligt.

* Der findes faktisk en krypteringsform som
kaldes ECDHE (eng. for Elliptic Curve Diffie–Hellman [key] Exchange),
som ikke opbygger den krypteret forbindelse omkring certifikatet, hvilket vil
sige at det ikke længere er nok at få fat i serverens certifikat.
Det er inkluderet i TLSv1.2.
Dvs i tlsv1.2 har ingen kontrollen over certifikatet eller krypterings-
nøglen?

ECDHE
Jeg mener, jeg har læst en diskussion om ecdhe, hvor man mener det er
lykkedes nsa at kompromitere metoden. Men der var vist uenighed om,
det var sket ved krypteringsvidenskab, eller bagdøre.

Din hjemmeside giver 'connection is untrusted'.
Dvs det sker, når man selv genererer ssl-nøglen?

[gtr]

http://arstechnica.com/security/2013/11/op-ed-a-critique-of-lavabit/