Forsker efter nyopdaget svaghed: NSA kan nok lytte med på de fleste VPN-forbindelser

Diffie-Hellman algoritmen, der bliver brugt til SSL, SSH og ikke mindst VPN, er implementeret på en måde, så det med tilstrækkelig computerkraft har vist sig realistisk muligt at knække nøgler på 1024 bit og under. Der er ingen nem løsning.

En række forskere har fundet frem til flere svagheder i den måde, den udbredte Diffie-Hellman-algoritme bliver anvendt på. Algoritmen danner blandt andet grund for krypteringen bag TLS- (HTTPS), VPN- og SSH-forbindelser. Værst ser det ud for VPN-forbindelser, fortæller en af forskerne til Version2.

Diffie–Hellman key exchange, som den retteligt kaldes, bliver brugt til udveksling af kryptografiske nøgler på offentlige forbindelser.

Svaghederne ved Diffie-Hellman key exchange, som forskerne har fundet, er særligt problematiske, fordi de samme primtal bliver anvendt mange steder. Så selvom det med kendskab til svaghederne i matematikken tager en uges computerkraft at knække krypteringen bag et primtal med en længde på eksempelvis 512 bit, så gør det ikke så meget set fra en hackers synspunkt, fordi det samme primtal bliver anvendt på mange webservere. Derfor er det nok at foretage en enkelt beregning på et udbredt primtal for at kompromittere mange servere.

En del af det forskerne har fået frem til har fået navnet LogJam-angrebet, og blev blandt andet omtalt her på Version2 i sidste uge. Det er et downgrade-angreb, der, som navnet antyder, får serveren til at nedgradere forbindelsen til 512 bit-kryptering, selvom krypteringen i udgangspunktet burde være stærkere. Herefter kan forskerne anvende de matematiske svagheder, der har fundet frem til i Diffie-Hellman til at lytte med på forbindelsen i et man-in-the-middle-angreb.

8,4 pct. af de en million mest populære HTTPS-domæner understøtter 512 bit-kryptering, der ellers ikke bliver betragtet som sikker. Og 80 pct. af disse domæner er sårbare overfor LogJam-angrebet og kan derved narres til at bruge 512 bit-krypteringen af en man-in-the-middle.

Problemet med 512 bit-sårbarheden er, at den kan alle med den rette viden udnytte efter at have udført de nødvendige primtalsberegninger på forhånd. LogJam-sårbarheden kan fikses med browser-patches, og det er Google, Microsoft, Mozilla og andre igang med.

1024 bit kan også knækkes

Men en ting er 512 bit-primtallene, noget andet er, at forskerne også har fundet frem til, at det er realistisk muligt at knække 1024 bit-primtal med tilstrækkelig computerkraft. Ikke den, som almindelige hackere eller andre kriminelle måtte være i besiddelse af, men den som eksempelvis nationalstater og NSA kunne tænkes at råde over.

Ved at knække det mest udbredte 1024 bit-primtal vurderer forskerne, at det vil være muligt passivt at lytte med på 18 pct. af de 1 million mest populære HTTPS-domæner. Det passive ligger i, at det modsat LogJam ikke er nødvendigt først at udføre et downgrade angreb til 512 bit - som nogen måske bemærker - for at kunne lytte med.

»I 1024 bit-tilfældet, så kræver det nok en nationalstat for at investere tilstrækkeligt. Men vi har beviser, der er konsistente med, at det har fundet sted. Og det er det uhyggelige,« siger en af de førende forskere bag LogJam-opdagelsen, J. Alex Halderman fra universitetet i Michigan til Version2.

Han var i fredag i sidste uge på besøg på IT-Universitetet, hvor han fortalte nærmere om LogJam og perspektiverne ved at nationalstater kan knække 1024 bit-krypteringen.

Modsat 512 bit-angrebet, så er det ikke let at løse problemet i forhold til 1024 bit-primtallene. Og slet ikke hvad VPN-forbindelser angår, som også er ramt af denne sårbarhed.

