Main content
Onder middeluitgevers worden alle partijen verstaan welke via BSNk activatie een middel aanvragen. Onder DEP ontvanger worden zowel de partijen verstaan welke een DEP/DEI aanvragen via BSNk activatie als ook alle partijen die een DEP ontvangen en verder verwerken.
Aankondiging en procedure handtekeningsleutelwissel
Binnen uw organisatie in de rol als Middeluitgever worden de volgende sleutels gebruikt:
- de U-handtekeningsleutel voor de handtekeningverificatie van PIP/PI/PP/VPIP/DEP/DEI
- optioneel: de VPIP 'zero knowledge proof' sleutel
Binnen uw organisatie als DEP verwerker worden de volgende sleutels gebruikt:
- de U-handtekeningsleutel voor de handtekeningverificatie van DEP/DEI
Sleutelwisseltermijnen
Sleutels dienen vanuit beveiligingsoogpunt periodiek te wijzigen. In dit geval gaat het om de handtekening sleutel, ook wel de U sleutel genoemd. De handtekeningsleutel wordt gebruikt voor de ECDSA handtekeningverificatie van PIP/PI/PP/VPIP/DEP/DEI.
De huidig vastgestelde betrouwbare levensduur is 3 jaar. Dit betekent dat de U sleutel elke 3 jaar zal worden gewijzigd of indien de situatie dit vereist binnen een termijn van 3 jaar. In alle gevallen worden de relevante stakeholders tijdig van de wissel op de hoogte gebracht.
Uit te voeren acties binnen de organisatie
Bepaal de systeemconfiguratie, systeemcomponenten
De middeluitgever heeft bij de aansluiting op BSNk keuzes gemaakt m.b.t. verschillende opties en/of afspraken gemaakt met andere organisaties. De middeluitgever moet om de impact goed te kunnen bepalen de systeemconfiguratie m.b.t. de BSNk aansluiting en BSNk gerelateerde componenten in kaart brengen.
De belangrijkste vragen om dit te kunnen vaststellen zijn:
- Wordt gebruik gemaakt van PI/PP/PIP?
- Wordt gebruik gemaakt van VPIP?
- Wordt gebruik gemaakt van DEP/DEI?
- Valideert de middeluitgever handtekeningen
- Voor PI/PP/PIP/VPIP
- DEP/DEI
- Wordt de metadata automatisch ingeladen, verwerkt en gebruikt bij handtekening validaties?
- Welke zaken worden handmatig geconfigureerd?
- Kunnen verschillende sleutelversies door de aangesloten partij naast elkaar worden gebruikt?
- Is een 'escape' aanwezig waarbij de aangesloten partij de verificatie (tijdelijk) kan overslaan?
Voor de DEP ontvanger/verwerker geldt nagenoeg hetzelfde als voor de middeluitgever en is de lijst van controles gelijk, met uitzondering van de PI/PP/PIP/VPIP specifieke zaken.
Configureer de handtekening sleutel
De versleutelde identiteiten en/of versleutelde pseudoniemen zijn ondertekend met een digitale handtekening. Door de handtekening te valideren wordt vastgesteld of de integriteit van het bericht intact is en of het bericht afkomstig is van Logius of een door Logius vertrouwde partij. Het publieke deel van de handtekeningverificatiesleutel wordt door Logius BSNk in haar netwerk metadata geplaatst. Indien het systeem van dienstverlener is geconfigureerd om automatisch de juiste sleutel uit de gepubliceerde data te halen dan is verdere actie waarschijnlijk niet noodzakelijk.
Is de sleutel op een andere manier geconfigureerd in het systeem van dienstverlener dan dient dienstverlener de sleutel(s) uit de netwerk metadata te halen en deze in haar systeem te configureren. De wijze van configuratie valt buiten de scope van Logius.
Risico’s bij sleutelwissel
| NR | Risico | Kans | Impact | Toelichting |
|---|---|---|---|---|
| 1 | Stagnatie in productie door onvolledige communicatie | M | H | Communicatie naar Middeluitgever verloopt niet correct/komt niet aan waardoor omgeving niet tijdig is aangepast. Na de sleutelwissel gaat productie fout. |
| 2 | Stagnatie in statusmeldingen door foutieve of niet tijdige configuratie-aanpassingen | M | M | Indien statusmeldingen niet kunnen worden verstuurd/verwerkt dan dienen deze op een later moment opnieuw te worden aangevraagd en te worden verstuurd. Voorziet het productieproces hier in? |
Genoemde risico's kunnen eenvoudig worden gemitigeerd door tijdelijk de verificatie over te slaan. Of dit mogelijk is hangt af van de implementatie binnen uw organisatie.
Aankondiging en procedure sleutelwissel
Een aankondiging van vervanging van de handtekeningsleutel (U) wordt vanuit Logius per mail aangekondigd vergezeld van relevante documentatie m.b.t. procedure en impact. Een sleutelwissel wordt gefaseerd uitgevoerd waarbij de aangesloten partijen de nieuwe configuratie kunnen testen in de preproductie omgeving waarna na de gecommuniceerde periode de wissel wordt doorgevoerd in de productieomgeving.
Impact op de organisatie/systemen
De middeluitgever dient allereerst inzichtelijk te hebben welke sleutels en welke aan sleutels gerelateerde informatie actief in gebruik is.
De impact op de systemen hangt voor een deel af van de wijze waarop de systeemconfiguratie is ingericht.
- Wordt de benodigde U sleutel automatisch bepaald a.d.h.v. de meta data of wordt deze expliciet geconfigureerd?
- Wordt gebruik gemaakt van de VPIP structuur?
- Is het systeem gebaseerd op gebruik van een enkele versie van een sleutel of kunnen meerdere sleutels naast elkaar bestaan? Dit is met name van belang voor de vaststelling of een geleidelijke inrichting/migratie mogelijk is of dat het systeem op moment X volledig overgaat van de ene sleutelversie naar de andere? In het laatste geval is een strakke coördinatie vereist en een goede rollback procedure noodzakelijk.
Een middeluitgever kent in deze rol een aantal mogelijke gegevensstromen.
Gegevensstroom: Aanvraag middel (=PI/PP/PIP) bij Logius BSNk
Een aanvraag van een middel wordt door de middeluitgever rechtstreeks bij Logius BSNk gedaan. Dit middel wordt door de middeluitgever gecontroleerd op integriteit door de digitale handtekening onder het ontvangen middel te controleren.
De publieke sleutel om het middel te controleren is door Logius BSNk beschikbaar gesteld in de netwerk metadata, de U sleutel. Deze sleutel wordt periodiek gewijzigd en heeft naast de SKSV versie ook een sleutelversie.
In het middel staat voldoende informatie om de voor verificatie benodigde U sleutel op te zoeken in de netwerk metadata. Afhankelijk van de implementatie bij de middeluitgever kan de impact variëren van nul tot aan handmatig aanpassen van de configuratie.
Actie middeluitgever: Vaststellen welke situatie van toepassing is.
In onderstaand schema is weergegeven hoe de aanvraag en ontvangst van een middel verloopt, bezien vanuit de middeluitgever.
Gegevensstroom: Aanvraag verifieerbaar middel (=VPIP) bij Logius BSNk
De aanvraag van een verifieerbaar middel, de VPIP, is grotendeels gelijk aan de aanvraag van een regulier middel. Zie daarom ook de voorgaande gegevensstroom.
Het verschil met een regulier middel zit in de mogelijkheid tot het verifiëren van de relatie tussen het middel en een PIP waarbij gebruik van een extra sleutel is vereist. De nuance m.b.t. aanvraag en configuratie van de extra sleutel is verder in dit document uiteengezet (zie Aanvraag VPIP verificatiesleutel).
Onderstaand schema geeft de aanvraag en verificatie van een VPIP schematisch weer.
Gegevensstroom: Aanvraag DEP bij Logius BSNk / Ontvangst DEP van MU
Bij de aanvraag van een DEP door de middeluitgever of het verwerken van een door de middeluitgever verrijkte en doorgestuurde DEP is een gelijk scenario van toepassing zoals bovenstaand beschreven. Hierbij is het uitgangspunt dat enkel de handtekeningsleutel wijzigt.
Verificatie van de handtekening onder het bericht met behulp van de handtekeningsleutel is voor alle partijen gelijk.
Technische informatie U-sleutel
Technische info met betrekking tot de handtekeningsleutel. In onderstaand schema refereert de Keyname U aan de handtekeningsleutel.
| KeyName | Doel | Type | Gepubliceerd door | Gebruik | Opmerkingen | Levensduur in jaren |
|---|---|---|---|---|---|---|
| U | PI/PP Verificatie sleutel | EC Public Key (EC-DSA) | Koppeldienst (Activatiefunctie) | Verificatitie van Ondertekende PP en ondertekende PI (MU, AD, EB) en DEP (IR) | MU/AD/EB kunnen de sleutel gebruiken om de authenticiteit te verifiëren van de ondertekende PI / ondertekende PP (EC-DSA handtekening). | 3 |
Wat is de aanpassing en waar vind de aanpassing plaats?
In de netwerkmetadata zal een toevoeging worden gedaan. Er zal onder de key-descriptor \ keyinfo een 2e veld </ ds:keyname> worden toegevoegd
in de overgangsperiode. Zie https://stb.bsn-koppelregister.nl/md/ voor de BSNk netwerkmetadata Dit is hoe de handtekeningsleutel nu is gepubliceerd.
Open deze afbeelding met uw rechter muisknop in een nieuw tabblad om hem beter te kunnen bekijken.
De handtekeningsleutelwissel weergegeven in een flow-chart
Tijdens de overgangsperiode naar U_u sleutelwissel groep 2, hier in onderstaand voorbeeld op een BSNk acceptatieomgeving.
Vanaf het moment dat de overgangsperiode in gaat zal in de BSNk metadata zowel U-sleutel 1 als U-sleutel 2 beschikbaar komen.
Open deze afbeelding met uw rechter muisknop in een nieuw tabblad om hem beter te kunnen bekijken
Weergave van BSNk intern Acceptatie netwerkmetadata
U-sleutel 1 <ds:keyname>urn:nl-gdi-eid:1.0:pp-key:acc:1:U:1</ds:KeyName>
U-sleutel 2 <ds:keyname>urn:nl-gdi-eid:1.0:pp-key:acc:1:U:2</ds:KeyName>
Voorbeeld van de BSNk Preproductie tags in de netwerkmetadata
U-sleutel 1 <ds:keyname>urn:nl-gdi-eid:1.0:pp-key:pp:1:U:1</ds:KeyName>
U-sleutel 2 <ds:keyname>urn:nl-gdi-eid:1.0:pp-key:pp:1:U:2</ds:KeyName>
Voorbeeld van de BSNk Productie tags in de netwerkmetadata
U-sleutel 1 <ds:keyname>urn:nl-gdi-eid:1.0:pp-key:prod:1:U:1</ds:KeyName>
U-sleutel 2 <ds:keyname>urn:nl-gdi-eid:1.0:pp-key:prod:1:U:2</ds:KeyName>
NB: Na de overgangsperiode blijft alleen sleutel 2 zichtbaar in de netwerkmetada.
SchemeKeySetVersion en Keyversion
BSNk-PP kent vele onderling samenhangende sleutels. Deze sleutels zijn als set samengebracht en worden over het algemeen als set geïdentificeerd. De term die voor deze set wordt gehanteerd is 'Scheme Key Set Version' afgekort als SKSV.
De individuele sleutels in deze set hebben een sleutelversie welke kan afwijken van het SKSV. De U sleutel is de enige sleutel waarvan meerdere versies binnen een set kunnen voorkomen.
Met de wijziging van de U handtekeningsleutel wordt een nieuwe sleutel toegevoegd aan de bestaande set. Het SKSV wijzigt dus niet met deze actie. Het versienummer van de U-sleutel wijzigt wel en dit versienummer is onderdeel van de berichten waarvoor de U sleutel is benodigd t.b.v. verificatie.
Schematisch ziet de samenhang van de sleutelversies er als volgt uit, waarbij de groen gemarkeerde 'Scheme' de cryptografische architectuur betreft en in principe niet zal wijzigen en de blauw gemarkeerde Scheme Key Set periodiek zal wijzigen door sleutelwissels maar door de unieke positie van de U handtekening sleutel in dit geval niet wijzigt. In het grijs is een mogelijke toekomstige situatie weergegeven waarbij door wissel van een of meer andere stelselsleutels een nieuwe set wordt aangemaakt. De handtekening sleutel U nummert altijd door.
