image

Vervangen van duizenden PKI-overheidcertificaten begonnen

dinsdag 14 mei 2019, 14:45 door Redactie, 7 reacties
Laatst bijgewerkt: 14-05-2019, 15:34

De komende maanden zullen duizenden PKIoverheid-certificaten worden vervangen omdat ze niet meer aan de vastgestelde eisen voldoen. Certificaatverstrekkers is gevraagd hiermee te beginnen, zo laat Logius weten, de ict-afdeling van het ministerie van Binnenlandse Zaken.

Overheidsdiensten gebruiken PKIoverheid-certificaten voor verschillende zaken, zoals versleutelde verbindingen voor websites, authenticatie op afstand, elektronische handtekeningen en versleuteling van elektronische berichten. Deze certificaten worden binnen het "Public Key Infrastructure" (PKIoverheid) stelsel op drie niveaus uitgegeven: een rootcertificaat, tussenliggende certificaten en eindgebruikerscertificaten. Eindgebruikerscertificaten zijn onderverdeeld in servercertificaten en persoonsgebonden certificaten.

Logius is verantwoordelijk voor de uitgifte van het rootcertificaat en de tussenliggende certificaten. Eindgebruikerscertificaten worden door publieke en private certificaatverstrekkers uitgegeven. Onlangs werd bekend dat certificaatautoriteiten een fout hebben gemaakt bij het genereren van certificaten. De standaarden voor certificaten verplichten dat die over een 64-bit serienummer moeten beschikken. De certificaatautoriteiten hebben echter certificaten uitgegeven die effectief over een 63-bit serienummer beschikten. Dit kwam door een standaardinstelling van de gebruikte uitgiftesoftware EJBCA.

Vanwege de fout moeten 11 tussenliggende en ongeveer 3900 onderliggende PKIoverheid-certificaten worden vervangen. Er is gekozen om alleen de certificaten te vervangen die voor webverkeer worden gebruikt. Certificaten die niet voor webverkeer gebruikt worden, inclusief persoonsgebonden certificaten, laat Logius niet vervangen. "De uitvoering van het vervangingsplan verloopt voorspoedig. Inmiddels zijn alle tussenliggende certificaten vervangen", zo meldt Logius vandaag.

Wat betreft de vervanging van de servercertificaten wordt hier nu mee begonnen. Certificaatverstrekkers zullen met de betreffende organisaties contact opnemen. Eind 2019 zou de operatie moeten zijn afgerond. Certificaatverstrekkers zullen de certificaten die niet in het vervangingsplan zijn opgenomen monitoren. Wanneer blijkt dat ze toch voor webverkeer worden gebruikt, zullen ook deze certificaten worden vervangen.

"Ik wil nogmaals benadrukken dat de veiligheid van de getroffen certificaten die nog in gebruik zijn niet in het geding is en burgers veilig digitaal zaken kunnen doen met de overheid", aldus staatssecretaris Knops van Binnenlandse Zaken in een brief aan de Tweede Kamer over het vervangen van de certificaten.

Reacties (7)
14-05-2019, 16:53 door Bitwiper
Anderhalve week geleden bleek het intermediate code-signing certificaat van Mozilla, op dat moment opgenomen in alle browser extensies, genaamd signingca1.addons.mozilla.org met serienummer "10:00:04" te zijn verlopen - waardoor alle extensies als onveilig werden aangemerkt en daarom uitgeschakeld. Dat is duidelijk geen 64 bit serienummer (het is maar 3 bytes lang zoals te zien is in een ASN.1 editor). Maar misschien was het op 4 mei 2017 (de uitgiftedatum) nog niet helemaal doorgedrongen dat 64 bit randmoness een vereiste was/is.

Echter, als het random zijn van dat serienummer zo belangrijk is, waarom heeft Mozilla dan anderhalve week geleden een update van dat certificaat met aangepast verloopdatum, met een eveneens 3-bytes lang serienummer "10:00:08", toegevoegd aan de certificate store van alle Firefox gebruikers?

Uit https://blog.mozilla.org/security/2017/04/04/mozilla-releases-version-2-4-ca-certificate-policy/:
64 bits of entropy is required in certificate serial numbers.

Als Mozilla zich daar zelf niet aan hoeft te houden, waarom moeten gebruikers van PKI Overheid certificaten dat dan wel? Complete onzin dit.
14-05-2019, 17:48 door [Account Verwijderd]
Door Bitwiper: Als Mozilla zich daar zelf niet aan hoeft te houden, waarom moeten gebruikers van PKI Overheid certificaten dat dan wel? Complete onzin dit.
Het lijkt mij dat er andere eisen gesteld worden aan code signing certificaten dan aan Web PKI certificaten. Bij dat laatste is er inderdaad sprake van de minstens 64 bits eis, maar het zou goed kunnen dat dit niet vereist is voor code signing certificaten en dus helemaal niet hoeft voor het extension signing certificaat.