Men først HTTPS-webserverne. Det er ganske vist muligt at opdatere webserverne, der i dag anvender den sårbare 1024 Diffie-Hellman kryptering, så stærkere kryptering bliver anvendt.

Men fordi serverne først skal opdateres, så er det ikke noget, der umiddelbart kan klares ved at patche browser-siden. For det nytter ikke, at browserne eksempelvis kun understøtter 2048 kryptering, når mange servere ikke kører via 2048 endnu, forklarer Alex Halderman.

»Efterhånden som servere skifter til stærkere metoder, så kan browsere forhåbentligt droppe det sårbare 1024-bit tilfælde også. Og så vil vi være i en situation, hvor vi er sikrere i forhold til angribere på statsniveau. Foreløbigt ved vi det ikke med sikkerhed, men vi har grund til at tro, at i hvert fald NSA - og måske andre regeringer også - er i stand til at bryde de mest almindelige 1024 bit-primtal,« siger Alex Halderman.

Også SSH-forbindelser er sårbare, hvor forskerne vurderer, at 26 pct. af alle SSH-servere kan kompromitteres ved at knække 1024 bit-krypteringen. Men værst ser det ud for VPN-forbindelser, som også er de sværeste at fikse.

66 pct. af alle VPN-forbindelser er ifølge forskerne sårbare og anvender det samme 1024 bit-primtal, som krypteringen baserer sig på. Primtallet er bygget ind i specifikationerne bag VPN-forbindelserne.

»Vi tror, 1024 er relativt vanskeligt at fikse, fordi det involverer sådan noget som VPN - disse [prim]tal er standardiserede i protokol-specifikationen. Så alles software har disse primtal på 1024 bit programmeret ind i sig. Vi bliver nødt til at gå tilbage og ændre en masse legacy-systemer for at slippe af med den svage kryptering,« siger Alex Halderman.

Han forklarer, at problemet ligger i standard internet key exchange-protokollen (IKE), og at langt størstedelen af alle VPN’er bruger den.

»Det er langt den mest udbredte standard,« siger Halderman.

Informationer fra Snowden

Når Halderman og hans forskerkollegaer mener, eksempelvis NSA, nok kan knække 1024 bit som følge af svagheder i svagheder i Diffie–Hellman, så er det mere en bare ren spekulation.

Forskerne har blandt andet kigget på NSA’s budget og på papirer, som den tidligere efterretningsanalytiker Edward Snowden har offentliggjort. Og når regnekraften, der skal til at knække 1024 bit-nøglerne blive holdt op mod NSA’s budget og Snowdens informationer, så mener Alex Halderman, der er god grund til at tro, at NSA - og måske også andre - lytter med på 1024 bit-Diffie-Hellman-linjen. Blandt andet har det tyske magasin Der Spiegel tidligere offentliggjort et diagram fra Snowden, som giver forskerne anledning til at tro, at NSA har et setup rettet mod netop VPN-forbindelser i den forbindelse. (se billede).

Om NSA-mistanken siger Halderman:

»Det er en meget kraftig mistanke, men vi kan ikke bevise det. Vi mener dog, mistanken er velfunderet. Vi kan lave beregninger, som viser, at det er muligt, vi kan demonstrere, at de har råd til det, vi kan fremlægge beviser for, at de har bygget systemer, som muligvis fungerer således, og vi kan fremlægge beviser for, at det er præcist dette, de gerne vil. Vi kan dog ikke dokumentere, at det faktisk er blevet gjort.«

Samme primtal

En væsentligt del af problemet med Diffie-Hellman-svaghederne skyldes som nævnt, at de samme primtal går igen mange steder.

Så selvom det har taget forskerne en uges beregninger at kompromittere 512 bit-primtallene, så er det nok at gøre det en enkelt gang for at ramme eksempelvis en stor del af alverdens Apache-servere, som bruger samme primtal.

Og på samme måde som forskerne kan kompromittere 512 bit, kan eksempelvis NSA ved at regne (kraftigt) på et enkelt 1024 bit-primtal lytte med på rigtigt mange VPN-forbindelser. Hvad webservere angår, så dækker 10 primtal 97 pct. af alverdens webservere. Men de kan altså fikses, forklarer Alex Halderman.

