Archief
- De topics van lang geleden
RSA exponent=3 bug in OpenSSL, Firefox etc.
1.1 Vooraf
Ik ben geen crypto-expert en geen security.nl medewerker. Ik
kon geen overzichtelijke informatie vinden over het hier
beschreven probleem, en heb gegevens bij elkaar gesprokkeld.
Ik vond het leerzaam om e.e.a. voor mezelf op een rijtje te
zetten, en wie weet vinden anderen dit ook interessant,
vandaar de post op dit forum als een soort discussiestuk.
Verder weet ik ook niet alles, dus zijn aanvullingen en
positieve/negatieve kritiek natuurlijk welkom! Omdat het een
erg lang verhaal geworden is hak ik het in 4 stukken;
kwetsbare applicaties noem ik in laatste deel.
1.2 Inleiding
Ik vermoed dat andere andere gebruikers, beheerders en
"gewone" programmeurs zich ook zorgen maken over de
betrouwbaarheid van cryptografie, welke een steeds
prominentere rol speelt in ons leven en onze samenleving.
Hoewel er ongetwijfeld vooral crypto-experts met goede
bedoelingen rondlopen, is het uiteindelijk wel hun boterham.
Uit dat oogpunt zijn zij wellicht niet de juiste mensen om
aan te vragen: hoe "foutloos" zijn jullie producten nu
echt, en zijn jullie producten inclusief de
infrastructuur waar jullie op bouwen, ueberhaupt wel
betrouwbaar genoeg om daarmee objecten en zelfs personen mee
te identificeren? Een probleem is dat cryptografie voor veel
mensen "black magic" is. Dat, en het feit dat consequenties
van fouten vaak onduidelijk zijn, is wellicht de oorzaak dat
berichten over crypto problemen met horten en stoten naar
buiten komen.
1.3 Implementatiefout in RSA signature verifier
Op de Crypto 2006 conferentie (20-24 Aug) werd niet alleen
een nieuwe aanvalstechniek op SHA-1 bekend gemaakt. Op
diezelfde conferentie meldde Daniel Bleichenbacher dat hij
in ten minste 1 implementatie van de RSA public key
signature verification code een ernstige fout had gevonden,
waardoor onder bepaalde omstandigheden signatures eenvoudig
te vervalsen zijn. Dit is voor het eerst in het openbaar
gemeld door Hal Finney op 27 augustus, zie
http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html.
Voor gewone mensen is die post waarschijnlijk onleesbaar en
ook de consequenties zijn niet duidelijk. Ik snapte er toen
ook nauwelijks wat van maar had wel het gevoel dat dit
flinke gevolgen kon hebben, en ben er veel over gaan lezen.
N.B. er is geen sprake van een fout in RSA zelf!
Om e.e.a. goed uit te kunnen leggen is het nodig te weten
hoe publick key encryptie werkt en wordt toegepast. Sla het
volgende stuk gerust over als je dat al weet.
Ik ben geen crypto-expert en geen security.nl medewerker. Ik
kon geen overzichtelijke informatie vinden over het hier
beschreven probleem, en heb gegevens bij elkaar gesprokkeld.
Ik vond het leerzaam om e.e.a. voor mezelf op een rijtje te
zetten, en wie weet vinden anderen dit ook interessant,
vandaar de post op dit forum als een soort discussiestuk.
Verder weet ik ook niet alles, dus zijn aanvullingen en
positieve/negatieve kritiek natuurlijk welkom! Omdat het een
erg lang verhaal geworden is hak ik het in 4 stukken;
kwetsbare applicaties noem ik in laatste deel.
1.2 Inleiding
Ik vermoed dat andere andere gebruikers, beheerders en
"gewone" programmeurs zich ook zorgen maken over de
betrouwbaarheid van cryptografie, welke een steeds
prominentere rol speelt in ons leven en onze samenleving.
Hoewel er ongetwijfeld vooral crypto-experts met goede
bedoelingen rondlopen, is het uiteindelijk wel hun boterham.
Uit dat oogpunt zijn zij wellicht niet de juiste mensen om
aan te vragen: hoe "foutloos" zijn jullie producten nu
echt, en zijn jullie producten inclusief de
infrastructuur waar jullie op bouwen, ueberhaupt wel
betrouwbaar genoeg om daarmee objecten en zelfs personen mee
te identificeren? Een probleem is dat cryptografie voor veel
mensen "black magic" is. Dat, en het feit dat consequenties
van fouten vaak onduidelijk zijn, is wellicht de oorzaak dat
berichten over crypto problemen met horten en stoten naar
buiten komen.
1.3 Implementatiefout in RSA signature verifier
Op de Crypto 2006 conferentie (20-24 Aug) werd niet alleen
een nieuwe aanvalstechniek op SHA-1 bekend gemaakt. Op
diezelfde conferentie meldde Daniel Bleichenbacher dat hij
in ten minste 1 implementatie van de RSA public key
signature verification code een ernstige fout had gevonden,
waardoor onder bepaalde omstandigheden signatures eenvoudig
te vervalsen zijn. Dit is voor het eerst in het openbaar
gemeld door Hal Finney op 27 augustus, zie
http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html.
Voor gewone mensen is die post waarschijnlijk onleesbaar en
ook de consequenties zijn niet duidelijk. Ik snapte er toen
ook nauwelijks wat van maar had wel het gevoel dat dit
flinke gevolgen kon hebben, en ben er veel over gaan lezen.
N.B. er is geen sprake van een fout in RSA zelf!
Om e.e.a. goed uit te kunnen leggen is het nodig te weten
hoe publick key encryptie werkt en wordt toegepast. Sla het
volgende stuk gerust over als je dat al weet.
Reacties (7)
17-09-2006, 14:42 door
Bitwiper
2.1 Werking public key encryptie
De basis van public key crypto bestaat uit een fraaie
wiskundige truuk. Het komt er op neer dat er twee "sleutels"
zijn die op een speciale manier bij elkaar horen, een
private key en een public key (dit wordt wel een
complementair sleutelpaar genoemd). Het elegante er aan is
dat je, wat je met de private key versleutelt, uitsluitend
met de public key kunt uitpakken. Andersom werkt het ook:
wat je met de public key versleutelt, kun je uitsluitend met
de private key uitpakken.
Bovendien zit het algoritme zo in elkaar dat het met de
huidige computerkracht niet mogelijk is om uit de "cryptext"
en de gebruikte "uitpaksleutel" de gebruikte "inpaksleutel"
te herleiden. Een belangrijk nadeel is dat het proces traag
is, en alleen al om die reden is het ongeschikt om grotere
bestanden te versleutelen. Daarom wordt met public key
encryptie meestal een hash (bij signeren) of een
symmetrische sleutel (bij versleutelen, die sleutel heeft
niets met PKI te maken) versleuteld en bij ontvangst weer
uitgepakt. Omdat het "public exponent=3" probleem (voor
zover ik weet) alleen met het het controleren van signatures
te maken heeft, ga ik niet verder in op het versleutelen van
documenten.
Als je wilt dat iemand zeker weet dat een document (e-mail,
webpage, exe-file, getuigenis etc). echt door jou is
geschreven (en daarna niet is gewijzigd) kun je er een
digitale handtekening onder zetten. Er van uitgaande dat je
al een sleutelpaar hebt, gaat dit als volgt:
(1) Bepaal de hash van het document (bijv. met SHA-1)
(2) Versleutel die hash met je private key (noem dit de
"signature")
(3) Stuur het document samen met de "signature" naar de
ontvanger
Ga er gemakshalve van uit dat de ontvanger jouw public key
al in zijn bezit heeft en zeker weet dat het
jouw public is, bijv. doordat jij deze ooit
persoonlijk aan hem gegeven hebt. Dit kan ook op een andere
manier (dit leg ik verderop uit aan de hand van de punten 4
t/m 6, vandaar dat ik die hier oversla). De ontvanger kan
dan het volgende doen:
(7) De "signature" uitpakken met jouw public key
(8) Zelf ook de hash van jouw document bepalen
(9) Beide hashes vergelijken
De implementatiefout waar Bleichenbacher op doelt betreft in
eerste instantie punt 7. Als jouw sleutelpaar aan bepaalde
voorwaarden voldoet, en een aanvaller jouw public key kent
(wat zelden een probleem is) kan hij een document uit jouw
naam zodanig "signeren" (zonder over jouw private key te
beschikken) dat foutieve software geen alarm slaat. Zodra de
ontvanger zijn software geupdate heeft zal een dergelijke
vervalsing door de mand vallen; echter er kan geruime tijd
overheen gaan voordat de bug in de software van jouw
ontvanger is vastgesteld, gerepareerd en is geinstalleerd.
Tot die tijd kunnen al onjuiste beslissingen zijn genomen,
personen kunnen onterecht toegang tot gegevens hebben gehad
of, bijv. bij een software distributie systeem, kunnen
systemen al zijn "geroot".
Een PKI systeem kan, onafhankelijk van jouw sleutelpaar, al
roet in het eten gooien voordat punt 7 wordt bereikt. Om dat
te verduidelijken leg ik eerst uit hoe PKI werkt.
2.2 Werking PKI
Bij een Public Key Infrastucture worden certificaten
gebruikt. Doel is dat ontvangers kunnen vaststellen dat jouw
public key daadwerkelijk van jou is. Dit doen ontvangers
door een derde partij, een CA (Certificate Authority) te
vertrouwen; die CA vertelt namelijk aan de ontvanger of de
gegeven public key daadwerkelijk van jou is of niet. Ook
dit proces maakt gebruik van public key encryptie.
Het voordeel van certificaten is dat public keys met
documenten zelf meegestuurd kunnen worden. Ontvangers hoeven
dan niet zelf naar public keys te zoeken en vaststellen dat
ze echt van de bedoelde eigenaar zijn. Ook hoeven ze, als er
meer gecommuniceerd gaat worden, die public keys niet zelf
op een "safe place" (zoals een keyring) te bewaren.
Opnieuw ervan uitgaande dat je al een sleutelpaar hebt, kun
je als volgt aan een certificaat komen. Jouw software pakt
jouw public key tezamen met diverse naamsgegevens in een
(nog ongetekend) certificaat (een klein bestand). Dit
bestand stuur jij naar een CA, en nadat je op de een of
andere manier hebt aangetoond dat jij jij bent (en betaald
hebt) zal die CA jouw certificaat aanvullen met gegevens van
die CA zelf, het certificaat ondertekenen en naar jou
terugsturen. Dit ondertekenen gebeurt op precies dezelfde
manier als bovenstaande punten (1) t/m (3), waarbij jouw
certificaat het document is en de CA natuurlijk ondertekent
met hun private key.
Elke moderne web "bevat" de public keys van alle
gerenommeerde CA's (om verwarring te voorkomen leg ik
verderop pas uit hoe dat is geimplementeerd). Doel is dat de
webbrowser van elk certificaat dat door een CA met haar
private key is gesigneerd, de echtheid kan vaststellen.
Daarmee bevestigt de CA feitelijk dat het certificaat jouw
public key bevat.
Als je een document wilt signeren en verzenden, handel je
als volgt:
(1) Bepaal de hash van het document
(2) Versleutel die hash met je private key (noem dit de
"signature")
(4) Stuur het document samen met de "signature" en
jouw certificaat naar de ontvanger
Op de PC van de ontvanger:
(5) Uit jouw certificaat wordt bepaald wie de CA is
(6) Met de public key van die CA (uit de webbrowser) wordt
vastgesteld of jouw certificaat in orde is
Als dat in orde is wordt jouw public key uit jouw
certificaat gehaald en wordt de procedure afgemaakt zoals
onder de eerdergenoemde punten 7 t/m 9.
Probleem: afhankelijk van het sleutelpaar van de CA kan
foutieve software bij punt 5 onterecht melden dat een
gespoofed certificaat correct is. Dit is een heel ernstige
fout. Het betekent namelijk dat indien een webbrowser
minstens 1 public key van een CA bevat die voldoet aan "de
eisen", een aanvaller een certificaat kan genereren dat die
CA "goedkeurt" (alle moderne webbrowsers blijken meerdere
van dergelijke CA public keys te bevatten). Dus ook al heb
jij een certificaat van een "goede" CA, dan kan een
aanvaller zich nog steeds als jou voordoen indien de
ontvanger de public key van zo'n "foute" CA in z'n browser
heeft.
2.3 Root certificaten
Public keys van CA's worden niet direct in webbrowsers
opgeslagen, maar in zogenaamde root certificaten.
Theoretisch zou het verifieeren daarvan ook fout kunnen
gaan, maar het hele systeem is er op gebaseerd dat de
webbrowser zelf, en alles wat daarbij geinstalleerd wordt,
betrouwbaar is. Als een aanvaller achteraf een kwaadaardig
root certificaat aan je webbrowser kan toevoegen heb je
sowieso een probleem, dat groter is dan de hier beschreven
problematiek.
De basis van public key crypto bestaat uit een fraaie
wiskundige truuk. Het komt er op neer dat er twee "sleutels"
zijn die op een speciale manier bij elkaar horen, een
private key en een public key (dit wordt wel een
complementair sleutelpaar genoemd). Het elegante er aan is
dat je, wat je met de private key versleutelt, uitsluitend
met de public key kunt uitpakken. Andersom werkt het ook:
wat je met de public key versleutelt, kun je uitsluitend met
de private key uitpakken.
Bovendien zit het algoritme zo in elkaar dat het met de
huidige computerkracht niet mogelijk is om uit de "cryptext"
en de gebruikte "uitpaksleutel" de gebruikte "inpaksleutel"
te herleiden. Een belangrijk nadeel is dat het proces traag
is, en alleen al om die reden is het ongeschikt om grotere
bestanden te versleutelen. Daarom wordt met public key
encryptie meestal een hash (bij signeren) of een
symmetrische sleutel (bij versleutelen, die sleutel heeft
niets met PKI te maken) versleuteld en bij ontvangst weer
uitgepakt. Omdat het "public exponent=3" probleem (voor
zover ik weet) alleen met het het controleren van signatures
te maken heeft, ga ik niet verder in op het versleutelen van
documenten.
Als je wilt dat iemand zeker weet dat een document (e-mail,
webpage, exe-file, getuigenis etc). echt door jou is
geschreven (en daarna niet is gewijzigd) kun je er een
digitale handtekening onder zetten. Er van uitgaande dat je
al een sleutelpaar hebt, gaat dit als volgt:
(1) Bepaal de hash van het document (bijv. met SHA-1)
(2) Versleutel die hash met je private key (noem dit de
"signature")
(3) Stuur het document samen met de "signature" naar de
ontvanger
Ga er gemakshalve van uit dat de ontvanger jouw public key
al in zijn bezit heeft en zeker weet dat het
jouw public is, bijv. doordat jij deze ooit
persoonlijk aan hem gegeven hebt. Dit kan ook op een andere
manier (dit leg ik verderop uit aan de hand van de punten 4
t/m 6, vandaar dat ik die hier oversla). De ontvanger kan
dan het volgende doen:
(7) De "signature" uitpakken met jouw public key
(8) Zelf ook de hash van jouw document bepalen
(9) Beide hashes vergelijken
De implementatiefout waar Bleichenbacher op doelt betreft in
eerste instantie punt 7. Als jouw sleutelpaar aan bepaalde
voorwaarden voldoet, en een aanvaller jouw public key kent
(wat zelden een probleem is) kan hij een document uit jouw
naam zodanig "signeren" (zonder over jouw private key te
beschikken) dat foutieve software geen alarm slaat. Zodra de
ontvanger zijn software geupdate heeft zal een dergelijke
vervalsing door de mand vallen; echter er kan geruime tijd
overheen gaan voordat de bug in de software van jouw
ontvanger is vastgesteld, gerepareerd en is geinstalleerd.
Tot die tijd kunnen al onjuiste beslissingen zijn genomen,
personen kunnen onterecht toegang tot gegevens hebben gehad
of, bijv. bij een software distributie systeem, kunnen
systemen al zijn "geroot".
Een PKI systeem kan, onafhankelijk van jouw sleutelpaar, al
roet in het eten gooien voordat punt 7 wordt bereikt. Om dat
te verduidelijken leg ik eerst uit hoe PKI werkt.
2.2 Werking PKI
Bij een Public Key Infrastucture worden certificaten
gebruikt. Doel is dat ontvangers kunnen vaststellen dat jouw
public key daadwerkelijk van jou is. Dit doen ontvangers
door een derde partij, een CA (Certificate Authority) te
vertrouwen; die CA vertelt namelijk aan de ontvanger of de
gegeven public key daadwerkelijk van jou is of niet. Ook
dit proces maakt gebruik van public key encryptie.
Het voordeel van certificaten is dat public keys met
documenten zelf meegestuurd kunnen worden. Ontvangers hoeven
dan niet zelf naar public keys te zoeken en vaststellen dat
ze echt van de bedoelde eigenaar zijn. Ook hoeven ze, als er
meer gecommuniceerd gaat worden, die public keys niet zelf
op een "safe place" (zoals een keyring) te bewaren.
Opnieuw ervan uitgaande dat je al een sleutelpaar hebt, kun
je als volgt aan een certificaat komen. Jouw software pakt
jouw public key tezamen met diverse naamsgegevens in een
(nog ongetekend) certificaat (een klein bestand). Dit
bestand stuur jij naar een CA, en nadat je op de een of
andere manier hebt aangetoond dat jij jij bent (en betaald
hebt) zal die CA jouw certificaat aanvullen met gegevens van
die CA zelf, het certificaat ondertekenen en naar jou
terugsturen. Dit ondertekenen gebeurt op precies dezelfde
manier als bovenstaande punten (1) t/m (3), waarbij jouw
certificaat het document is en de CA natuurlijk ondertekent
met hun private key.
Elke moderne web "bevat" de public keys van alle
gerenommeerde CA's (om verwarring te voorkomen leg ik
verderop pas uit hoe dat is geimplementeerd). Doel is dat de
webbrowser van elk certificaat dat door een CA met haar
private key is gesigneerd, de echtheid kan vaststellen.
Daarmee bevestigt de CA feitelijk dat het certificaat jouw
public key bevat.
Als je een document wilt signeren en verzenden, handel je
als volgt:
(1) Bepaal de hash van het document
(2) Versleutel die hash met je private key (noem dit de
"signature")
(4) Stuur het document samen met de "signature" en
jouw certificaat naar de ontvanger
Op de PC van de ontvanger:
(5) Uit jouw certificaat wordt bepaald wie de CA is
(6) Met de public key van die CA (uit de webbrowser) wordt
vastgesteld of jouw certificaat in orde is
Als dat in orde is wordt jouw public key uit jouw
certificaat gehaald en wordt de procedure afgemaakt zoals
onder de eerdergenoemde punten 7 t/m 9.
Probleem: afhankelijk van het sleutelpaar van de CA kan
foutieve software bij punt 5 onterecht melden dat een
gespoofed certificaat correct is. Dit is een heel ernstige
fout. Het betekent namelijk dat indien een webbrowser
minstens 1 public key van een CA bevat die voldoet aan "de
eisen", een aanvaller een certificaat kan genereren dat die
CA "goedkeurt" (alle moderne webbrowsers blijken meerdere
van dergelijke CA public keys te bevatten). Dus ook al heb
jij een certificaat van een "goede" CA, dan kan een
aanvaller zich nog steeds als jou voordoen indien de
ontvanger de public key van zo'n "foute" CA in z'n browser
heeft.
2.3 Root certificaten
Public keys van CA's worden niet direct in webbrowsers
opgeslagen, maar in zogenaamde root certificaten.
Theoretisch zou het verifieeren daarvan ook fout kunnen
gaan, maar het hele systeem is er op gebaseerd dat de
webbrowser zelf, en alles wat daarbij geinstalleerd wordt,
betrouwbaar is. Als een aanvaller achteraf een kwaadaardig
root certificaat aan je webbrowser kan toevoegen heb je
sowieso een probleem, dat groter is dan de hier beschreven
problematiek.
17-09-2006, 14:42 door
Bitwiper
3.1 Low-level RSA signatures
We ontkomen niet aan een stukje low-level techniek. Nogmaals
ik ben geen expert, correcties en aanvullingen zijn welkom.
Hoe een RSA sleutelpaar precies gegenereerd wordt leg ik
hier niet uit. Van belang is dat je weet dat er uiteindelijk
drie positieve gehele getallen uit rollen:
n: de modulus
e: de public exponent
d: de private exponent
De public key wordt gevormd door zowel e als n, en de
private key door zowel d als n (beide keys bestaan feitelijk
uit twee positieve gehele getallen, waarbij "n" in beide
keys wordt gebruikt).
Bij RSA encryptie wordt de "message" of "plaintext" (de te
versleutelen data) opgenomen als onderdeel in een blok van
vaste lengte, bijv. 1024 bits (128 bytes). Bij signatures,
waarbij een hash (ook bekend als message digest) wordt
versleuteld met het PKCS #1 protocol (RFC3447), is de layout
van dit blok als volgt:
EncodedMessage =
| 0 | 1 | Padding | 0 | ASN.1_DigestInfo |
"Padding" bevat zoveel 0xFF bytes als nodig om tot de
gewenste bloklengte te komen, en ASN.1_DigestInfo bevat,
naast de hash zelf, onder meer informatie over welk hash
algoritme wordt gebruikt. N.B. "Encoded" betekent hier
alleen ingepakt, er is nog niets versleuteld! Dat
versleutelen gaat als volgt:
[color=red]signature = EncodedMessage^d mod n
[/color]
oftewel "EncodedMessage" wordt hier als een getal beschouwd
en tot de macht "d" verheven, en van het getal dat daar
uitkomt wordt de modulus met "n" berekend (modulus is de
rest na een deling, bijv. 11 mod 3 geeft 2). De ontvanger
decrypt de signature weer in een EncodedMessage als volgt:
[color=red]EncodedMessage = signature^e mod n
[/color]
waarna de hash uit de EncodedMessage gehaald wordt.
3.2 Public Exponent=3
Indien de public exponent "e" de waarde 3 heeft, blijken een
aantal implementaties kwetsbaar, als ik het goed begrijp bij
het uitpakken van de EncodedMessage (dus na het
decrypten). In OpenSSL zijn zelfs twee verschillende
problemen geconstateerd. In beide gevallen laat de software
zich verleiden om de "hash" op een verkeerde plaats uit het
blok te halen. De aanvaller maakt namelijk een
EncodedMessage als volgt:
| 0 | 1 | Padding | 0 | ASN.1_DigestInfo | Troep |
waarbij de aanvaller de lengte van padding varieert om zo
troep (vrij te kiezen bytes) toe te kunnen voegen. Als de
aanvaller weet dat de ontvanger een root certificaat met
public key exponent = 3 in z'n browser heeft, kan hij een
certificaat naar keuze maken dat door de door hem gekozen CA
lijkt te zijn gesigneerd. Hoe dat precies in z'n werk gaat
begrijp ik nog niet helemaal, maar het komt er op neer dat
de aanvaller in elk geval zo met de hash, de troep en het
aantal padding bytes moet spelen totdat het blok een macht
van 2 vormt, waarna hij de wortel daarvan als signature kan
gebruiken (ik vermoed dat er dan nog een iteratieslag nodig
is om de signature te laten goedkeuren).
3.3 Oorzaken exp=3 bugs
De bug waar Bleichenbacher op doelt ontstaat doordat OpenSSL
niet controleert of ASN.1_DigestInfo helemaal rechts in het
blok zit. Ook andere implementaties (doch niet GnuTLS)
blijken na de 0, de 1 en een onbekend aantal 0xFF bytes te
zoeken naar de eerstvolgende 0, om er daarna blind van uit
te gaan dat daarop de ASN.1_DigestInfo volgt.
Een tweede probleem, zowel in OpenSSL als in GnuTLS, zou
door Yutaka Oiwa, Kazukuni Kobara en Hajime Watanabe zijn
ontdekt, en wordt in
http://www.mail-archive.com/cryptography%40metzdowd.com/msg06624.html
toegelicht door Simon Josefsson. Daarbij zou een signature
ook zijn te vervalsen door de ASN.1 structure te manipuleren.
Beide bugs werken, voor zover mij bekend, alleen bij een
public key met public exponent=3.
3.4 Nog niet genoemde bronnen
http://en.wikipedia.org/wiki/RSA
http://en.wikipedia.org/wiki/ASN.1
Aardige RSA uitleg page waar ook wikipedia naar verwijst
http://www.di-mgt.com.au/rsa_alg.html
Index van een archive van de Cryptography maillijst
http://www.mail-archive.com/cryptography%40metzdowd.com/maillist.html
Public-Key Cryptography Standards (PKCS) #1: RSA
Cryptography Specifications Version 2.1
http://tools.ietf.org/html/rfc3447
Generate a keypair using OpenSSL
http://en.wikibooks.org/wiki/Transwiki:Generate_a_keypair_using_OpenSSL
Forscher stellen Exploit für SSL-Schwachstelle vor
http://www.heise.de/security/news/meldung/78274
Het enige artikel op security.nl dat inhoudelijk aandacht
besteed aan deze bug, met op dit moment nog geen enkel
commentaar
http://www.security.nl/article/14383/1/SSL_spoofing_door_beveiligingslek_in_RSA_crypto.html
OpenSSL-Signaturen lassen sich fälschen
http://www.heise.de/security/news/meldung/77783
We ontkomen niet aan een stukje low-level techniek. Nogmaals
ik ben geen expert, correcties en aanvullingen zijn welkom.
Hoe een RSA sleutelpaar precies gegenereerd wordt leg ik
hier niet uit. Van belang is dat je weet dat er uiteindelijk
drie positieve gehele getallen uit rollen:
n: de modulus
e: de public exponent
d: de private exponent
De public key wordt gevormd door zowel e als n, en de
private key door zowel d als n (beide keys bestaan feitelijk
uit twee positieve gehele getallen, waarbij "n" in beide
keys wordt gebruikt).
Bij RSA encryptie wordt de "message" of "plaintext" (de te
versleutelen data) opgenomen als onderdeel in een blok van
vaste lengte, bijv. 1024 bits (128 bytes). Bij signatures,
waarbij een hash (ook bekend als message digest) wordt
versleuteld met het PKCS #1 protocol (RFC3447), is de layout
van dit blok als volgt:
EncodedMessage =
| 0 | 1 | Padding | 0 | ASN.1_DigestInfo |
"Padding" bevat zoveel 0xFF bytes als nodig om tot de
gewenste bloklengte te komen, en ASN.1_DigestInfo bevat,
naast de hash zelf, onder meer informatie over welk hash
algoritme wordt gebruikt. N.B. "Encoded" betekent hier
alleen ingepakt, er is nog niets versleuteld! Dat
versleutelen gaat als volgt:
[color=red]signature = EncodedMessage^d mod n
[/color]
oftewel "EncodedMessage" wordt hier als een getal beschouwd
en tot de macht "d" verheven, en van het getal dat daar
uitkomt wordt de modulus met "n" berekend (modulus is de
rest na een deling, bijv. 11 mod 3 geeft 2). De ontvanger
decrypt de signature weer in een EncodedMessage als volgt:
[color=red]EncodedMessage = signature^e mod n
[/color]
waarna de hash uit de EncodedMessage gehaald wordt.
3.2 Public Exponent=3
Indien de public exponent "e" de waarde 3 heeft, blijken een
aantal implementaties kwetsbaar, als ik het goed begrijp bij
het uitpakken van de EncodedMessage (dus na het
decrypten). In OpenSSL zijn zelfs twee verschillende
problemen geconstateerd. In beide gevallen laat de software
zich verleiden om de "hash" op een verkeerde plaats uit het
blok te halen. De aanvaller maakt namelijk een
EncodedMessage als volgt:
| 0 | 1 | Padding | 0 | ASN.1_DigestInfo | Troep |
waarbij de aanvaller de lengte van padding varieert om zo
troep (vrij te kiezen bytes) toe te kunnen voegen. Als de
aanvaller weet dat de ontvanger een root certificaat met
public key exponent = 3 in z'n browser heeft, kan hij een
certificaat naar keuze maken dat door de door hem gekozen CA
lijkt te zijn gesigneerd. Hoe dat precies in z'n werk gaat
begrijp ik nog niet helemaal, maar het komt er op neer dat
de aanvaller in elk geval zo met de hash, de troep en het
aantal padding bytes moet spelen totdat het blok een macht
van 2 vormt, waarna hij de wortel daarvan als signature kan
gebruiken (ik vermoed dat er dan nog een iteratieslag nodig
is om de signature te laten goedkeuren).
3.3 Oorzaken exp=3 bugs
De bug waar Bleichenbacher op doelt ontstaat doordat OpenSSL
niet controleert of ASN.1_DigestInfo helemaal rechts in het
blok zit. Ook andere implementaties (doch niet GnuTLS)
blijken na de 0, de 1 en een onbekend aantal 0xFF bytes te
zoeken naar de eerstvolgende 0, om er daarna blind van uit
te gaan dat daarop de ASN.1_DigestInfo volgt.
Een tweede probleem, zowel in OpenSSL als in GnuTLS, zou
door Yutaka Oiwa, Kazukuni Kobara en Hajime Watanabe zijn
ontdekt, en wordt in
http://www.mail-archive.com/cryptography%40metzdowd.com/msg06624.html
toegelicht door Simon Josefsson. Daarbij zou een signature
ook zijn te vervalsen door de ASN.1 structure te manipuleren.
Beide bugs werken, voor zover mij bekend, alleen bij een
public key met public exponent=3.
3.4 Nog niet genoemde bronnen
http://en.wikipedia.org/wiki/RSA
http://en.wikipedia.org/wiki/ASN.1
Aardige RSA uitleg page waar ook wikipedia naar verwijst
http://www.di-mgt.com.au/rsa_alg.html
Index van een archive van de Cryptography maillijst
http://www.mail-archive.com/cryptography%40metzdowd.com/maillist.html
Public-Key Cryptography Standards (PKCS) #1: RSA
Cryptography Specifications Version 2.1
http://tools.ietf.org/html/rfc3447
Generate a keypair using OpenSSL
http://en.wikibooks.org/wiki/Transwiki:Generate_a_keypair_using_OpenSSL
Forscher stellen Exploit für SSL-Schwachstelle vor
http://www.heise.de/security/news/meldung/78274
Het enige artikel op security.nl dat inhoudelijk aandacht
besteed aan deze bug, met op dit moment nog geen enkel
commentaar
http://www.security.nl/article/14383/1/SSL_spoofing_door_beveiligingslek_in_RSA_crypto.html
OpenSSL-Signaturen lassen sich fälschen
http://www.heise.de/security/news/meldung/77783
17-09-2006, 14:44 door
Bitwiper
4.1 Kwetsbare applicaties
Op 5 september meldde OpenSSL zelf kwetsbaar te zijn in
versies 0.9.7j en 0.9.8b en ouder:
http://www.openssl.org/news/secadv_20060905.txt.
Ondertussen is gebleken dat ook een aantal populaire
webbrowsers en e-mail programma's kwetsbaar zijn voor deze
kwetsbaarheid, zoals Erik Tews en anderen op 15 sept. hebben
gepubliceerd, zie
http://www.cdc.informatik.tu-darmstadt.de/securebrowser/:
- Firefox en Thunderbird 1.5.0.6 en ouder
- Opera 9.01 en ouder
- Konqueror voor zover OpenSSL nog niet gepatched is
- Netscape (alle versies)
Behalve OpenSSL zelf zijn applicaties die van de RSA
signature verifier in OpenSSL gebruik maken natuurlijk ook
kwetsbaar:
- OpenPKG, zie
http://www.openpkg.org/security/advisories/OpenPKG-SA-2006.018-openssl.html
- OpenSSH indien voorzien van Roumen Petrov's X.509
certificate support, zie
http://roumenpetrov.info/openssh/
- BIND/DNSSEC zou volgens Ben Laurie
http://www.mail-archive.com/cryptography%40metzdowd.com/msg06588.html
ook kwetsbaar zijn; in
http://www.ietf.org/rfc/rfc3110.txt sectie 4
wordt duidelijk gesteld dat een public exponent van 3
acceptabel is (maar dat wil nog niet zeggen dat de
verifier kwetsbaar is). Volgens een aantal anderen op
de Crptography maillijst wordt DNSSEC nog nauwelijks gebruikt.
Vermoedelijk zijn ook deze kwetsbaar, voor zover ze gebruikt
worden om remote sites te identificeren. Hoewel SSL
verbindingen nog wel zullen worden versleuteld zijn MITM
attacks mogelijk. Patches zijn voor zover ik weet nog niet
beschikbaar:
- wget http://www.gnu.org/software/wget/
- curl http://curl.haxx.se/
Naast overige producten die "netjes" OpenSSL gebruiken en
mogelijk kwetsbaar zijn, kan sourcecode ook minder legaal
zijn overgenomen in andere producten, waarbij ook aan
embedded systemen moet worden gedacht. Het is de vraag of en
wanneer kwetsbare code gepatched zal worden.
4.2 Discussie
Op de Cryptography maillijst pleit Peter Gutmann ervoor om
public exponents van 3 (bij voorkeur kleiner dan of gelijk
aan 17) niet langer te accepteren, zie
http://www.mail-archive.com/cryptography%40metzdowd.com/msg06636.html.
Een probleem is natuurlijk dat er root certificaten in
omloop zijn die nog van kleinere exponenten gebruik maken.
Vervangen daarvan is misschien niet zo'n groot probleem,
maar ook alle certificaten die door de CA met de foute keys
zijn ondertekend worden daarmee ongeldig. Wie gaat het
vernieuwen daarvan betalen?
Kennelijk had ik op 22 augustus 2006 19:12 een voorgevoel
toen ik in http://www.security.nl/article/14235/
schreef "wie weet wat voor andere fouten ik nog over het
hoofd zie (denk ook aan implementatiefouten aan de kant van
de ontvanger)". Ik vind dit soort bugs heel ernstig. Hoewel
deze "input validation" bugs gelijkenis vertonen met code
die struikelt over gemanipuleerde velden in bijv. jpeg
plaatjes, hebben we het hier over het hoofddoel van
software: het onderscheid maken tussen echte en vervalste
handtekeningen. Dat de fouten in verschillende sources
voorkomen (Firefox en Netscape gebruiken geen OpenSSL) lijkt
er op te wijzen dat kritische sourcecode compleet met fouten
zonder nadenken is overgenomen. Als er zo gewerkt wordt kan
ik me niet voorstellen dat dit de laatste bugs waren op dit
gebied. Met alle zwakke schakels zou zelfs een kwalificatie
als "Pretty Good" wel eens te hoog gegrepen kunnen zijn.
De nadruk bij digitale handtekeningen lijkt vooral te liggen
op het aantonen dat jij iets wel geschreven hebt; de
omgekeerde situatie blijft vaak onderbelicht. Zolang dit
soort fouten niet algemeen bekend zijn en er misbruik van
gemaakt wordt, kan "aangetoond" worden dat jij iets
wel geschreven hebt terwijl dat niet zo is, en je
kunt je vast wel situaties voorstellen waarbij jij dat niet
eens te weten komt. En wie weet wordt "jouw" digitale
paspoort ooit gevonden op de plaats van een "crime-scene".
N.B. kleine exponenten zijn vooral populair op plaatsen waar
weinig rekenkracht beschikbaar is.
Op 5 september meldde OpenSSL zelf kwetsbaar te zijn in
versies 0.9.7j en 0.9.8b en ouder:
http://www.openssl.org/news/secadv_20060905.txt.
Ondertussen is gebleken dat ook een aantal populaire
webbrowsers en e-mail programma's kwetsbaar zijn voor deze
kwetsbaarheid, zoals Erik Tews en anderen op 15 sept. hebben
gepubliceerd, zie
http://www.cdc.informatik.tu-darmstadt.de/securebrowser/:
- Firefox en Thunderbird 1.5.0.6 en ouder
- Opera 9.01 en ouder
- Konqueror voor zover OpenSSL nog niet gepatched is
- Netscape (alle versies)
Behalve OpenSSL zelf zijn applicaties die van de RSA
signature verifier in OpenSSL gebruik maken natuurlijk ook
kwetsbaar:
- OpenPKG, zie
http://www.openpkg.org/security/advisories/OpenPKG-SA-2006.018-openssl.html
- OpenSSH indien voorzien van Roumen Petrov's X.509
certificate support, zie
http://roumenpetrov.info/openssh/
- BIND/DNSSEC zou volgens Ben Laurie
http://www.mail-archive.com/cryptography%40metzdowd.com/msg06588.html
ook kwetsbaar zijn; in
http://www.ietf.org/rfc/rfc3110.txt sectie 4
wordt duidelijk gesteld dat een public exponent van 3
acceptabel is (maar dat wil nog niet zeggen dat de
verifier kwetsbaar is). Volgens een aantal anderen op
de Crptography maillijst wordt DNSSEC nog nauwelijks gebruikt.
Vermoedelijk zijn ook deze kwetsbaar, voor zover ze gebruikt
worden om remote sites te identificeren. Hoewel SSL
verbindingen nog wel zullen worden versleuteld zijn MITM
attacks mogelijk. Patches zijn voor zover ik weet nog niet
beschikbaar:
- wget http://www.gnu.org/software/wget/
- curl http://curl.haxx.se/
Naast overige producten die "netjes" OpenSSL gebruiken en
mogelijk kwetsbaar zijn, kan sourcecode ook minder legaal
zijn overgenomen in andere producten, waarbij ook aan
embedded systemen moet worden gedacht. Het is de vraag of en
wanneer kwetsbare code gepatched zal worden.
4.2 Discussie
Op de Cryptography maillijst pleit Peter Gutmann ervoor om
public exponents van 3 (bij voorkeur kleiner dan of gelijk
aan 17) niet langer te accepteren, zie
http://www.mail-archive.com/cryptography%40metzdowd.com/msg06636.html.
Een probleem is natuurlijk dat er root certificaten in
omloop zijn die nog van kleinere exponenten gebruik maken.
Vervangen daarvan is misschien niet zo'n groot probleem,
maar ook alle certificaten die door de CA met de foute keys
zijn ondertekend worden daarmee ongeldig. Wie gaat het
vernieuwen daarvan betalen?
Kennelijk had ik op 22 augustus 2006 19:12 een voorgevoel
toen ik in http://www.security.nl/article/14235/
schreef "wie weet wat voor andere fouten ik nog over het
hoofd zie (denk ook aan implementatiefouten aan de kant van
de ontvanger)". Ik vind dit soort bugs heel ernstig. Hoewel
deze "input validation" bugs gelijkenis vertonen met code
die struikelt over gemanipuleerde velden in bijv. jpeg
plaatjes, hebben we het hier over het hoofddoel van
software: het onderscheid maken tussen echte en vervalste
handtekeningen. Dat de fouten in verschillende sources
voorkomen (Firefox en Netscape gebruiken geen OpenSSL) lijkt
er op te wijzen dat kritische sourcecode compleet met fouten
zonder nadenken is overgenomen. Als er zo gewerkt wordt kan
ik me niet voorstellen dat dit de laatste bugs waren op dit
gebied. Met alle zwakke schakels zou zelfs een kwalificatie
als "Pretty Good" wel eens te hoog gegrepen kunnen zijn.
De nadruk bij digitale handtekeningen lijkt vooral te liggen
op het aantonen dat jij iets wel geschreven hebt; de
omgekeerde situatie blijft vaak onderbelicht. Zolang dit
soort fouten niet algemeen bekend zijn en er misbruik van
gemaakt wordt, kan "aangetoond" worden dat jij iets
wel geschreven hebt terwijl dat niet zo is, en je
kunt je vast wel situaties voorstellen waarbij jij dat niet
eens te weten komt. En wie weet wordt "jouw" digitale
paspoort ooit gevonden op de plaats van een "crime-scene".
N.B. kleine exponenten zijn vooral populair op plaatsen waar
weinig rekenkracht beschikbaar is.
17-09-2006, 15:27 door
Pleurtje
Als je het artikel van RSA leest, kom je erachter dat niet
zozeer de encryptie zelf, danwel de implementatie van 1
programma niet deugt. Dit komt niet echt duidelijk naar
voren in je topic, dus ik meld het er even expleciet bij
En overigens, er bestaat niet zoals een magische manier om
iets te beveiligen; alles kan worden gekraakt, dus je moet
ook niet spreken OF een methode kraakvrij is, maar hoelang
't duurt om de encryptie te kraken. Theoretisch is 't uit te
rekenen hoelang 't duurt voordat je een bepaalde encryptie
kraakt, deze tijdsduur dient zolang te zijn, dat de
encrpyted data op 't theoretisch kraakmoment geen waarde
meer heeft
zozeer de encryptie zelf, danwel de implementatie van 1
programma niet deugt. Dit komt niet echt duidelijk naar
voren in je topic, dus ik meld het er even expleciet bij
En overigens, er bestaat niet zoals een magische manier om
iets te beveiligen; alles kan worden gekraakt, dus je moet
ook niet spreken OF een methode kraakvrij is, maar hoelang
't duurt om de encryptie te kraken. Theoretisch is 't uit te
rekenen hoelang 't duurt voordat je een bepaalde encryptie
kraakt, deze tijdsduur dient zolang te zijn, dat de
encrpyted data op 't theoretisch kraakmoment geen waarde
meer heeft
Ik ben geen crypto-expert maar na mijn mening maakt het niet zo veel uit of
het encrypted is of niet.Het enige voordeel wat encryptie kan bieden is data
versleuteld over een netwerk gaat.Waardoor het onmogelijk is voor
personenen de data op welke manier nog te kunnen inlezen van buiten af.
Ik denk dat het probleem blijft zitten in de het programma zelf.Om een
voorbeeld te geven van een mail applicatie die sha-2 of md-5 encryptie
gebruikt kan het document wel versleuteld zijn maar het programma zelf is
wel Vulnerable voor exploits.Hierdoor lijkt het alsof het document beveiligd
is maar is het totaal niet.
het encrypted is of niet.Het enige voordeel wat encryptie kan bieden is data
versleuteld over een netwerk gaat.Waardoor het onmogelijk is voor
personenen de data op welke manier nog te kunnen inlezen van buiten af.
Ik denk dat het probleem blijft zitten in de het programma zelf.Om een
voorbeeld te geven van een mail applicatie die sha-2 of md-5 encryptie
gebruikt kan het document wel versleuteld zijn maar het programma zelf is
wel Vulnerable voor exploits.Hierdoor lijkt het alsof het document beveiligd
is maar is het totaal niet.
19-09-2006, 00:39 door
raboof
Leuk stuk, hoewel aan het eind naar mijn smaak wat al te
dramatisch geschreven.
Ik ben er zelf nog niet ingedoken, maar uit je verhaal is me
nog niet precies duidelijk waarom je public exponents van 3
zou willen verbieden, in plaats van `gewoon' de fouten uit
de kwetsbare applicaties te halen.
dramatisch geschreven.
Ik ben er zelf nog niet ingedoken, maar uit je verhaal is me
nog niet precies duidelijk waarom je public exponents van 3
zou willen verbieden, in plaats van `gewoon' de fouten uit
de kwetsbare applicaties te halen.
19-09-2006, 02:50 door
Bitwiper
Door raboof
Leuk stuk
Dank je wel!Leuk stuk
, hoewel aan het eind naar mijn smaak wat al te
dramatisch geschreven.
Ik hoop het (in de zin van dat jij gelijk hebt :)dramatisch geschreven.
Ik ben er zelf nog niet ingedoken, maar uit je
verhaal is me nog niet precies duidelijk waarom je public
exponents van 3 zou willen verbieden, in plaats van `gewoon'
de fouten uit de kwetsbare applicaties te halen.
verhaal is me nog niet precies duidelijk waarom je public
exponents van 3 zou willen verbieden, in plaats van `gewoon'
de fouten uit de kwetsbare applicaties te halen.
Die fouten moeten er inderdaad als eerste uit gehaald
worden. De eerste fout, troep achter de ASN.1 structure, is
een pure implementatiefout en niet moeilijk te fixen.
Overigens zit in Firefox 1.5.0.7 nog steeds een routine met
zo'n fout, maar die wordt volgens Hal Finney waarschijnlijk
niet (meer) gebruikt:
http://www.mail-archive.com/cryptography%40metzdowd.com/msg06693.html
Ik heb zelf gisteravond kort naar de sources gekeken en er
lijkt bij het verifieeren van certificaten inderdaad
een andere routine gebruikt te worden, waar ik op het eerste
gezicht niet een dergelijke fout in zag.
De tweede fout komt eigenlijk neer op een design error in
RSA, doordat zij voor een ASN.1 struct gekozen hebben (ASN.1
is een soort binaire XML). Deze maakt het toevoegen van
variabele-lengte "troep" mogelijk binnen wat ik hierboven
ASN.1_DigestInfo noem (dit i.v.m. toekomstige uitbreidingen
zoals andere hash algoritmes). Als ik me niet vergis zijn
hier in latere revisies van de standaard wel beperkingen in
aangebracht.
Die tweede "fout" zat in bijv. in Firefox en is "gefixed"
door het niet meer accepteren van onbekende ASN.1 velden.
Dit klinkt dramatisch maar in Firefox zit toch geen code die
daar iets mee zou kunnen, en dus is future-compatibility
onzin. Deze fix zou theoretisch false positives (onterecht
afgekeurde certificaten) kunnen opleveren als iemand zo'n
ASN.1 uitbreiding zou gebruiken om er bijv. een comment in
te zetten (maar dat ligt niet voor de hand).
De reden om e=3 te verbieden lijkt te zijn dat, als
een aanvaller enige speelruimte heeft in de EncodedMessage
(Peter Gutmann noemt zelfs het varieeren van de hash door
het "document" enigszins te aan te passen), hij vooral bij
e=3 makkelijk een vervalsing kan maken.
Nadat http://en.wikipedia.org/wiki/RSA vermeldt
dat er geen attacks bekend zijn voor e=3, staat er: "when
the padding is improperly implemented then small public
exponents have a greater risk of leading to an attack".
RFC3110 wijst er onder punt 4 op dat public e=3 niet
geschikt is voor versleutelen, maar wel acceptabel is voor
authenticatie.
Ik verwacht niet dat support voor public e=3 meteen gedropt
wordt, maar ik neem aan dat CA's nu wel op zullen houden om
dergelijke root certs te maken, en als ze verstandig zijn
waarschuwen ze klanten die e=3 certs ter ondertekening
aanbieden.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Toezichthouder informatiebeveiliging Overheid
Rijksinspectie Digitale Infrastructuur (RDI)
Vind je het leuk om als toezichthouder bij te dragen aan de verdere groei in informatie-beveiliging van de overheid en in contact te staan met (belangen) organisaties binnen de overheid? Dan kun je komen bouwen aan toezicht op een veilige en betrouwbare Digitale Infrastructuur in Nederland.
Adviseur Informatiebeveiliging
Je bent een belangrijke speler om invulling te geven aan de gemeentelijke ambities op het gebied van informatiebeveiliging. Deze ambities neem jij op in het Informatie-beveiligingsbeleid Gemeente Zoetermeer. Wil je helpen bij het verbeteren van de informatiebeveiliging in Zoetermeer en het versterken van het cyberbewustzijn binnen onze organisatie? Wacht dan niet en kom ons team informatiebeveiliging versterken!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.