PKI Overheid heeft zich net als alle andere partijen zoals Apple en Google, die niet 4000 maar enkele honderdduizenden certificaten moesten vervangen, gewoon te houden aan deze eis. Alleen in tegenstelling tot Apple en Google lijkt het de Nederlandse overheid een goed idee om er zo lang mogelijk over te doen om de certificaten te vervangen (of zou het echt niet sneller kunnen?). Dat geeft te denken wat er zou gebeuren als een van de intermediates zou worden ingetrokken door bijvoorbeeld een key compromise, zou het dan opeens wel snel kunnen?
15-05-2019, 12:07 door Bitwiper
Door Acrimony:
Door Bitwiper: Als Mozilla zich daar zelf niet aan hoeft te houden, waarom moeten gebruikers van PKI Overheid certificaten dat dan wel? Complete onzin dit.
Het lijkt mij dat er andere eisen gesteld worden aan code signing certificaten dan aan Web PKI certificaten.
Er zijn verschillen tussen TLS server certificaten en code signing certificaten, maar de reden om CSP's (Certificate Service Providers), vóór ondertekening, een random waarde aan een certificaat te laten toevoegen, is voor elk certificaat hetzelfde.

Dat is namelijk om te voorkomen dat, indien een aanvrager een hash collision gevonden heeft, deze kan bewerkstelligen dat die hash-waarde in de digitale handtekening van de CSP onder het certificaat zal worden gebruikt. Daarmee kan de aanvrager een ander certificaat maken dat geldig is omdat de handtekening van de CSP hetzelfde is (en klopt). Dit wordt uitgelegd in https://cabforum.org/2016/03/31/ballot-164/. Met andere woorden: als een random waarde (ongeacht of deze in het serienummer zit of ergens anders in de te ondertekenen blob) belangrijk is, zou dat m.i. voor alle soorten digitale certificaten moeten gelden. En als die random waarde uit tenminste 64 bits zou moeten bestaan (los van het feit dat ik nergens kan vinden waarom 64 en niet meer of minder), dan zie ik niet in waarom dat niet voor alle soorten digitale certificaten zou moeten gelden.

De laatstgenoemde ballot leidde overigens tot de volgende wijziging in nieuwe Baseline Requirements:
“Effective September 30, 2016, CAs SHALL generate Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG.”

M.b.t. concrete eisen aan code signing certificaten, het volgende.