»Det er faktisk muligt at beregne et unikt primtal per server, men det er bare ikke sådan, folk tager servere i brug. I stedet er primtallet bygget ind i Apache, og alle bruger det samme tal,« siger han og tilføjer:

»Noget af det, vi foreslår, hvis folk fortsat vil bruge Diffie-Hellman, er at skifte til 2048 bit-styrke, hvilket burde være stærkt nok til også at besejre selv angribere på statsniveau, og derudover at vælge et unikt primtal på hver enkelt server.«

Kryptering med primtal er dog sådan indrettet, at ikke alle primtal er lige gode, hvis det skal være sikkert. Og det er en udfordring, hvis folk selv begynder at regne primtal ud på webservere.

»Så folk kan lave fejlkonfigurationer ved at vælge deres egne primtal, hvorved de faktisk kompromitterer sikkerheden yderligere. Så vi har nogle råd til, hvordan man kan være omhyggelig med dette på vores hjemmeside (weakdh.org). Og der er også andre muligheder i forhold til nøgleudveksling,« siger Alex Halderman.

Han nævner i den forbindelse elliptic curve-baseret Diffie-Hellman, som ikke har problemer i forhold til den konkrete angrebsteknik. Disse metoder har dog andre udfordringer, forklarer Alex Halderman.

»Vi er ikke helt sikre på, at vi kan stole på elliptic curve Diffie-Hellman, selvom den almene opfattelse blandt kryptologer for øjeblikket lader til at være, at det nok er bedre.«

Læs også: NSA-direktør: Vi skulle ikke have anbefalet algoritme med potentielle bagdøre

Spøgelse fra 1990’erne

Når 512 bit-krypteringen - som det ikke kræver NSA’s eller tilsvarende ressourcer at knække - overhovedet er et problem i dag, skyldes det, at forskerne er i stand til at udføre et downgrade-angreb. Her bliver klient og server narret til at kommunikere via 512 bit, selvom begge i udgangspunktet understøtter en stærkere kryptering.

Downgrade-angrebet udspringer - som et andet angreb tidligere på året, FREAK - direkte af det amerikanske eksportforbud mod stærk kryptering fra 1990’erne.

Dengang var 512 bit tilladt, mens stærkere kryptering var forbudt. Og derfor understøtter mange servere den dag i dag 512 bit-kryptering af hensyn til bagudkompatibilitet. Og det er denne understøttelse, der gør forskerne i stand til at foretage downgrade-angrebet.

»Det er 512 bit krypto-bagdøren fra 1990’erne, der hjemsøger os i dag. 1024 bit-tilfældet påvirker endnu flere mennesker, inklusiv to tredjedele af alle sikre VPN-forbindelser,« siger Alex Halderman.

Og det er netop dette downgrade-angreb, som en stribe udbredte browsere nu bliver patched mod som følge af forskernes opdagelser. Halderman fortæller, at de i god tid tog kontakt til firmaerne bag browserne, så de kunne nå at fikse det, inden forskningsresultaterne blev offentliggjort.

»Nogle af dem ventede med at publicere patches til efter, vi havde offentliggjort vores resultater. Men deres patches er klar. Og forhåbentlig vil browserne være patchede, når kriminelle angribere bliver i stand til at få deres Diffie-Hellman-beregninger til fungere,« siger han med henvisning til, at forskerne skulle bruge en uges computerkraft på at knække krypteringen, som et udbredt 512 bit-primtal ligger til grund for.

Sikkerhedssamfundet troede det var sikkert

FREAK-sårbarheden, som Alex Halderman også stod bag opdagelsen af, er som sådan lettere at udnytte i konkrete tilfælde. Men til forskel fra Diffie-Hellman, bygger FREAK på RSA-kryptering. Og antagelsen var her, at RSA var mange gange svagere end Diffie-Hellman. Det er den som sådan også, hvis altså ikke de samme primtal gik igen ved Diffie-Hellman. På den måde er det muligt at lave én tung beregning i stedet for en beregning per server, man ønsker at angribe.

