Main content

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 oktober 2023. 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 3 augustus. Op 29 augustus is het overzicht van verschillen toegevoegd. Op 23 september is 'handtekening' vervangen door 'ondertekening'.

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).

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 BSNk Decryptiecomponent (mei 2022). Neemt u 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:

  • Vervang de huidige softwarecomponent die u gebruikt voor het ontsleutelen van een versleuteld BSN/PseudoID door de BSNk Decryptiecomponent.
  • Vervang de huidige component door de code van de BSNk decryptiecomponent. Deze methode vraagt meer onderhoud bij eventuele toekomstige wijzigingen.
  • Uw organisatie of softwareleverancier kan ook zelf nieuwe code schrijven die voldoet aan de specificaties. Het testtraject en de kwaliteitscontrole van deze maatwerksoftware valt onder uw verantwoordelijkheid. Zie hier 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 eventuele vragen over uw aansluiting en de planning kunt u contact opnemen met uw eHerkenningsmakelaar. Als u daarna specifieke technische vragen heeft over deze BSNk Decryptiecomponent of code, dan kunt een mail sturen aan 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)
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.
Current OID (v1) New OID (v2)
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

Changes in structure for Signed Direct Encrypted Pseudonym

Direct Encrypted Pseudonyms are used in specific use-cases by specific parties. The Signed Direct Encrypted Pseudonym will also be updated, along with the ECSDSA structures above.

Existing DEP-structure (v1) Updated DEP-structure (v2)

SignedDirectEncryptedPseudonym ::= SEQUENCE {
   notationIdentifier OBJECT IDENTIFIER (id-BSNk-encrypted-direct-pseudonym-signed),
   signedDEP SEQUENCE {
     directEncryptedPseudonym DirectEncryptedPseudonym,
     auditElement OCTET STRING,
     signingKeyVersion INTEGER
   },
   signatureValue ECDSA-Signature
}

SignedDirectEncryptedPseudonym-v2 ::= SEQUENCE {
   notationIdentifier OBJECT IDENTIFIER (id-BSNk-encrypted-direct-pseudonym-signed-v2),
   signedDEP SEQUENCE {
      directEncryptedPseudonym DirectEncryptedPseudonym
      auditElement OCTET STRING,
      signingKeyVersion INTEGER,
      issuanceDate IA5String,
      extraElements [2] ExtraElements OPTIONAL
   },
   signatureValue ECDSA-Signature
}
Changes to the existing structure:

•    New identifier: changes from id-BSNk-direct-pseudonym-signed to id-BSNk-direct-pseudonym-signed-v2)
•    issuanceDate and extraElements[2] are fields that support new use-cases. Existing processing-logic for signedEI structures will not be affected by those fields.

Gerelateerde dienst(en)

BSNk PP