Hoofdinhoud

Alle dienstverleners die inloggen met eIDAS of eHerkenning aanbieden en daartoe een versleuteld Pseudoniem of versleuteld ID ontvangen, moeten binnenkort een nieuwe BSNk-ondertekening gaan gebruiken om versleutelde gegevens uit te pakken.

Vooralsnog geldt dit alleen voor eIDAS en eHerkenning.

Dit moet u hebben geregeld vóór 1 juli voor de preproductieomgeving en vóór 1 oktober 2023 voor de productieomgeving. U kunt deze technische wijziging zelf doen. Werkt u samen met een ICT-leverancier, bespreek deze wijziging dan met hen.

Deze pagina is aangepast op 19 juli. Op 23 september 2022 werd 'handtekening' vervangen door 'ondertekening'. Op 29 augustus 2022 werd het overzicht van verschillen toegevoegd.

Over BSNk

Met DigiD, eHerkenning of eIDAS identificeert u uw gebruikers. Uw software gebruikt BSNk om daarbij versleutelde gegevens uit te pakken. Bijvoorbeeld als u per inloggende gebruiker een Burgerservicenummer (BSN) of PseudoID (pseudoniem) gegeven ontvangt.

Wat verandert er?

Er is een nieuwe versie van de ondertekensoftware, V2. U kunt deze nu al implementeren zodat u tijdig gereed bent. Tot voor kort was V1 de standaard bij BSNk, maar inmiddels is de verbeterde versie V2 bij BSNk geïmplementeerd. Tot 1 oktober 2023 kan nog met beide versies gewerkt worden, maar ná 1 oktober 2023 kunt u geen versleutelde gegevens meer uitpakken met de V1 software.

Bekijk een overzicht van de verschillen tussen ‘v1’ en ‘v2’ onderaan deze pagina (Engels). Kijk hier voor meer technische informatie.

Achtergrond

Het BSNk gebruikte tot nu cryptografie voor de versleuteling van BSN’s die sterk leunt op de cryptografie die in Duitsland is gebruikt. Deze standaard is in de huidige implementatie van BSNk opgenomen als EC-Schnorr (v1). Inmiddels is er een verbeterde internationale standaard, de ECSDSA. BSNk heeft de nieuwe ECSDSA standaard geïmplementeerd (in de berichten met versie ‘v2’). Berichten van type ‘v2’ worden ook ondersteund in de eTD(eHerkenning) en eIDAS ketens.

Planning - Iedereen over voor 1 oktober

Alle dienstverleners, die een BSN of PseudoID ontvangen vanuit eHerkenning of eIDAS, moeten zijn overgegaan naar de nieuwe ondertekening ECSDSA (v2), voordat BSNk de digitale ondertekening van de EC-Schnorr (v1) volledig stopt.

  • Nu tot 1 juli 2023: uitfaseren EC-Schnorr ondertekening v1, beëindigen van ondersteuning van de EC-Schnorr (v1) op de Preproductieomgeving
  • Nu tot 1 oktober 2023: overstappen naar ECSDSA-ondertekening v2. Beëindigen van ondersteuning van de EC-Schnorr (v1) op de Productieomgeving

Uw software moet zowel v1 als v2 om kunnen gaan. Deze herkent dan automatisch of de digitale ondertekening is opgemaakt volgens de nieuwe ECSDSA-norm of de oude EC-Schnorr-norm, en controleert deze volgens de betreffende standaard.

In de huidige productieversie van BSNk worden beide ondertekeningen gelijktijdig ondersteund. Dit geeft u en uw ICT-softwareleverancier een mogelijkheid om sneller en op eigen tempo over te stappen naar de v2-structuren.

Wat moet u doen?

Bent u nog niet in het bezit van de nieuwste versie van de BSNk Decryptiecomponent (maart 2023)? Neem dan contact op met bsnkoppelregister@logius.nl.

Stap 1: Voer de aanpassingen door

Uw organisatie kan de aanpassingen het beste doen op basis van de BSNk Decryptiecomponent, die al met beide ondertekenstandaarden om kan gaan. Dit kan op meerdere manieren:

Uw organisatie of softwareleverancier kan ook zelf nieuwe code schrijven die voldoet aan de specificaties. Het testtraject en de kwaliteitscontrole van deze maatwerksoftware vallen onder uw verantwoordelijkheid. Zie: de voorbeeldcode.

Stap 2:  Migreer van v1 naar v2

Geef via uw eHerkenningsmakelaar in de dienstencatalogus aan welke versie van de BSNk-berichten u wilt ontvangen. Deze staat momenteel als standaard op v1. Zodra hier v2 wordt aangegeven zal het BSNk-berichten ondertekenen volgens de v2 structuur (Zie ‘BsnkStructureVersion’ op deze pagina).