»Den gængse opfattelse i sikkerhedssamfundet var, at Diffie-Hellman var mange gange sværere end RSA. Men det nye i det her er, at hvis du kun går efter én forbindelse, så er det mange gange sværere. Men hvis du går efter alle, så er det måske en million gange lettere (med Diffie-Hellman, red.),« siger Alex Halderman.

Derudover er der også en fælles lektion ved både FREAK og LogJam, der begge bruger downgrade-angreb, som er mulige som følge af det amerikanske eksport-forbud fra 1990’erne, mener Halderman:

»De er begge en lærestreg om, at bevidst svækkelse af krypteringsstyrke er en meget dårlig og farlig idé, selv når du tror, det er et særligt tilfælde. Her 20 år senere har det vist sig, at ja, 512 bit ikke bare er svagt nok til NSA, det er svagt nok til en flok akademikere i et lille computerlaboratorie, eller svagt nok til alle med EC2 - Amazons sky - og open source software.«

Og så er der der med 1024 bit-primtallene og NSA. Udover Snowden-lækkene og beregningerne i forhold til, at det faktisk godt kan lade sig gøre at knække den stærkere kryptering sammenlignet med 512-downgrade-angrebet, så fortæller Halderman, at han ved fra pålidelig kilde, at NSA er trætte af forskernes seneste offentliggørelse:

»Man hører på jungletrommerne, at de er sure hos NSA over, at dette er kommet for dagens lys. Jeg kan ikke citere nogen specifikt for dette. Og hvem ved, om det er virkeligt. Jeg vurderer, det er en pålidelig kilde.«

Forskerne har lavet en oversigt med tips og tricks til, hvordan server-operatører bør forholde sig i forhold til de nyopdagede sårbarheder, hvor det også er muligt at se, om ens browser er blevet opgraderet mod LogJam-sårbarhden. Siden kan findes her og forskernes rapport med flere videnskabelige data findes her (PDF).

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (21)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Kristian Christensen

Jeg er da ikke tryg ved at 2048bit nøgle BURDE være stærk nok. Hvis den formodes at være stærk nok ville jeg ikke bruge mindre end 4096 bit. Ja det giver en masse trafik. Men det vil da gøre brugere mere trygge ved at bruge ens service.

  • 2
  • 0
Baldur Norddahl

Skift til elliptic curve. Det er en mærkelig formulering i artiklen: "Vi er ikke helt sikre på, at vi kan stole på elliptic curve Diffie-Hellman, selvom den almene opfattelse blandt kryptologer for øjeblikket lader til at være, at det nok er bedre".

Med andre ord, vi er ikke sikre på at man kan stole på elliptic curve, men flertalet af kryptologerne mener at vi kan stole mere på elliptic curver end primtal. Heraf udledt, vi er ikke sikre på at man kan stole på primtal.

Jeg bruger elliptic curve til mine ssh nøgler. De fylder også væsentligt mindre.

  • 4
  • 0
Peter Christiansen

Det er en mærkelig formulering i artiklen: "Vi er ikke helt sikre på, at vi kan stole på elliptic curve Diffie-Hellman, selvom den almene opfattelse blandt kryptologer for øjeblikket lader til at være, at det nok er bedre".

Grunden til at han formulerer det sådan, er at matemagikerne ikke med
100% sikkerhed kan bevise at kryptering virker, eller er fejlfri,
man kan tilnærme sig et bud men aldrig 100%.

Man læner sig op af hvor mange der har peer-reviewet en given algoritme
og "godkendt" matematikken bag og også hvor langt tid den har været brugt etc.

Det er derfor man som programmør ikke skal sidde på kontoret og spille
smart ved at lave sin egen krypterings algoritme, det kaldes
"Security by obscurity" og kan aldeles frarådes.

Det blev set for nyligt i el målerne at en eller anden klaphat prøvede
at lave sin egen algoritme til kryptering og fejlede naturligvis.

Når matemagikere med livs lang erfaring ikke en gang kan bevise med
100% sikkerhed at en krypterings algoritme virker, så tro ikke at du er et eller andet og kan laven een på en eftermiddag.

  • 10
  • 1
