image

Apple, GoDaddy en Google maakten fout bij uitgifte certificaten

woensdag 13 maart 2019, 14:19 door Redactie, 7 reacties
Laatst bijgewerkt: 14-03-2019, 09:29

Apple, GoDaddy, Google en verschillende andere certificaatautoriteiten hebben een fout gemaakt bij de uitgifte van honderdduizenden certificaten, waarop ook Logius, de ict-organisatie van het ministerie van Binnenlandse Zaken, een onderzoek heeft aangekondigd.

De fout deed zich voor in de software die voor de uitgifte van certificaten wordt gebruikt. Uitgegeven certificaten, die websites gebruiken voor het opzetten van een beveiligde verbinding, horen over een 64-bit serienummer te beschikken. Deze entropie in het serienummer moet voorkomen dat zogeheten hash collisions zijn te gebruiken om certificaten te vervalsen.

EJBCA, een programma waarmee certificaatautoriteiten certificaten genereren, zorgde ervoor dat het serienummer in werkelijkheid 63-bit was. Dit lijkt een klein verschil, maar het verschil tussen 2^64 en 2^63 is meer dan 9 triljoen, legt beveiligingsonderzoeker Adam Caudill uit. In eerste instantie werd gedacht dat er meer dan 2 miljoen foutieve certificaten waren uitgegeven, maar dat aantal is inmiddels naar beneden bijgesteld.

Volgens GoDaddy zijn er van de foutieve certificaten die het heeft uitgegeven nog 12.000 in omloop, terwijl Apple het op 558.000 actieve certificaten houdt. Google denkt dat er sinds 2016 iets meer dan 100.000 certificaten met een 63-bit serienummer zijn uitgegeven. Apple en Google gebruiken de certificaten met name intern en voor partners.

De richtlijnen voor certificaatautoriteiten stellen dat foutieve certificaten na ontdekking binnen vijf dagen moeten worden ingetrokken. Google stelt dat de meeste certificaten inmiddels zijn ingetrokken en de resterende 400 certificaten later deze maand zullen verlopen of worden ingetrokken. GoDaddy is van plan om alle certificaten in kwestie binnen de komende 30 dagen opnieuw uit te geven. Apple zal naar aanleiding van het voorval ook verschillende maatregelen doorvoeren, zo laat het aan Ars Technica weten.

Logius, dat PKIoverheid-certificaten uitgeeft waar overheidsdiensten gebruik van maken, kwam vandaag met de volgende verklaring: "Vanuit de stelselverantwoordelijkheid van Logius als Policy Authority (PA) voor PKIoverheid is een onderzoek gestart naar de uitgifte van servercertificaten. Dit naar aanleiding van een discussie omtrent een verduidelijking van de interpretatie van een bepaalde eis, waarbij mogelijk niet wordt voldaan aan internationaal geldende eisen. Wij houden u op de hoogte."

Reacties (7)
13-03-2019, 16:23 door Anoniem
RFC5280 https://tools.ietf.org/html/rfc5280#section-4.1.2.2 laat weten:
The serial number MUST be a positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate).
CAs MUST force the serialNumber to be a non-negative integer.

Dit is verwarrend, want er bestaan meerdere methoden om aan te geven of een (binair) getal negatief of positief is.
https://en.wikipedia.org/wiki/Signed_number_representations
Als het dan zonodig duidelijk een positieve integer moet zijn, dan staat daarmee het eerste bit (sign-bit) al helemaal vast. Vervolgens blijven er nog 63 bits over om serienummers mee te genereren.

Verder mag het serienummer ook langer zijn, want:
Given the uniqueness requirements above, serial numbers can be expected to contain long integers.
Certificate users MUST be able to handle serialNumber values up to 20 octets.
Conforming CAs MUST NOT use serialNumber values longer than 20 octets.
20 bytes dus: 160 bits maximaal.

Opvallend is daarna ook de note in RFC5280:
Note: Non-conforming CAs may issue certificates with serial numbers that are negative or zero.
Certificate users SHOULD be prepared to gracefully handle such certificates.
Dus negatieve serienummers mogen niet, maar als iemand ze toch gebruikt moeten ze toch genadig normaal worden verwerkt. Hoe onduidelijk kun je zijn? Dat is haast vragen om wat er nu is geconstateerd.

