Sind OpenSSL-Zertikate mit Exponent 3 unsicher?

Transkript

1 Sind OpenSSL-Zertikate mit Exponent 3 unsicher? Annie Yousar 2007-January-04 In OpenSSL erzeugt man Zertikate mit RSA-Schlüsseln (zum Beispiel mit 3096 Bit) mit dem Kommando openssl req -x509 -newkey rsa:3096. Dabei wird seit mehreren Versionen für den RSA-Schlüssel 65537=0x10001=F4, die vierte Fermatsche Zahl, als Standard-Exponent benutzt. Man kann aber auch erst den Schlüssel erzeugen openssl genrsa -out newkey.rsa -text 3096 und dann mit openssl req -x509 -key newkey.rsa in ein Zertikat 1 einbinden. Wenn man keine weitere Option angibt, wird bei der Schlüsselerzeugung ebenfalls der Standard-Exponent verwendet. Durch die Angabe der Option -3 kann man auch noch den Exponenten 3 erhalten, andere Exponenten sind aber für die Schlüsselerzeugung nicht vorgesehen. Nach der Sicherheitswarnung 2 werden nun OpenSSL-Zertikate mit RSA-Exponenten 3 und PKCS#1 als unsicher betrachtet. Was dieser von Daniel Bleichenbacher auf der Crypto 2006 vorgestellte Angri darstellt, wird durch diese Sicherheitswarnung nicht richtig beschrieben. Eine bessere Darstellung ist die von Thomas Ptacek (Matasano Team) im Netz 3. Natürlich könnte man für eine Verikation das PKCS#1 Padding vor der Hashwert-Berechnung entfernen. Man muss dann aber seine Länge kontrollieren. Der Angri von Bleichenbacher ist nur deshalb bei OpenSSL und anderen Produkten möglich, weil diese die Prüfung, ob Padding und DigestInfo zusammen auch wirklich alle entschlüsselten RSA-Daten ergeben, nicht implementiert war. Ein stark verkürztes Natürlich ist der hier von mir verwendete Name Yousar ein Pseudonym. Ich wollte schon immer im Alphabet etwas weiter hinten stehen. Man fällt so weniger auf. 1 Dies sind hier der Einfachheit halber gleich selbstsignierte Zertikate. Normalerweise würde man nicht das Zertikat, sondern erst nur einen PKCS#10-Request erzeugen. 2 Es heiÿt darin: OpenSSL before 0.9.7, before 0.9.7k, and before 0.9.8c, when using an RSA key with exponent 3, removes PKCS1 padding before generating a hash, which allows remote attackers to forge a PKCS #1 v1.5 signature that is signed by that RSA key and prevents OpenSSL from correctly verifying X.509 and other certicates that use PKCS#

2 Padding mit zusätzlichen Daten nach der DigestInfo wurde ohne diese Kontrolle nicht als Angri erkannt, sondern als gültige Signatur bewertet. Im Quelltext von openssl/crypto/rsa/rsa_sign.c waren das die Zeilen i=rsa_public_decrypt((int)siglen,sigbuf,s,rsa,rsa_pkcs1_padding); const unsigned char *p=s; sig=d2i_x509_sig(null,&p,(long)i); Sie wurden nun durch eine zusätzliche Verikation /* Excess data can be used to create forgeries */ if(p!= s+i) RSAerr(RSA_F_RSA_VERIFY,RSA_R_BAD_SIGNATURE); goto err; ergänzt. Man prüft nun, ob das Ende s + i der angeblichen Signatur s nach der Transformation von p in die Signatur sig auch tatsächlich erreicht wurde. Nebenbei wird jetzt auch eine Prüfung der (normalerweise mit NULL belegten) Algorithmen-Parameter gemacht, die bisher immer übergangen wurde. An dieser Stelle im DigestInfo hätte man sonst ebenfalls Daten einbringen können, die eine eigentlich ungültige Signatur als korrekte erscheinen lassen. Die von OpenSSL erzeugten Zertikate mit dem RSA-Exponenten 3 sind aber deshalb nicht unsicher, sie wurden bisher nur von OpenSSL falsch geprüft. Dieser Fehler hat bei Zertikaten mit gröÿeren Exponenten auch keine Auswirkungen. Nur beim Exponenten 3 können gefälschte Zertikate und gefälschte Signaturen konstruiert werden, die die bisherige Verikationsroutine von OpenSSL als gültig akzeptiert. Das Problem ist damit behoben. Die vage Unsicherheit bei kleinen Exponenten, die bei der RSA-Verschlüsselung in anderem Zusammenhang seit einigen Jahren schon bekannt ist, sollte uns aber dazu anregen, kleine Exponenten nicht mehr zu verwenden. Der damit verbundene Vorteil einer schnellen Verikation ist sogar im Vergleich mit einem zufälligen 32-Bit Exponenten nicht sehr groÿ. Leider lässt OpenSSL bei der Schlüsselerzeugung in der Form usage: genrsa [args] [numbits] über die Argumente nur 3 oder F4=0x10001 als RSA-Exponenten zu. Wäre es nicht an der Zeit, das zu verändern? Diese Frage stellt sich um so mehr, da in den Version der Typ des öentlichen Exponenten nicht wie vorher unsigned long sondern BIGNUM ist. Es geht erstaunlich einfach. In einer ganz normalen OpenSSL-Distribution muss man in der Datei openssl/apps/gen_rsa.c im Wesentlichen folgende Veränderungen vornehmen: 1. in der Erzeugungsroutine ist if (strcmp(*argv,"-exponent") == 0) BN_hex2bn(&bn,*(++argv)), 2