Brian Jacobsen

Det er interessant som dette udtryk ofte dukker i forbindelse med 'dårlig sikkerhed'. Findes der egentlig andet end Security by obscurity i en digital verden?

Hvis kryptering går ud på at de 'onde' ikke kender et password eller et primtal, er det så ikke grundlæggende obscurity, altså noget man ved eller ikke ved?
Uanset om vi lægger fingeraftryk, nøglekort eller irisscanninger oveni, er det stadig 1'er og 0'er der suser frem og tilbage mellem klient og server. Hvis man kender de rigtige 1'er og 0'er kan man komme ind.

Hvordan får man en voldgrav og vindelbro digitalt?

  • 2
  • 3
Peter Christiansen

Hej Brian,
udtrykket knytter sig til kode der ikke er offentlig tilgængelig
for inspektion, hvor een eller anden har lavet noget "smart" hjemme
brygget som ligner noget der er sikkert.

Det kan til tider være svært at gennemskue hvis man ikke har kildekoden,
men som eksemplet med El-målerne kan det gå grueligt galt hvis nogen
tager sig tid til at analysere systemet.

Noget der ikke er security by obscurity er hashing algoritmer,
krypterings algoritmer da koden rent faktisk er tilgængelig for
inspektion. At man så ikke lige kan gennemskue hvordan det virker,
er ikke det samme.

"Security by obscurity" er det faktum at man prøver at gøre noget
sikkert, ved at gemme kildekoden. Altså obfuskere den om man vil.

  • 3
  • 2
Peter Lind

"Security by obscurity" er det faktum at man prøver at gøre noget
sikkert, ved at gemme kildekoden. Altså obfuskere den om man vil.

Det dækker over langt mere end bare at gemme kildekode. Security by obscurity er en negativ term der dækker over at du søger at opnå sikkerhed ved at gemme dine kritiske data eller systemer frem for at implementere reel sikkerhed.

Et eksempel på security by obscurity der ikke har noget med kildekode at gøre, kunne i konteksten være at benytte andre porte til VPN trafik end de typiske. Det vil helt sikkert fjerne en del automatiserede angreb mod det VPN-setup man bruger men det har nul og niks med egentlig sikkerhed at gøre, da motiverede angribere uden videre kan finde de nye porte med et distribueret portscan.

  • 5
  • 0
Peter Christiansen

Et eksempel på security by obscurity der ikke har noget med kildekode at gøre, kunne i konteksten være at benytte andre porte til VPN trafik end de typiske

Ja du har 65535 porte at vælge imellem, så det ville tage lidt mere tid
med nmap at finde den du bruger til vpn, dette ville jeg dog ikke se
som et træk til at forbedre sikkerheden, men der er nok nogle der ville
tro at det gør dem mere sikre.

Men din pointe er fin, der er nok andre ting end kildekoden der kan
klasificers som security by obscurity.

Jeg har også et real-life eksempel på hvad folk der arbejder professionelt
med web apps kan finde på for at forbedre sikkerheden.

"Lad os sætte vores program til kun at behandle POST requests,
så kan folk jo ikke spoofe parametre via url'en".

  • 0
  • 1
Ole Tange Blogger

Jeg fatter ikke kommentaren om de genbrugte primtal. Kan nogen uddybe?

Ligger der i min Apache (eller SSL eller SSH) pakke nogle primtal, som bliver brugt, når jeg genererer mit certifikat til underskrivelse? Eller der det en RNG, som laver dårlige tal, der bruges til at generere primtal (som så bliver de samme)?

Jeg gik og troede, at når jeg genererede certifikater at så blev primtallene valgt tilfældigt ud fra mit indhold i /dev/random, og at der derfor ikke var noget genbrug.

Hvis du forstår, hvordan de genbrugte primtal dukker op, så post lige en kommentar om det.

  • 1
  • 0
Bent Jensen

da motiverede angribere uden videre kan finde de nye porte med et distribueret portscan.


Nej, det har du da slået fra :-)

@ Brian Jacobsen

