Dit is niet de juiste constatering. Het zijn nog steeds 64-bit serienummers.
Maar omdat het eerste bit steeds hetzelfde blijft, is er effectief sprake van 63-bit (2 tot de macht 63 verschillende serienummers). M.a.w.: de entropie halveert.
Dus er is sprake van 64 bit serienummers, maar met slechts 63 bit entropie omdat 1 bit onveranderlijk is.

Bron: https://arstechnica.com/information-technology/2019/03/godaddy-apple-and-google-goof-results-in-1-million-misissued-certificates/:

Dat er geen sprake is van een beveiligingsprobleem onderschrijf ik voor 100%.

Dat er dan toch certificaten moeten worden vervangen, vind ik onbegrijpelijk. Dit leidt tot onnodige risico's en verspilling van tijd en geld. Misschien een goed idee om meteen overal EV certificaten in te zetten?

Zullen we dat even niet doen? EV voegt letterlijk niets toe behalve wat extra centjes voor de certificaat boeren. Browsermakers & bedrijven zien dat gelukkig in en zijn alweer gestopt of stoppen met EV. #ByebyeEV..

Wordt niet gedaan ivm ondersteuning oude Android versies

Het is zeker verspilling, maar ik denk dat de minister geen keus heeft. In zijn brief schrijft hij:


Als hij het niet laat vervangen loopt hij het risico dat browsers deze certificaten als ongeldig gaan markeren.

Het woord 64 bit komt overigens niet in die brief voor. En die geciteerde fout over 63 bit, uit de eerste reactie, is inmiddels door de redactie gecorrigeerd.

pgp 2.6.2 had een probleem met 2048 bit RSA sleutels. Deze kon deze versie niet aanmaken.
pgp 2.6.3i kon wel 2048 bit RSA sleutels aanmaken. Deze versie was de internationale versie van PGP die geëxporteerd was in boekvorm.

Toch waren de 2047 bit RSA sleutels van 2.6.2 geen probleem voor de community toen en was dit lang de populairste versie voor Amerika. http://www.mccune.cc/PGPpage2.htm#2047

Er is nu geen beveiligingsprobleem, maar als SHA256 morgen zou worden gekraakt kan het wel plotseling ontstaan.
Zoiets schijnt vroeger eens te zijn gebeurd te zijn toen hier nog MD5 voor werd toegepast en MD5 werd gekraakt.

Daarnaast bestaan er naast de RFCs actuele zogenaamde Baseline Requirements: afgesproken regels (actueler dan een RFC die er over gaat) waar een en ander aan moet voldoen.
Daarin stond o.a. dat voor het serienummer minimaal 64 bits moeten worden gegenereerd door de random generator.
Dus het serienummer moet volgens deze requirements minimaal een entropie van 64 bits hebben.
(men weigert deze regel te versoepelen, hoewel de oorspronkelijke RFC5280 hier misschien nog wel enige ruimt voor laat)

Waar we in feite mee te maken hebben, is dat de regels simpelweg niet duidelijk genoeg waren gesteld!
Zo staat bijv. ook nergens duidelijk beschreven of de DER-encoding dient te worden toegepast vóór of na serienummer randomisatie. (Godaddy schijnt hiermee de mist in te zijn gegaan)

En dat lijkt me dan ook de allerbelangrijkste les van in deze kwestie:
laat een gezaghebbende organisatie a.u.b. voortaan onbetwistbaar de regels en hun exacte bedoeling formuleren.

EV voegt juist heel veel toe: browsers laten geen verschil zien tussen DV speelgoedcertificaten en OV certificaten waardoor het stikt van de phishing sites. Je hebt er dus niets aan dat voor PKI overheid veel strengere authenticatie-eisen gelden dan bij gemiddelde OV certificaten. De stap van PKI overheid OV naar EV certs is (gezien genoemde eisen) maar klein, en een groot prijsverschil tussen PKI-Overheid OV en EV certificaten lijkt mij dan ook niet gerechtvaardigd.

Zijn EV-certificaten perfect? Nee. Zijn ze betrouwbaarder dan DV certificaten? Die vraag mag de lezer zelf beantwoorden.

Bron?