3 2. entsprechend in der Hilferoutine ist als Erläuterung -exponent x use x (odd hex number) for the E value 3. und in der Ausgaberoutine ist für gröÿere Exponenten BN_print(bio_err,rsa->e); zu ergänzen und vielleicht später die Option -3 endgültig zu streichen. Die vollständige diff-ausgabe ndet man am Ende. Sicher lassen sich noch einige Fehlerfälle besser behandeln. Für den Anfang reicht das jedoch aus. Es gibt damit nun eine neue Option -exponent, mit der man RSA-Schlüssel zum Beispiel für den Exponenten 0x4159="AY" oder auch 0x erzeugen kann. Man beachte dabei, dass der Exponent nicht gerade sein darf, der RSA funktioniert dann nämlich nicht, aber nicht unbedingt eine Primzahl sein muss. Zwar könnte sich daraus eine Verlängerung bei der Schlüsselerzeugung ergeben, man wird das aber normalerweise nicht bemerken. So sind meine eigentlichen Favoriten für die Exponenten 0x416E6E6965="Annie" oder 0x416E6E2059="Ann Y" beides keine Primzahlen. Leider kann ich diese schönen 39-Bit- Exponenten aber nicht in einem Zertikat unter Windows verwenden, da RSA-Schlüssel mit Exponenten, die länger als 32 Bit sind, angeblich 0-Bit-Schlüssel sind. Übrigens ein bekannter Darstellungsfehler, zu dem mir von so genannten Experten mit der Gegenfrage Wer braucht denn eigentlich solche Schlüssel? geantwortet wurde. Ein so erzeugter 1024-Bit-Schlüssel ist -----BEGIN RSA PRIVATE KEY----- MIICXQIBAAKBgQCyfM4hCs9JwwzvAQ+W7gAhNZEVXqQOXuiDgXJc891kkio7VXQ0 IajfNLgxTAr4zGHkcZ75uUXfmuVH6j8nC99Efpj3N2epwRI/iUourXNYY+L9guJp L6fwUbgMpddoRg04FRQn5ExscF6gBiZWxpoGPL8w/8oLq/roB1zIkz/OnwIFQW5u awucgybiht+9psxir36dqswgycb+dzngseh02bb05tn0neafry1zracedcybnwxp WiVJLMzzOsRbcFKCNJnJsSN6edtxN407gdRJdYwMnYeoCat7InPnhH1GzrrlzyLD TXEfymR1Dtx9/g3/GAzCx+BckMlkxGOOjWw9SEanZyBnCY6PZQJBANbsLnYsb3ve 3ObPj2445P/tVRUvgHj7barTK/WHtr8xModWGbjEKnKYSGztHPSPdG8zGHnQsZQV imalz3+k2sucqqdumeonuun5m7roxt0v8t+krksgm5c3jscv23tjecd3rswtre8u oeo/uddqetvlwsdisjwvjry0l1yac6oilmotakbccv1z26nyatjza2j5j5u72yqs cv+qizn5e6+aqlttwejjjohb6slefj/wmhqvqj1b9noyt+rvcuhmacecft9jakbg ZzaXn0Tg7HogvXjP6PnJweNhVYkMo2L9d+xmD8wmMWI01EbnnMKfvt2bG09/kd1b aladqx2zgpy6+lvgofexakbnqkukxj+6dlnycwbjysvswoncjwbhkyy5dvo8giqc JQIa4yP4wpkNj7LX3D8jB26n8u/Fxa9pgzfSijUJnZUq -----END RSA PRIVATE KEY----- Er wird unter OpenSSL auch völlig korrekt angezeigt 4. Den Exponenten "Annie" erhält man aus einem solchen 2048-Bit-Schlüssel durch openssl rsa -outform DER tail -c+142 head -c+5 Die hier verwendete Zahl 142 ergibt sich aus der Header-Länge der Schlüssel-Sequence (4 Byte), der Versionsangabe (3 Byte), der Header-Länge des Moduls (3 Byte), der Modul- Länge selbst (129 Byte) und der Länge des Exponenten-Headers (2 Byte). 4 Das Kommando dafür ist openssl rsa -text -noout. 3