Men når regeringen læser og gemmer alt din data, så har de tid nok til at vente på at de kan læse det på et tidspunkt.

Men det er en rigtigt god forklaring på "Security by obscurity", som hvis du lægger adgang til din webserver på 8080, i stedet for 80, det er der aldrig nogen som vil prøve i stedet, så der for behøves du ikke adgangskode hvis du gør det.

Men hensyn til en rigtigt kryptering, og om det er sikkert, så er det meget svært at svare på. Da de fleste krypteringsmetoder virker ved at det kræver meget mere regnekraft at bryde, ind at code dem. Men efterhånden som udregnings kraften vokser så bliver de ældre metoder svagere og svagere. Der for DES blev aflivet.

Som et andet eksempel kan jeg huske de første digitale kryptering af TV signaler fra Satellit. Det vil tage en helt nyt 486 mindst et år at knække koden, og det skulle man så have lov til. Af det kan du så se at det var før internettet, hvor kopder kunne deles, og her over 25 senere, og med et godt grafikkort, så vil det nok kun tage dig 2-3 dage, hvis du ikke google det.

Man kan heller ikke bare sætte flere bit til nu, selv om 1 bit i teorien giver et 1.5 år extra tid før den er usikker. Da mange VPN forbindelser bliver beregnet i meget små CPU i Firewall, og en højere bitrate til kryptering vil give mere Lag, og en laver datamænge der kan puttes i tunnelen.

Men efter frihedshelten Edward Snowden afsløring, må man formode at alt vores data bliver indsamlet og gemt, så er det manglende på rettidigomhu IKKE at gøre det så svært for dem som muligt at lytte med. Det gøres ved at bruge den bedste kryptering man har til rådighed. Og kryptere de data som er mest sensitive med maximal bit og måske 2 forskellige algoritmer, inden man sender dem ud på nettet, vpn eller ej.

Hvis du vil have mest sikkerhed for din data, sæt ikke dine enheder på nettet, og lås dem inde. Og håb på din hus ikke brænder ned, så har du mistet dine data, men det er så helt sikkert dine.

  • 0
  • 0
Ole Tange Blogger

Nu har jeg bladret lidt i https://weakdh.org/imperfect-forward-secrecy.pdf Og så vidt jeg kan se er det gruppen af 1024-bit primtal, der kan knækkes ved at lave noget tung forudberegning, som ville være for dyr, hvis der kun kunne knækkes een forbindelse, men som er realistisk at lave, hvis det kan knække alle forbindelser. Så alle, der benytter gruppen af 1024-bit primtal er sårbare, men hvis du istedet havde baseret din nøgle på 1008-bit, så ville det kræve at lave den tunge beregning for dig (og de få andre nørder, det puttede 1008 ind i stedet for 1024).

Har jeg fattet det korrekt?

  • 3
  • 0
Bent Jensen

Har jeg fattet det korrekt?


Nej, de andre nørder skal bruge ,1009,1010,1011... hvis du bruger 1008. :-)

Men det om ikke andet, så viser det. Som frihedshelten Edward Snowden fortalte "kryptering virker".
Det er jo matematik, et naturvidenskabelig fag. Og hvis der ikke var en "lille fejl" i en af protokolerne/algoritmeren, som i praktisk betyder at vi alle bruger den samme nøgle, så var det uden for selv NSA og andre store landes rækkevidde at bryde den.

  • 0
  • 0
Peter Makholm Blogger

Og så vidt jeg kan se er det gruppen af 1024-bit primtal, der kan knækkes ved at lave noget tung forudberegning, som ville være for dyr, hvis der kun kunne knækkes een forbindelse, men som er realistisk at lave, hvis det kan knække alle forbindelser.


Når den artikle bruger begrebet 'Gruppe' så henviser det til en bestemt matematisk struktur.

Diffie-Helmann anvender to offentlige parametre: 'p' der er et stort primtal og 'g' der er en primitiv rod når man regner modulo p. Tilsammen definerer de to parametre den matematiske gruppe man foretager beregningerne i under en DH Key exchange. Det er noget omstændigt at beregne korrekte parametre derfor findes der lister af passende paramtre med forskellige størelser primtal.