Vervolgens wordt met een enorm getal (meer dan 9 quintiljoen) groot opgeklopt alsof er met 63 bits te weinig entropie zou zijn om hash collisions te kunnen voorkomen. Ik zou zeggen: probeer er eerst maar eens eentje te vinden,
en ik verwacht dat het ontzettend tegenvalt.
Ga je naar 64 bits, dan heb je nog maar 2 keer zoveel als het aantal mogelijke bit-combinaties als van 63 bits.
Lijkt me niet iets om zo moeilijk en ingewikkeld over te doen om dat spul allemaal in te trekken en te vervangen.
Ze sterven vanzelf uit nadat alle cert-verstrekkers voor nieuwe certificaten naar minimaal 64 bits zijn overgestapt.
Gewoon de resterende looptijd van de certificaten met 63 bits serienummers "gracefully" toestaan,
zoals RFC5280 in feite ook al min of meer had gesteld.
13-03-2019, 16:53 door Anoniem
het verschil tussen 2^64 en 2^63 is meer dan 9 quintiljoen
Bij lange na niet. Het verschil is "slechts" ongeveer 9 triljoen. (Is een vertaalfout: in USA Engels is het namelijk wel "9 quintillion", want daar tellen ze million, billion, trillion, quadrillion, quintillion, ...; wij tellen in NL echter miljoen, miljard, biljoen, biljard, triljoen, ...).

Los daarvan is met zo'n groot getal smijten niet zo relvant, is alleen maar aandachttrekkerij. Want bij brute-force aanvallen moet je het wegzetten tegen rekenkracht en dat zijn ook erg grote getallen. Het betreft gewoon een factor 2 verschil. Dus een brute-froce aanval kost nog maar de helft van de eigenlijk beoogde tijd. En dat zou in de praktijk geen risico mogen zijn, anders is de oorspronkelijk boogde 64 bits al veel te krap gekozen. Maar een probleem is het wel, het is zeker een verzwakking. En het combineren van zulk soort problemen werkt exponentieel, dus met een paar van dit soort problemen bij elkaar kan een brute-force aanval haalbaar worden.
13-03-2019, 23:39 door Anoniem
Even een correctie; een octet is 4 bits en een byte is 8 bits. Het is dus maximaal 20x4 = 80 bits en geen 160 bits.
14-03-2019, 09:01 door Anoniem
Door Anoniem:Opvallend is daarna ook de note in RFC5280:
Note: Non-conforming CAs may issue certificates with serial numbers that are negative or zero.
Certificate users SHOULD be prepared to gracefully handle such certificates.
Dus negatieve serienummers mogen niet, maar als iemand ze toch gebruikt moeten ze toch genadig normaal worden verwerkt. Hoe onduidelijk kun je zijn? Dat is haast vragen om wat er nu is geconstateerd.

Dit is al tientallen jaren gebruikelijk in RFC's. Je MOET je aan bepaalde afspraken houden. Je zou er vervolgens vanuit kunnen gaan dat anderen dat ook doen. Maar iedereen ook weet dat in software fouten zitten of dat sommige partijen RFC's anders uitleggen.

"Gracefull handle" betekent dat je eigen programma niet moet crashen als je een dergelijk certificaat tegenkomt. Je moet een foutmelding genereren zonder dat jouw gebruiker met een hangend systeem opgescheept zit.
"Gracefull handle" betekent niet dat je dat certificaat gewoon moet accepteren alsof het voldoet aan de eisen.

Peter
14-03-2019, 10:55 door Anoniem
Door Anoniem: RFC5280 https://tools.ietf.org/html/rfc5280#section-4.1.2.2 laat weten:
The serial number MUST be a positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate).
CAs MUST force the serialNumber to be a non-negative integer.