4 Anhang diff -ur openssl-0.9.8d/apps/genrsa.c openssl-0.9.8d-work/apps/genrsa.c --- openssl-0.9.8d/apps/genrsa.c :42: openssl-0.9.8d-work/apps/genrsa.c :15: ,9 +94,8 int ret=1; int i,num=defbits; - long l; + unsigned long l; const EVP_CIPHER *enc=null; - unsigned long f4=rsa_f4; char *outfile=null; char *passargout = NULL, *passout = -108,6 RSA *rsa = RSA_new(); if(!bn!rsa) goto err; + if(!bn_set_word(bn, RSA_F4)) goto err; apps_startup(); BN_GENCB_set(&cb, genrsa_cb, -135,9 outfile= *(++argv); else if (strcmp(*argv,"-3") == 0) - f4=3; + if(!bn_set_word(bn, 3)) goto err; else if (strcmp(*argv,"-f4") == 0 strcmp(*argv,"-f4") == 0) - f4=rsa_f4; + ; + else if (strcmp(*argv,"-exponent") == 0) + if (--argc < 1) goto bad; else ++argv; + if(bn_hex2bn(&bn,*argv)!= strlen(*argv)) + BIO_printf(bio_err,"Wrong hex value\n"); + goto bad; + if (!BN_is_odd(bn)) + BIO_printf(bio_err,"Error, exponent must be an odd number\n"); + goto bad; else if (strcmp(*argv,"-engine") == -206,7 BIO_printf(bio_err," -out file output the key to 'file\n"); BIO_printf(bio_err," -passout arg output file pass phrase source\n"); BIO_printf(bio_err," -f4 use F4 (0x10001) for the E value\n"); 4

5 - BIO_printf(bio_err," -3 use 3 for the E value\n"); + BIO_printf(bio_err," -exponent x use x (odd hex number) for the E value\n"); BIO_printf(bio_err," -engine e use engine e, possibly a hardware -258,7 BIO_printf(bio_err,"Generating RSA private key, %d bit long modulus\n", num); - if(!bn_set_word(bn, f4)!rsa_generate_key_ex(rsa, num, bn, &cb)) + if(!rsa_generate_key_ex(rsa, num, bn, &cb)) goto err; app_rand_write_file(null, -274,7 l+=rsa->e->d[i]; - BIO_printf(bio_err,"e is %ld (0x%lX)\n",l,l); + BIO_printf(bio_err,"e is "); + if (BN_num_bits(rsa->e) <= BN_BITS2) + BIO_printf(bio_err,"%lu (0x%lX)\n",l,l); + else + BIO_printf(bio_err,"0x"); + BN_print(bio_err,rsa->e); + BIO_printf(bio_err," (%d Bits)\n",BN_num_bits(rsa->e)); + PW_CB_DATA cb_data; cb_data.password = passout; 5