Så det der skal til for at løse problemet er ikke nødvendigvis at gå væk fra 1024bit primtal, men bare at bruge et andet primtal end alle andre. At 1024bit så af andre grunde antages at være i den lave ende efter dagens standard er en anden sag. Hovedkonklusionen er at du selv skal generere det primtal der skal bruges (selvom det er offentligt).

Angrebet er så specielt kritisk i forbindelse med angreb hvor man kan lokke den anden ende til at bruge udgaver af algoritmerne hvor der er begrænsninger på størrelsen af primtal der kan bruges. Kombineret gør de to problemer det overkommeligt at lave et storstilet angreb mod SSL (og relaterede protokoller).

  • 3
  • 0
Jakob Møllerhøj Editor

Har jeg fattet det korrekt?

Som jeg har forstået det:

Hvis du klikker ind på nedenstående (IKE) og spoler ned til Oakley Groups, så indeholder 768-gruppen og 1024-gruppen et hardcoded primtal hver.

https://tools.ietf.org/html/rfc2409

Fra rapporten:

Generating primes with special properties can be computationally burdensome, so many implementations use fixed or standardized Diffie-Hellman parameters. A prominent example is the Oakley groups [39], which give “safe” primes of length 768 (Oakley Group 1), 1024 (Oakley
Group 2), and 1536 (Oakley Group 5). These groups were published in 1998 and have been used for many applications since, including IKE, SSH, Tor, and OTR.

I forhold til Apache og LogJam står der i rapporten:

The most popular 512-bit prime was hard-coded into many versions of Apache. Introduced in 2005 with Apache 2.1.5, it was used until 2.4.7, which disabled export ciphersuites. We found it in use by about 564,000 servers with browser-trusted certificates

Igen henvises der til et specifikt primtal og ikke 512 bit-primtal generelt.

Så som Peter Makholm udspecificerer ovenover, og som Alex Halderman påpeger i artiklen, er hovedproblemet, at de samme primtal bliver brugt mange steder.

  • 1
  • 0
Jesper Louis Andersen

Ikke alle primtal er lige gode til dette; det er sikkert også derfor at man har rodet sig ud at anbefale visse primtal, og det har så ledt til, at netop disse tal er blevet meget populære.

Det er også fordi de historisk set har været dyrt at beregne en gruppe og garantere at den er sikker. Så i stedet for at din VPN hardwaredims har skullet stå og æde løs i et par dage før den kan anvendes, så har man valgt at præinstallere den med en sikker gruppe, naturligvis "officielt" anbefalet.

  • 0
  • 0
Jesper Louis Andersen

Jeg er da ikke tryg ved at 2048bit nøgle BURDE være stærk nok. Hvis den formodes at være stærk nok ville jeg ikke bruge mindre end 4096 bit. Ja det giver en masse trafik. Men det vil da gøre brugere mere trygge ved at bruge ens service.

Fra 1024 bit til 2048 bit er der 1024 bit. Hvis du tager et 1025 bit primtal er arbejdet 21024bit. Ved 1027 bit er det 2221024bit og så fremdeles. Så hvis du kan præberegne 1024bit på 1 år, så skal du bruge 222 = 8 år for 1027 bit. Ved 1024 bit har du 2^1024 så meget arbejde. Det er

17976931348623159077293051907890247
33617976978942306572734300811577326
75805500963132708477322407536021120
11387987139335765878976881441662249
28474306394741243777678934248654852
76302219601246094119453082952085005
76883815068234246288147391311054082
72371633505106845862982399472459384
79716304835356329624224137216

år. Dertil kommer at du også skal bruge mere plads, for præberegningen skal gemmes på et lagermedie så du kan hive det frem. Hvis du skal bryde 2048bit, så skal du finde en hurtigere metode til at lave number-field-sieve-beregninger med præberegning. Det er muligt at de findes, men det er ikke specielt sandsynligt at de er i stand til at barbere 1024 bit af arbejdet. Hvis NSA havde det, er det en temmeligt stor matematisk opdagelse værdigt.