Dit is verwarrend, want er bestaan meerdere methoden om aan te geven of een (binair) getal negatief of positief is.
Appendix B (ASN.1 notes) van rfc5280 verduidelijkt het:
CAs MUST force the serialNumber to be a non-negative integer, that is, the sign bit in the DER encoding of the INTEGER value MUST be zero. This can be done by adding a leading (leftmost) `00'H octet if necessary. This removes a potential ambiguity in mapping between a string of octets and an integer value.
Kennelijk heeft men gedacht dat verwarring tussen een signed en unsigned integer kan ontstaan en dat "opgelost" door voor een getal dat unsigned moet zijn een signed integer te kiezen en te eisen dat voorloopnullen in de representatie worden toegevoegd om een positief teken te forceren. Het komt op mij niet over als een oplossing maar op het verplaatsen van de verwarring naar een andere plek. Ik zou zelf eerder kiezen voor een bitpatroon dat exact overeen moet komen ongeacht de vraag of je het als signed of unsigned interpreteert, maar ik zal wel iets relevants missen ;-).
14-03-2019, 11:25 door NonNocere
Hé, hé! Goede inhoudelijk discussie, top.
14-03-2019, 14:58 door Anoniem
Door Anoniem: Even een correctie; een octet is 4 bits en een byte is 8 bits. Het is dus maximaal 20x4 = 80 bits en geen 160 bits.
Nietes.
https://nl.wikipedia.org/wiki/Byte#Octet_(8_bits)
Octet (8 bits)
Om expliciet aan te geven dat men acht bits bedoelt, gebruikt men ook wel het woord octet (bij Philips octad (Engels) of octade (Nederlands)). Mogelijk werd de term byte vermeden omdat het intellectueel eigendom was van IBM.

"Gracefull handle" betekent dat je eigen programma niet moet crashen als je een dergelijk certificaat tegenkomt. Je moet een foutmelding genereren zonder dat jouw gebruiker met een hangend systeem opgescheept zit.
"Gracefull handle" betekent niet dat je dat certificaat gewoon moet accepteren alsof het voldoet aan de eisen.

Peter
Dat zou best kunnen. "once upon a time..." .
Maar...zou men dan bijv. niet beter kunnen spreken over "gracefully handle potential crashes in case of this issue"?

"Gracefully handle" is voor meerdere interpretaties vatbaar. Dus ook hier onduidelijkheid troef.
Het kan zijn dat men in een bepaalde omgeving met een bepaald jargon ergens ooit eens de vaste betekenis A aan gaf,
maar als buiten dat jargon (of na lange tijd waarin taalbetekenissen verschuiven) een uitdrukking ook (of misschien zelfs wel vaker) betekenis B heeft gekregen, dan kan later iemand anders die tekst gemakkelijk anders opvatten.
Daarom kan jargon denk ik beter worden vermeden in dergelijke officiële documenten.

Door Anoniem::Appendix B (ASN.1 notes) van rfc5280 verduidelijkt het:
CAs MUST force the serialNumber to be a non-negative integer, that is, the sign bit in the DER encoding of the INTEGER value MUST be zero. This can be done by adding a leading (leftmost) `00'H octet if necessary. This removes a potential ambiguity in mapping between a string of octets and an integer value.
Kennelijk heeft men gedacht dat verwarring tussen een signed en unsigned integer kan ontstaan en dat "opgelost" door voor een getal dat unsigned moet zijn een signed integer te kiezen en te eisen dat voorloopnullen in de representatie worden toegevoegd om een positief teken te forceren. Het komt op mij niet over als een oplossing maar op het verplaatsen van de verwarring naar een andere plek. Ik zou zelf eerder kiezen voor een bitpatroon dat exact overeen moet komen ongeacht de vraag of je het als signed of unsigned interpreteert, maar ik zal wel iets relevants missen ;-).
Ah juist. Dank! Had ik gemist.
Maar waar ik dan weer onzeker van wordt is de omschrijving:
This can be done by adding a leading (leftmost)`00'H octet if necessary.
Hoezo "if necessary"? Er moest toch zonodig aangegeven worden dat het om een positieve integer ging?

Ho wacht, je zou natuurlijk ook het serienummer zelf altijd met een 0 -signbit kunnen laten beginnen
gevolgd door een serienummer van 63 bits....... ; )
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.