We gaan mierenneuken over 1 totaal irrelevante bit in certificaten, maar blijven wel zwaar lekke stokoude Android versies ondersteunen - met bijbehorende support voor zwakke ciphersuites, gekraakte hashes en verouderde TLS versies (waardoor iedereen risico's loopt)? Krankzinnig...

Het is je in de andere thread ook een paar keer uitgelegd , en de toelichting van de minister zegt het feitelijk ook : omdat dat nu eenmaal in de eisen staat waaraan een certificaat moet voldoen, en CA's die zich daar niet aan houden letterlijk het risico lopen om trusted-CA af te zijn.
En nogmaals, dat heeft inderdaad heel weinig te maken met een echt security risico.

Je bent, zo te lezen , een erg capabele techneut, maar als je die oogkleppen voor alle niet-technische requirements niet leert afzetten blijf je in elk soort organisatie van enige schaal in je hokje zitten en wordt je bij veel beslissingen genegeerd omdat je het totaal plaatje niet wilt of kunt zien.

Dat maar 63 van de vereiste 64 bits gebruikt worden, lijkt mij wel degelijk een technische requirement.

Stel dat een kwaadwillende in staat is om een SHA-256 hash collision te generen, en in staat is om elke microseconde een certificaat aan te vragen (bij één CSP). Bij 63 perfecte random bits zal die kwaadwillende gemiddeld 2^62 pogingen moeten doen om de gewenste hash te verkrijgen - en is daardoor gemiddeld ruim 146000 jaar bezig (zie ook mijn uitleg in https://www.security.nl/posting/601697).

Los van het feit dat, voor zover mij bekend, SHA-256 collisions nog niet binnen afzienbare rekentijd te genereren zijn, duurt het aanvragen van een PKI-overheid certificaat extreem veel langer dan 1 microseconde - waardoor datum/tijdvelden ook in lastig te voorspellen waarden zullen wijzigen. En als die 63- of 64-bits random waarde al dit leed daadwerkelijk moet voorkomen, gaat die ene bit (een factor 2 in tijd) je echt niet redden. Technisch gezien is het risico dus verwaarloosbaar.

De enige twee risico's die ik zie is dat 1) beslissers bij verschillende organisaties zich niet goed laten adviseren (of er garen bij spinnen) en elkaar gek maken, en 2) dat tijd en geld uit het IB-budget van inzetters van deze certificaten worden verspild terwijl dit altijd schaarse resources zijn (en je er echt mee had kunnen beveiligen).

Overigens is het niet zo dat wat ik (zoals altijd op persoonlijke titel) op security.nl schrijf, ook altijd is wat ik mijn opdrachtgevers adviseer; als zij mij om een zorgvuldige analyse van de risico's voor hun organisatie vragen, krijgen zij dat - ook als e.e.a. niet overeenkomt met mijn persoonlijke mening.

Ik hoop dat de staatssecretaris zich gesterkt voelt door bijdragen als die van mij, waarin ik uitleg waarom er geen sprake is van een beveiligingsrisico (geen Diginotar-achtig drama dus, maar drukte om niks - dus verspilling).

Jouw advies aan Knops zou zeker zijn om zich erbij neer te legen dat alle "63-bit certificaten" met gillende sirenes moeten worden vervangen?

Beste Bitwiper, ik lees mee en volg je een heel eind, maar...
volgens https://www.securityweek.com/mozilla-wants-64-bits-entropy-certificate-serial-numbers is Mozilla per 1 juni 2017 al overgegaan tot de eis van een minimum van 64 bits entropie voor het serienummer met het oog op hash collisions.

En met de hete adem van mogelijke capriolen van het shady Darkmatter in de nek (bijv.: "als er niets aan wordt gedaan gaan wij ons inspannen om jullie te laten zien dat het kan worden misbruikt") wordt het dan wel erg moeilijk om 2 jaar later te zeggen dat 63 bits aan entropie door de vingers wordt gezien.

Dat is zo , en ik ben het ook al de hele tijd met je eens dat er op dat probleem geen reëel security risico argument te baseren valt.

[knip wederom uitleg over hash collisions. Ja - ik zie óók geen bruikbaar aanvalsscenario, en de RFC/BR auteurs waren blijkbaar erg vaag over het soort scenario dat ze ermee mitigeerden]


De Stas heeft zich , zo te lezen, uistekend laten adviseren. Er is geen claim van een security risico, en wel het punt van de betrouwbaarheid/reputatie van de CA.

En als je ziet in de discussie's dat dit punt gevonden werd toen gezocht werd naar minpunten van Darkmatter is het gewoon geen optie meer om te zeggen 'wij voldoen gewoon niet aan de baseline requirements omdat wij die bij nader inzien hier onzinnig vinden.'


Ah, ik kan je natuurlijk alleen inschatten op grond van wat je hier schrijft.
Degenen die ik zie acteren zoals je bijdrage geschreven was zijn degenen wiens input ik vaak maar zeer beperkt of zeer afgebakend gevraagd zie worden. (en die dan ook op een borrel tegen me aan staan te zeuren dat 'het management niet naar ze wil luisteren' - nou, dat gevoel heb ik een stuk minder last van )


Natuurlijk niet. Ik heb nooit gezegd of gedacht dat er een security risico was, alleen de onmogelijkheid om in de context van de RFC en BR, en het uit de root store willen trappen van Darkmatter met welk excuus dan ook - je ogen te sluiten en helemaal geen actie te ondernemen omdat je dit punt van de BR onzinnig vindt en je fout ermee niet wilt herstellen.

Zo te lezen heeft hij het advies gekregen wat ik ook gegeven zou hebben - kondig aan dat je gaat vervangen, en zoek steun/acceptatie in het CA forum om dat over langere termijn te doen in plaats van de termijn van een gillende sirene actie.

De prioriteit voor de Stas is gewoon heel logisch en duidelijk:
De acceptie van de NL Overheids CA in de browsers mag onder geen beding ter discussie komen te staan.
En als dat een re-issue kost van 22K ouf-of-spec certificaten kost dan is dat maar zo - maar liever wel verspreid over een langere termijn als we dat geaccepteerd kunnen krijgen.

Zo interpreteer ik de gemaakte keuzes en mededelingen, en daar ben ik het ook helemaal mee eens.

Vermoedelijk heeft iemand een vinger in de lucht gehouden en gezegd "64 bits randomness is meer dan genoeg om hash-clash aanvallen te pareren en maakt tegelijkertijd certificaatbestanden niet onnodig groot". Toen heeft een idioot opgeschreven dat het om een non-negative integer van minstens 64 bits moet gaan, en ofwel geen enkele reviewer heeft daar bezwaar tegen gemaakt, ofwel een nog grotere idioot heeft besloten om niets met dat commentaar te doen. Precies aan deze eis voldoen de gewraakte certificaten, want in een signed integer van 64 bits is 1 bit het "sign-bit". En als je eist dat deze getallen "signed" zijn, heeft dat bit altijd dezelfde waarde en draagt dus niet bij aan de randomness.

Is dat qua security een probleem? Nee (zie mijn eerdere toelichtingen). Wat is dan wel het probleem? Dat er drie soorten drammers bestaan die en/of:
1) Niet (willen) snappen dat er geen probleem is en denken, waar rook is, is vuur;
2) Willen dat, ongeacht de relevantie van eisen, certificaten -koste wat het kost- toch exact voldoen aan de eisen;
3) Op de een of andere manier hun zakken willen vullen.