Som Baldur nævner, så er det værd at skifte til Elliptisk-Kurve kryptografi fordi disse kurver ikke er udsat for samme mulighed for præberegning. Nuvel, disse systemer er heller ikke uden problemer, da en fejlimplementation af systemet kan lokke folk til at afsløre deres key. Men matematisk er der ikke fundet samme gennembrud i at bryde dem, indtil videre.

  • 0
  • 0
Ole Tange Blogger

Det er

17976931348623159077293051907890247
33617976978942306572734300811577326
75805500963132708477322407536021120
11387987139335765878976881441662249
28474306394741243777678934248654852
76302219601246094119453082952085005
76883815068234246288147391311054082
72371633505106845862982399472459384
79716304835356329624224137216

år.

Laver du ikke her den (ret grove) antagelse, at computere ikke bliver hurtigere inden for den (ret lange) tidsperiode? Og hvis jo: Ville det så ikke være mere korrekt at skrive 1024 år (under antagelse af at computere+algoritme bliver dobbelt så hurtige hvert år)?

  • 0
  • 0
Pilu Kasper Bech

Simplet sagt er kryptering algoritmer matematiske problemer matematiker ikke har fundet nogen nem løsning på. Da man normalt ikke kan lave bevis for at der ikke er nogen nemmere måde at et løse matematisk problemet på. Kan sikkerheden på kryptering ikke bevises kun sandsynliggøres.

Derfor vil matematiker altid havde en hvis usikkerhed da det i teorien kunne findes en genial måde at løse disse kryptlogiske problemer på som ville gøre vores kryptering usikker.

Men med primtal og elliptiskes kurver har vi i meget langtid ledt efter en løsning som aldrig er fundet. Derfor mener vi de er sikker som kryptering.

*ret mig hvis jeg er helt ude i skov tak det er et komplekst emne ;) *

  • 0
  • 0
Kenneth Mejnert

Jeg fatter ikke kommentaren om de genbrugte primtal. Kan nogen uddybe?

Ligger der i min Apache (eller SSL eller SSH) pakke nogle primtal, som bliver brugt, når jeg genererer mit certifikat til underskrivelse? Eller der det en RNG, som laver dårlige tal, der bruges til at generere primtal (som så bliver de samme)?

Jeg gik og troede, at når jeg genererede certifikater at så blev primtallene valgt tilfældigt ud fra mit indhold i /dev/random, og at der derfor ikke var noget genbrug.

Hvis du forstår, hvordan de genbrugte primtal dukker op, så post lige en kommentar om det.


@ Ole Tange

Du blander tingene lidt sammen, og det er nok der din forviring opstår. Hvis vi tager SSL/TLS som eksempel, så involvere det flere forskellige kryptografiske funktioner med hvert sit formål. Populært kaldt en cipher suite. Tag fx.

TLS_DHE_RSA_WITH_AES_128_CBC_SHA

Denne cipher suite anvender:
DHE (Ephemeral Diffie Hellman) til nøgleudveksling
RSA til autentifikation
128 bit AES i CBC-mode til kryptering
SHA-1 som hash-funktion

Den nøgle du generere til dit certifikat, som er baseret på primtal, er unik (eller så godt som, men det er en anden diskusion :) ). Denne nøgle anvendes dog til autentifikation. Denne artikel går på Difffie Hellman, som anvendes til nøgleudveksling, og mange Diffie Hellman implementering kommer min "indbygget" primtal. Det har normalt ikke være betragtet som et problem, da sikkerheden i DH er baseret diskret logaritmeproblem, og primtallet derfor ikke behøver at være hemmeligt. Sikkerheden i RSA, som ofte anvendes til signatur, baseres sig derimod på primtalsfaktorisering.

Nu har det så vist sig, at selvom primtalet i Diffie Hellman ikke skal være hemmeligt, så er det alligevel nok uhensigtsmæssigt at anvende det samme primtal på tværs af mange implementeringer.

  • 0
  • 0
Kenneth Mejnert
  • 0
  • 0
Log ind eller Opret konto for at kommentere