Het CABforum heeft een voorstel geschreven (https://cabforum.org/wp-content/uploads/Code-Signing-Requirements-2015-11-19.pdf) waarin het m.b.t. de eisen aan het serienummer verwijst naar de "Baseline Requirements" (zie https://cabforum.org/baseline-requirements-documents/). Bij de stemming daarvoor is dit voorstel echter afgewezen (https://cabforum.org/2015/12/17/ballot-158/), naar verluidt omdat "some forum members felt code signing was not in scope with the Forum’s charter" (zie https://casecurity.org/2016/07/20/minimum-requirements-for-code-signing-certificates/).

Daarna heeft de "CA Security Council" dat document alsnog aangenomen als standaard (https://casecurity.org/wp-content/uploads/2016/09/Minimum-requirements-for-the-Issuance-and-Management-of-code-signing.pdf), met de opmerking "Microsoft also supports the document and has added the requirement to use the new standard for code signing certificates by February 1, 2017" (http://social.technet.microsoft.com/wiki/contents/articles/31633.microsoft-trusted-root-program-requirements.aspx).

Vanuit de pagina met laatstgenoemde URL verwijst Microsoft in 3.14, via https://aka.ms/csbr (ik heb http in https veranderd) weer naar https://casecurity.org/resources/:
[...]
3. Continuing Program Requirements
[...]
14. Effective February 1, 2017, any CA enrolled in the program that issues certificates capable of being used for code signing must adopt the Minimum Requirements for the Issuance and Management of Publicly Trusted Code Signing Certificates published by the CAB Forum Code Signing Working Group (available at http://aka.ms/csbr). Each CA must make the necessary changes to its CP/CPS documents and provide evidence to Microsoft that it has made the change and implemented the required process updates.
[...]

Dat lijk mij een niet te negeren standaard dus. Uit https://casecurity.org/wp-content/uploads/2016/09/Minimum-requirements-for-the-Issuance-and-Management-of-code-signing.pdf:
Version 1.1 (September 22, 2016)
Code Signing Working Group*
Minimum Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates
* This document was developed by the following members of the CA/Browser Forum Code Signing Working Group: Comodo, DigiCert, Entrust, GlobalSign, Izenpe, Microsoft, Symantec, SSC, and WoSign. It was not adopted by the Forum, but is presented here for publication.
This work is licensed under the Creative Commons Attribution 4.0 International license.
[...]
3. References
As specified in the Baseline Requirements. Cross-references to Sections of the Baseline Requirements are notated with the letters “BR”, as in “BR Section 1.2.”
[...]
9.6 Certificate Serial Number
As specified in BR Section 7.1.
[...]
Met andere woorden, voor de eisen aan het serienummer verwijst ook dit document naar de "Baseline Requirements" van het CA/Browser Forum.

Mozilla houdt zich hier duidelijk niet aan, ook niet bij de uitgifte van end-entity code signing certificaten. Eerder en gisteravond heb ik een stel Firefox add-ons/extensions gedownload (die bijv. overboekingen zouden kunnen manipuleren tijdens internetbankieren, en waarvan het dus op z'n minst noodzakelijk is dat je weet wie die extensie gemaakt heeft - los van of die partij betrouwbaar is). De resultaten:

Serienummer (hex)|   Cert geldig tot | Cert geldig vanaf | Add-on/extensie
----------------------------------------------------------------------------------
157d8534271fdcb7 | 20200127 00:05:05 | 20190127 00:05:05 | Bookmarks Organizer
159435549c8cfebe | 20200409 22:00:08 | 20190410 22:00:08 | NoScript
159afb4824423ebd | 20200501 23:35:08 | 20190502 23:35:08 | HTTPS Everywhere (oud)
159b6e778e883f78 | 20200503 10:45:55 | 20190504 10:45:55 | HTTPS Everywhere hotfix
159d1fb6fb5ec411 | 20200508 23:05:16 | 20190426 19:33:20 | Ghostery
159dbec82955ac0d | 20200510 23:40:13 | 20190426 19:33:20 | uBlock Origin
159e6350cacbcee8 | 20200513 01:55:19 | 20190426 19:33:20 | HTTPS Everywhere

De lijst hierboven heb ik gesorteerd op serienummer van het certificaat. Opvallend is dat er een relatie lijkt te bestaan tussen het serienummer en de vervaldatum. Ook doordat de eerste byte steeds 0x15 is, lijkt het er wel heel sterk op dat er geen sprake is van 64-bit randomness (helemaal uitsluiten kan ik dat niet, zie https://dilbert.com/strip/2001-10-25).

Overigens zijn alle extensies gisteravond gedownload, behalve "HTTPS Everywhere (oud)" op 20190506 en "HTTPS Everywhere hotfix" op 20190505.

Duidelijk is dat Mozilla zich niet aan de "gangbare" standaard houdt. Dit leidt, voor zover ik weet, niet tot een beveiligingsrisico. Maar ik vind het wel vreemd dat als andere organisaties (zoals PKI overheid en gebruikers van die certificaten) zich wel exact aan regels moeten houden, Mozilla meent dat niet te hoeven doen.
15-05-2019, 18:50 door Anoniem
Bitwiper, welke CA (if any) heeft de certificaten die je hierboven omschrijft uitgegeven?
15-05-2019, 23:05 door Bitwiper
Door Anoniem: Bitwiper, welke CA (if any) heeft de certificaten die je hierboven omschrijft uitgegeven?
Mozilla zelf.

Het root certificaat, dat in de Windows versie van Firefox hardcoded in xul.dll is opgenomen, wordt niet getoond in de Firefox certificate manager (zie ook https://www.security.nl/posting/607930/Firefox+add-on+cert+issues#posting607932).

Het lijkt alleen anders te werken dan ik vermoedde: uit https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Distribution maak ik op dat Mozilla voor elke extensie een sleutelpaar en bijbehorend certificaat genereert en Mozilla de extensie ondertekent (in plaats van de auteur). De logica hiervan ontgaat me: waarom gebruikt Mozilla een dedicated code signing cert per extensie, en belangrijker, hoe weten Firefox-extensie gebruikers dat de unsigned code daadwerkelijk afkomstig is van de kennelijke auteur?

Zodra ik tijd heb ga ik hier maar eens verder induiken denk ik.
16-05-2019, 20:12 door Anoniem
Door Bitwiper:
Door Anoniem: Bitwiper, welke CA (if any) heeft de certificaten die je hierboven omschrijft uitgegeven?
Mozilla zelf.
Volgens mij is Mozilla zelf geen CA.
De vraag is of een dergelijk certificaat onder de scope valt van de "basic requirements" die de minimale entropie-eis stelt.
20-05-2019, 08:40 door Anoniem
En zo kunnen onverlaten en commercie per extentie gaan cert-fingerprinten.
Er is gewoon te veel excessieve info proliferatie.
Dat gaat ook bij certificering en encryptie ons nog eens lekker opbreken.
Wat denk je, beste Bitwiper?
#sockpuppet
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.