Ah een doemdenker.

DarkMatter blijft een issue zolang QuoVadis het door hen uitgegeven trusted CA-certificaat niet intrekt of als een DarkMatter rootcert in relevante certificate stores wordt opgenomen. Zolang DarkMatter zelf certificaten uitgeeft, is zo'n random nummer totaal irrelevant, want dit hebben zij zelf onder controle.

De reden dat de certificaat (zinloos) vervangen moeten worden is dat Mozilla ze anders niet meer als 'veilig' ziet (CAB richtlijnen zijn 64 bit). Hiervoor hebben ze een heel kort tijdswindow gezet. Ze zijn trouwens de aanstichter van deze gehele situatie.

Vervanging van de certificaten levert een serieus operationeel risico op, terwijl het entropie risico op zichzelf echt beperkt is...

Dat geloof ik niet.
Eerder heeft iemand RFC5280 gelezen en gedacht dat sindsdien alweer jaren waren verstreken en gezien dat niet alle certificaatverstrekkers aan RTFi doen ('Read The F.... instructions/requirements).
Hierdoor neemt het risico op kwetsbaarheid toe, enerzijds vanwege die nalatigheid en anderzijds wegens toename van kennis en hardwaresnelheid van hacktools.
Ook zal men zich toen hebben gerealiseerd hoe er voor MD5 en SHA1 opeens veel sneller een collision kon worden gevonden. En dat zoiets op elk ogenblik met elke hash zou kunnen gebeuren. Dus ook met SHA256.
En dat dit zou kunnen leiden tot misbruik van namaakcertificaten op nepsites.
En dat er kwaadwillende partijen kunnen zijn die een gevonden hack op SHA256 niet meteen naar buiten zullen communiceren, maar het zelf kwaadaardig uitbuiten.

Het enige wat dan (aanvankelijk) nog enigszins hiertegen zou kunnen beschermen, is de mate van complexiteit van de hash-operand. Dit wil dus zeggen: de (verplichte) lengte van het serienummer.
Want dit bemoeilijkt normaalgesproken het vinden van een collision, oftewel verlengt de gemiddelde tijdsduur van het vinden/berekenen van een hash-collision (al of niet met een wat versnellende crack) aanzienlijk.

Conform RFC5280 heeft men daarom in 2017 blijkbaar nog eens in de Basic Requirements benadrukt dat serienummers toch echt uit minimaal 64 random bits moeten bestaan.
En voor wat betreft het signbit gaf RFC5280 destijds al aan:
Hieruit blijkt afdoende dat het de bedoeling was dat het signbit zelf geen deel uitmaakt van de 64 bits,
maar een apart item is als een octet (=byte) '00H' die aan het 64 bits-serienummer vooraf gaat.
Dit in een poging om (zoals het RFC-document zegt) dubbelzinnigheid ('ambiguity') te vermijden
voor wat betreft welk deel bij het (64-bits) serienummer hoort en wat de sign moet voorstellen.

Lastiger dan je denkt. Om te beginnen hoeven serienummers alleen uniek te zijn binnen één en dezelfde CA.

Kan je nog tegenwerpen dat Darkmatter vast wel certificaten met een andere issuernaam zou kunnen genereren.
Maar ten eerste is dit niet toegestaan, en ten tweede zet Darkmatter dan (á la Diginotar) alle privileges en respect op het spel zodra wordt ontdekt dat ze hiermee sjoemelen.
Daarentegen is het aantonen dat het kraken van de SHA2 hash kan worden bespoedigd en een gevaar zou kunnen opleveren voor ssl-certificaten niet strafbaar.

Doemdenker ben ik overigens niet, zoals gezegd volg ik je een heel eind. Ik ben in ieder geval met je eens dat er momenteel nog geen acuut security gevaar is. Maar niemand weet wat de (nabije?) toekomst hierin wel of niet zal veranderen,
want het is onvoorspelbaar wanneer precies kwetsbaarheden in een hash worden ontdekt.
Verder hebben regels en afspraken een achtergrond waar over is nagedacht (ook al doorzien wij dit niet altijd meteen)
en zijn dan ook bedoeld om te handhaven.
Ik verwacht eerlijk gezegd dan ook dat Mozilla Firefox binnenkort zal aanpassen om op deze certificaten te attenderen,
en ze na verloop van tijd zal verbieden.(blokkade met foutmelding vanuit de browser)


Tegen deze achtergrond vind ik het wel plausibel en verstandig om zulke certificaten toch maar voortijdig te vervangen.
De vraag is overigens of en in hoeverre falende certificaatautoriteiten dit niet behoren te vergoeden,
omdat ze zelf in gebreke waren door zich niet aan de gestelde requirements te houden.

Wellicht kijk ik er overheen, maar nergens in https://tools.ietf.org/html/rfc5280, noch in de errata, zie ik een eis voor een minimale lengte van het certificaat-serienummer (wel een maximale lengte, nl. 20 octets).

Wel zie ik, m.b.t. dat serienummer, de volgende logische eis:
Bizar genoeg ontbreekt die eis in de laatste Baseline Requirements in https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.4.pdf (die wel klip en klaar 64 bits randomness vereist - doch zonder argumentatie waarom 64), en uit dat oogpunt zou 64 bits wel eens te weinig kunnen zijn (met name als die CSPRGN niet zo S is als je zou willen). Ik vind het van de zotte dat je kennelijk de "best of both worlds" moet combineren om fatsoenlijke certificaten te verkrijgen. Wat een puinhoop...

Klopt, maar zoals ik al schreef, ik zie in RFC5280 geen minimale lengte vereist worden.

In principe kan een (foute medewerker van een) CSP samenspannen met een klant die een hash-collission heeft bewerkstelligd, in een poging om bij ontdekking de verdenking van de (medewerker van de) CSP weg te nemen; de klant levert dan gewoon het CSR en twee verschillende serienummers aan (die natuurlijk niet van random zijn te onderscheiden).

Maar sowieso is dit een non-issue, als een (medewerker met voldoende privileges van een) CSP fout wil, kan deze naar believen CSR's in certificaten omzetten (en heeft zelfs carte blanche als de "klant" het genereren van het sleutelpaar aan die CSP overlaat).

Uhhh de hele discussie DarkMatter speelt omdat, naar verluidt, DarkMatter fake certificaten uitgeeft om TLS verbindingen te onderscheppen, eveneens naar verluidt in opdracht van regimes die er andere normen en waarden op nahouden dan de meeste Nederlanders (persoonlijk vind ik dat fouter dan Diginotar).

Als een regime persé wil onderscheppen, dwingen ze hun burgers maar om een rootcert te installeren dat dit mogelijk maakt - in plaats van de hele wereld met risico's op te zadelen (zoals hier vermeld: https://www.security.nl/posting/453638/Kazakhstan+eist+aftap+gebruiker).

So what? Zoals ik al meermaals heb aangegeven, gaat die ene bit je niet redden als 63 te weinig zou zijn.

Ik heb er dan ook geen enkel bezwaar tegen als certificaten, uitgegeven na het bekend worden van deze issue, zouden worden geblokkeerd door browsers en/of besturingssystemen. Waar ik bezwaar tegen maak is het nodeloos vervangen van bestaande certificaten, namelijk die waar geen aantoonbare risico's voor bestaan.

In 2008 heeft RFC5280 wel een (verplichte) 'Upper Bound' van 8 octets (64 bits) vermeld. (ASN.1 -notatie)
Beetje raar, want elders geven ze dus aan dat 20 octets de maximum lengte is. Snap jij daar wat van?

Maar dan nog staat het sinds 2016 dus wél heel duidelijk in de Baseline Requirements. Bovendien staat hierin:

Nee hoor, zie blz.42:
Wordt ook vermeld in het revisie-overzicht (paragraaf 1.2.1.) en het overzicht van Relevant Dates (paragraaf 1.2.2.)

Frauderen betekent al snel: out of business en gezichtsverlies en daar heeft men vooral zichzelf mee.
Meestal komt de waarheid boven tafel, vooral als het op grotere schaal gebeurt. Dat zet er een natuurlijke rem op.

Dat was in zijn context genomen niet de boodschap. Ik bedoelde dat er geen vuiltje aan de lucht is als iemand gemotiveerd raakt en aantoont dat SHA2 kwetsbaar is, maar wel als iemand opzettelijk fraudeert met certificaten of anderszins op zijn muil gaat zoals bijv. Diginotar.

Je bedoelt dat je kan aantonen dat het risico wat groter kan zijn, maar verre van noemenswaardig?
Kijk, voor privégebruik zonder dat iemand anders er last van heeft vind ik het prima, maar als professional met zo'n beetje
het hele Nederlandse volk als gebruiker kan je dat niet maken. Al was het alleen maar om alle twijfels weg te nemen.
De certificaatautoriteit neemt bovendien contact op. Wat zou je dan zeggen: "Rot op, ik vind het zo wel veilig genoeg?"

En als je de bestaande regelgeving nu terzijde schuift, schept dit een precedent voor toekomstige problemen die erger kunnen zijn. Zoals bijv. meer mensen die wel even naar eigen inzicht zullen bepalen of iets wel veilig genoeg is of niet,
en CA s die geen reden (meer) zien om zich druk maken om de Baseline Rules.
(orde en netheid hebben ook zo hun voordelen in een complexe wereld, al lijkt het soms kinderachtig)

Als je bedoelt:
Daar bedoelen ze, naar ik aannneem, mee dat de constante "ub-serial-number" van het type integer is en de waarde 64 heeft. Die constante komt verderop terug in:
Het doel lijkt te zijn dat certificaatverwerkende software een "number" van 64 karakters moet kunnen afdrukken.

Dat lijkt overigens zelfs genoeg voor een decimale signed integer van 160 bits (20 octets), althans volgens https://www.mobilefish.com/services/big_number/big_number.php is hexadecimaal 7F FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF gelijk aan decimaal 730750818665451459101842416358141509827966271487 - een getal van 48 cijfers als ik goed tel.

Inderdaad. Maar in datzelfde document staat geen eis dat het serienummer uniek moet zijn. Formeel is er dus geen reden om certificaten in te trekken als wordt ontdekt dat een CSP deze CSPRNG https://xkcd.com/221/ of deze CSRPNG https://dilbert.com/strip/2001-10-25, of -realistischer- https://www.debian.org/security/2008/dsa-1571 of iets als https://en.wikipedia.org/wiki/Dual_EC_DRBG gebruikt (dat het ontzettend moeilijk is om cryptographically secure random numbers te genereren blijkt uit het grote aantal gerapporteerde kwetsbaarheden als gevolg van onjuiste ontwerpen, verkeerde implementaties en bewust aangebrachte backdoors - reken je niet rijk, mede omdat testen op de kwaliteit van randomness een soort black magic is).

Als je een minimale afwijking van eisen ontdekt die overduidelijk geen impact heeft op security, ben je een drammer als je dan toch je gelijk wilt halen. Dat heeft niets met realiteitszin en proportionaliteit te maken. Sterker, het voegt m.i. nog een spijker toe aan de doodskist met het imago van de certificatenbranche.

Dat is geen eis voor uniciteit, en 63 bits is inderdaad te weinig om dat redelijkerwijs te garanderen. Maar 64 bits is ook veel te weinig, namelijk decimaal 18446744073709551615 mogelijkheden, en belangrijk: door de Birthday Paradox is de kans groter dan je zou verwachten dat je tweemaal hetzelfde nummer genereert.

Al jaren geldt de aanbeveling van het equivalent van minimaal 128 bits in de cryptografie. En dus is het bespottelijk dat de eis voor uniciteit ontbreekt in de Baseline Requirements van CAB-Forum, want die vind ik belangrijker dan geneuzel over het aantal bits randomness om hash-clash aanvallen te voorkomen.

Ter illustratie: blind TCP secuence number attacks zie ik nooit gerapporteerd worden, en die zijn maar 32 bits. En als die al gerapporteerd zouden worden, komt dat doordat geen goede CSPRNG gebruikt is. Zoals Michal Zalewski daarover (lang geleden) schreef in http://lcamtuf.coredump.cx/oldtcp/tcpseq.html:
(FWIW: de birthday paradox speelt hier niet).

Met andere woorden: 63 bits, mits afkomstig uit een betrouwbare CSPRNG, zijn meer dan voldoende om hash-clash aanvallen te pareren. 64 bits is echter veel te weinig om uniciteit te garanderen, en daarom zal een ontwerper en/of implementor van software die certificaat-serienummers genereert, de uniciteit-eis uit RFC5280 serieus moeten nemen.

PS we zijn het niet met elkaar eens, maar wel een nette discussie zo!

Het serienummer wordt gegenereerd door een CSPRNG, dat staat voor 'Cryptographically Secure Pseudo Random Generator'. Deze stelt hoge eisen aan de entropy van de gegenereerde waarden en dus ook aan uniciteit. (niet te vergelijken met Birthday Paradox)
Verder houdt een CA (als het goed is) volgens mij een database bij van uitgegeven certificaten en kan elk nieuw gegenereerd serienummer daarmee worden vergeleken of het heel misschien al eerder was uitgegeven.

Echter een kwetsbaarheid die men op het oog heeft, is een certificaat met andere data maar dezelfde signature
(= hash van certificaatdata) zodat je browser er niet over mekkert en alles net echt lijkt.
Dit kan met behulp van een hash-collision.
Men kan hiermee een vals certificaat laten lijken op een bestaand certificaat, maar bijv. met een andere uitgekiende uitgiftedatum of ander serienummer, zodanig dat de hash over de certificaatdata resulteert in de hash-collision en dus de signature klopt en de browser niet waarschuwt.
Maar van tevoren moet dit al heel goed zijn uitgekiend omdat de data anders niet resulteert in de gewenste hash-collision. Toen men nog met MD5 werkte en MD5 was gekraakt, is het dus gelukt om deze aanval succesvol uit te voeren.

Mede daarom zijn serienummers niet meer sequentieel maar random, want bij sequentieel zou men kunnen wachen totdat de berekende waarde die het serienummer voor deze aanval zou moeten hebben aan de beurt is, en tegen die tijd een zootje certificaten aanschaffen. Ook lekt een CA met sequentiële certificaten business informatie. (nl. hoeveel certificaten de CA heeft uitgegeven/verkocht).
Men verwacht dat een zelfde soort aanval elk moment zou kunnen gebeuren bij certificaten met SHA1 hash.
(vooral intermediate certificaten kunnen behoorlijk oud zijn)
In de huidig uitgegeven certificaten gebruikt men de laatste tijd SHA256,
maar vroeg of laat kan dit type hash ook kwetsbaar worden, dat weten we nu niet.

Ja dank. Het is misschien maar wat je het maar wat je het belangrijkste vindt: security-risico, inspanning en geld,
of goed gereguleerde CA's die afrekenen met hun brakke verleden (CA's zijn lange tijd een ramp geweest in hun gedrag)
en zich ook werkelijk houden aan alle regels waar men het toch samen over eens was.