Stap 3:  Testen

Test in een preproductieomgeving of de aanpassing werkt vóór u deze naar productie uitrolt.

Stap 4: Uitrol naar productie en terugkoppeling naar uw eHerkenningsmakelaar.

U rolt de software uit naar productie en informeert de eHerkenningsmakelaar

Advies

Logius adviseert om V1 per heden niet meer te gebruiken voor nieuwe aansluitingen. Voor nieuwe aansluitingen adviseren wij om direct V2 in te zetten.

Meer informatie

Voor vragen over uw aansluiting en de planning kunt u contact opnemen met uw eHerkenningsmakelaar.

Als u daarna specifieke technische vragen heeft over de v2-ondertekensoftware kunt u een mail sturen naar bsnkoppelregister@logius.nl.

 

Overzicht van de verschillen tussen ‘v1’ en ‘v2’

Differences in structure for Signed Encrypted Identity and Signed Encrypted Pseudonym:

EC-Schnorr structure (v1) ECSDSA structure (v2)
Current OID (v1) New OID (v2)
DeprecatedSignedEncryptedIdentity ::= SEQUENCE {
   notationIdentifier OBJECT IDENTIFIER (id-BSNk-encrypted-identity-signed),
   signedEI SEQUENCE {
      encryptedIdentity EncryptedIdentity,
      auditElement OCTET STRING
  },
  signatureValue EC-Schnorr-Signature
}

SignedEncryptedIdentity-v2 ::= SEQUENCE {
   notationIdentifier OBJECT IDENTIFIER (id-BSNk-encrypted-identity-ecsdsa-signed-v2),
   signedEI SEQUENCE {
      encryptedIdentity EncryptedIdentity,
      auditElement OCTET STRING,
      issuanceDate IA5String,
      extraElements [2] ExtraElements OPTIONAL
   },
   signatureValue EC-SDSA-Signature
} Changes to the existing structure:

  • New identifier: changes from id-BSNk-encrypted-identity-signed to id-BSNk-encrypted-identity-ecsdsa-signed-v2
  • signatureValue is now EC-SDSA-Signature structure (see structure definition below)
  • issuanceDate and extraElements[2] are fields that support new use-cases. Existing processing-logic for signedEI structures should not be affected by those fields.
DeprecatedSignedEncryptedPseudonym ::= SEQUENCE {
   notationIdentifier OBJECT IDENTIFIER (id-BSNk-encrypted-pseudonym-signed),
      signedEP SEQUENCE {
      encryptedPseudonym EncryptedPseudonym,
      auditElement OCTET STRING
   },
   signatureValue EC-Schnorr-Signature
}		 SignedEncryptedPseudonym-v2 ::= SEQUENCE {
   notationIdentifier OBJECT IDENTIFIER (id-BSNk-encrypted-pseudonym-ecsdsa-signed-v2),
   signedEP SEQUENCE {
      encryptedPseudonym EncryptedPseudonym,
      auditElement OCTET STRING,
      issuanceDate IA5String,
      extraElements [2] ExtraElements OPTIONAL
   },
   signatureValue EC-SDSA-Signature
}
Changes to the existing structure:

•    New identifier: Changes from id-BSNk-encrypted-pseudonym-signed to id-BSNk-encrypted-pseudonym-ecsdsa-signed-v2
•    signatureValue is now EC-SDSA-Signature structure (see structure definition below)
•    issuanceDate and extraElements[2] are fields that support new use-cases. Existing processing-logic for signedEI structures should not be affected by those fields.
EC-Schnorr-Signature ::= SEQUENCE {
        signatureType      OBJECT IDENTIFIER (
                                  ecschnorr-plain-SHA384),
        signatureValue     EC-Sig-Value
}		 EC-SDSA-Signature ::= SEQUENCE {
        signatureType      OBJECT IDENTIFIER (
                                  ecsdsa-plain-SHA384),
        signatureValue     EC-Sig-Value
}
Changes to the existing structure:
•    New identifier: Changes from ecschnorr-plain-SHA384 to ecsdsa-plain-SHA384
•    signatureValue is now EC-SDSA and needs to be processed accordingly.
id-BSNk-encrypted-identity-signed
2.16.528.1.1003.10.1.2.3		 id-BSNk-encrypted-identity-ecsdsa-signed-v2
2.16.528.1.1003.10.1.2.7.2
id-BSNk-encrypted-pseudonym-signed
2.16.528.1.1003.10.1.2.4		 id-BSNk-encrypted-pseudonym-ecsdsa-signed-v2
2.16.528.1.1003.10.1.2.8.2
EC-Schnorr-Signature
0.4.0.127.0.7.1.1.4.3.3		 EC-SDSA-Signature
0.4.0.127.0.7.1.1.4.4.3

Gerelateerde dienst(en)

BSNk PP