Maar omdat het volgens die afspraken niet onze verantwoordelijkheid is, maar die van de CA's om indien nodig certificaten in te trekken, hoefden wij ons daar eigenlijk niet druk over te maken. ;)

Met alle respect, maar een CSPRNG houdt zich helemaal nergens aan. Elke keer dat een perfecte 64 bit CSPRNG een random getal genereert, is de kans 1 : 18446744073709551615 dat het resultaat 42 is.

De birthday paradox leidt ertoe dat in bijvoorbeeld een willekeurige schoolklas (van zeg 25 leerlingen) er meestal wel 2 leerlingen zitten die op dezelfde dag trakteren omdat ze jarig zijn (op dezelde dag dus). Door diezelfde birthday paradox is de kans dat, als je met een CSPRNG "serie"nummers voor bijv. 1000 certificaten hebt gegenereerd, er twee dezelfde nummers bij zitten, een stuk groter dan die 1 : 18446744073709551615. En je dus, veel veel eerder dan na 18446744073709551615 certificaten, met collisions (identieke "serie"nummers bedoel ik) te maken krijgt. Gooi maar eens zes keer met een dobbelsteen: de kans dat je dan alle zes de mogelijkheden hebt gezien, is klein.

Precies daarom verwees ik naar de XKCD en Dilbert strips (naast naar beschrijvingen van falende CSPRNG's). Met name de laatste woorden in die Dilbert strip (na "nine, nine, nine, nine, nine, nine" als outputs en de vraag "Are you sure that's random?") slaan de spijker op z'n kop: "That's the problem with randomness: you can never be sure".

Maar de eis daarvoor ontbreekt in de requirements van het CAB Forum, terwijl die wel in de RFC staat. Tegen het ontbreken van die eis in eerstgenoemde document maak ik bezwaar.

Het primaire doel van een serienummer is uniciteit, en dat dwing je af door sequentieel nummers uit te geven en nooit her te gebruiken. Door van dat "serie"nummer een random getal te maken, zonder erbij te eisen dat het uniek moet zijn, loop je het risico dat implementors dat primaire doel vergeten - omdat ze (net als jij) denken dat een CSPRNG uniciteit garandeert.

Sorry maar dit is een herhaling van zetten. Ik heb uitvoerig beargumenteerd waarom dit risico niet speelt.

Excuseer,
https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator/:


Let op de doelomschrijving van de B.R. (waaronder de huidige laatste versie 1.6.4) in paragraaf 1.4.1.:
Het doel van de B.R. is dus niet "complete vervanging van alle eerdere documenten".
Hoewel in de B.R. wel updates kunnen worden genoemd van eerdere policies die voorheen gebruikelijk waren in eerdere officiële documenten. Daarbij omvat de B.R. een referentielijst in paragraaf 1.6.3. van andere bestaande documenten.
En in paragraaf 1.2.2. staat een duidelijk overzicht van "Relevant dates" waarop door de B.R. een nieuwe rule moet zijn ingevoerd of aangepast.


Het was geen zet, maar een nadere verklaring van waar het precies in het verleden al eens mis is gegaan
en hoe daarbij o.a. het serienummer was betrokken.
We waren het er al over eens dat een dergelijk probleem in de huidige situatie niet speelt.
Of er nog andere mogelijk geïntroduceerde sjoemelarijen door teweeg zouden kunnen worden gebracht wordt niet altijd meteen overzien: je weet maar nooit hoe een koe een haas vangt.
(of toch wel?... https://zuidholland.partijvoordedieren.nl/nieuws/hoe-een-koe-een-haas-vangt)

Last but not least: een instantie maakt zijn eigen regels hilarisch als men ze zelf niet eens serieus neemt.
Zoals ik eerder heb aangegeven kan dit een ongewenste precedent voor de toekomst worden.
Volgens het doel van de B.R. neemt men dus elke twijfel over CA-vertrekkers en certificaatbetrouwbaarheid weg door ze te vervangen.

Het gaat om vertrouwen en geloofwaardigheid van de CA's en hun produkten, en zie: wtf bijna 3 jaar na dato bleken een aantal CA's hun huiswerk weer eens niet goed te hebben gedaan. En niet de geringsten, Google, Apple...
Het gaat nu dus ook om CA's voortaan beter bij de les te dwingen.
Niet alleen voor wat betreft security, maar ook omwille van imago en betrouwbaarheidsuitstraling. Want stel men komt er mee weg, dan maken CA's zich niet zo druk over B.R. Verder had niemand bezwaar gemaakt toen die regel van minstens 64 bits voor het serienummer aan de orde was. Hoe serieus en betrokken moet je de CA's dan nemen? (en de volgende keer zou het om een ernstiger afwijking kunnen gaan, tenzij CA's n.a.v. het huidige incident beter hebben leren opletten)

De URL die je noemt is incorrect, deze moet zijn: https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator (zonder trailing slash). Ook de tekst die je gequote hebt, klopt niet. Ik zie staan: Die tekst, vooral de waarschuwing, is grotendeels afkomstig van "CodesInChaos", zie haar of zijn antwoord in https://crypto.stackexchange.com/questions/25759/how-can-a-block-cipher-in-counter-mode-be-a-reasonable-prng-when-its-a-prp.

Anyway, in de basis heb je gelijk (met een "maar"). Omdat encryptie lossless moet zijn (decryptie moet je altijd het origineel geven) zal een block cipher met een block-lengte van 64 bits, gegeven een willekeurig gekozen sleutel, voor elk van de unsigned inputs 0 t/m 18446744073709551615 een unieke output geven met waardes tussen 0 en 18446744073709551615 (beide inclusief). Je kunt daarbij overigens niet uitsluiten dat er outputs bij zitten die identiek zijn aan de input (maar dat lijkt me in dit geval geen probleem).

Het probleem is dat 64bit block ciphers niet meer helemaal "cryptographically secure" zijn. In https://blog.cryptographyengineering.com/2016/08/24/attack-of-week-64-bit-ciphers-in-tls/ legt Matthew Green uit waarom 64bit block size ciphers in CBC mode niet veilig meer zijn (gebaseerd op onderzoek van Karthikeyan Bhargavan en Gaëtan Leurent, zie https://sweet32.info/).

Ik ben geen cryptografie-expert, dus wellicht begeef ik me op glad eis. Maar gevoelsmatig is het publiceren van vele die versleutelde "counter-values" (die steeds met dezelfde key moeten zijn versleuteld om uniek te zijn!) geen goed idee: het zou mij niet verbazen als iemand die alle (of veel) certificaten verzamelt (en dus de "random serial numbers" kent) de key zal kunnen brute-forcen (vereenvoudigd als de aanvaller weet dat bijv. DES als cipher wordt gebruikt en er een counter wordt gebruikt die steeds met 1 opgehoogd wordt). Als dat lukt ben je weer bij af (had je net zo goed een sequentieel serienummer kunnen gebruiken en loop je risico zodra de gebruikte hash (in de signature) collission-gevoelig blijkt te zijn).

Persoonlijk zou ik dit daarom nooit gebruiken (je kunt wel bijv. AES-128 gebruiken en de helft van de bits als 64-bit serienummer opnemen, maar dat is niet meer gegarandeerd uniek - je zult dan gewoon een nieuwe random moeten genereren als je een serienummer vindt dat je al eerder hebt gebruikt).

Aanvulling: dank dat je dit aanstipte. Het feit dat een ding dat een reproduceerbare reeks unieke getallen produceert een CSPRNG mag worden genoemd, had ik nog niet zo op mijn netvlies staan (echt random is de output natuurlijk niet).

Ik begrijp niet waar je het over hebt. Er staat geen eis voor uniciteit van het serienummer in de B.R.

Dat is jouw mening.

Mijn mening is dat er sprake is van een kleine afwijking van een arbitrair vastgestelde grenswaarde waarvan mensen die het begrijpen, het erover eens zijn dat er, bij 63 ipv 64 bits, geen beveiligingsrisico bestaat - zeker niet voor reeds uitgegeven certificaten. En dus dat deze instantie zich hilarisch maakt als zij erop blijft staan dat alle reeds uitgegeven certificaten met dit "geen-probleem" worden vervangen.

Hoewel je met 1km/h te hard rijden de regels overtreedt en de remweg wordt vergroot, krijg je er geen bekeuring voor. Dit schept in de praktijk ook geen precedent voor automobilisten die boven de marge uitkomen; zij krijgen wel een prent.

Was een Copy - paste uit zoekmachine, gehaald uit een link die te koop stond.
Dus ik dacht misschien beter de wiki-link te noemen, waar in essentie (naar zijn betekenis) hetzelfde in staat
hoewel inderdaad in iets andere bewoordingen (en bovendien uitgebreider voor de liefhebbers)
Jouw aanzet waar ik op reageerde was dat er een birthday paradox zou zijn die de uniciteit aantast.
Ik liet je in mijn reactie/link zien hoe het mogelijk is om een CSPRNG te maken en uniciteit te behouden. That's all.
Maar dank voor je nadere uitwerking.

CBC heb je volgens mij niets mee te maken als je serienummers genereert met een block-cipher.
Je werkt dan immers in CTR (Counter) mode, niet in CBC mode.[/quote]
Nee dat klopt. Want het doel van de B.R. is niet alles herhalen wat al ergens in een Reference staat en ongewijzigd blijft.
(daarom noemde ik dus de References paragraaf)
En actiepunten die wel nieuw zijn of een aanpassing van een oud voorschrift is, hoort in de lijst van "Relevant dates" te staan.

Dat heeft slechts te maken met de maximale meetfout. Die marge trekken ze van de gemeten snelheid af.
Dus:
https://www.om.nl/onderwerpen/verkeer/handhaving-verkeer/snelheid/meetcorrecties/

Als iets volgens samen afgesproken voorschrift niet de bedoeling is, maar je doet het toch en merkt daar verder niets van, dan ga je het in de toekomst meestal ook niet beter doen.

Dat volgens de B.R. CA s actie moeten nemen als een certificaat niet aan de afgesproken gestelde eisen voldoet,
is een beetje een stok achter de deur om CA s te motiveren om goed op te blijven letten en aan de regels te voldoen,
want anders het kost hun waarschijnlijk tijd en geld.