Dus 40000 partijen hebben niet standaard toegang tot mijn BSN.
Dat is toch goed?

Als ik mijn BSN zou veranderen, dan is het toch aan mijzelf om mijn zorginstanties en bank op de hoogte te brengen?
Verder heeft toch niemand enige noodzaak om mijn BSN te verwerken.

Interessant dat gevraagd wordt om een pseudoniem te pseudonimiseren. Dit komt er feitelijk op neer dat het BSN vervangen wordt door een nieuw BSN. Dit ondergraaft een deel van de reden om een BSN te hebben: een unieke identificatie van een persoon. Veel administraties, die vaak om wettelijke redenen het BSN gebruiken zullen dus naast het oude BSN het nieuwe BSN moeten registreren en alle queries die een volledig beeld van de historie van een persoon moeten genereren en die zoeken op BSN moeten aanpassen. Dit is vragen om fouten en problemen bij dienstverlening aan burgers en patiënten. Ik zou zeer terughoudend zijn: de gevolgen waar je op kan rekenen zijn voor de overgrote meerderheid van burgers en patiënten groter dan de mogelijke gevolgen van het blijven hanteren van een eenmalig uitgegeven BSN zoals het nu is.

Steeds meer NGO's willen ook een unieke identifier die te herleiden valt naar één individu. Het gaat in de basis dus niet om een "nieuwe" BSN maar om een "alternatief dat is afgeleid van".

Probleem: de huidige BSN's hebben veel te weinig "entropie" (mogelijke getalswaarden, d.w.z. cijfercombinaties) waardoor het hashen slechts daarvan, of in combinatie met een niet geheime organisatienaam) totaal zinloos is (dit is veel te eenvoudig te "reversen").

De minst onveilige aanpak die ik zie:

1) Geef iedereen (bij de geboorte of later) een voldoende lange, onvoorspelbare, GUID voorafgegaan door "NL-". Check dat deze nooit eerder is uitgegeven in de database met cryptografische hashes van ooit in Nederland uitgegeven GUID's. Zo ja: genereer een nieuwe etc. totdat de GUID gegarandeerd uniek is.

2) Deze GUIDs moeten, samen andere, uniek identificerende gegevens, zwaar beveiligd worden opgeslagen in een landelijk register (de beherende organisatie genereert ook de GUID's) , dat zo beperkt mogelijk toegankelijk moet zijn.

3) Voor elke organisatie die een "BSN" van de persoon wil:

3.a) Als die organisatie nog geen GUID heeft: genereer een unieke onvoorspelbare GUID die aan die organisatie wordt toegekend.

3.b) Bereken een HMAC (met sterke hashfunctie) uit de persoons-GUID (als secret) en de organisatie-GUID. Het resultaat kun je de organisatie-GUID van de persoon noemen.

Of een gegeven organisatie-GUID van de persoon hoort bij partieel of uniek identificerende gegevens van de persoon, kan bij het register worden geverifieerd.

Als een organisatie gehacked wordt, moet er een nieuwe organisatie-GUID worden gegenereerd waarmee alle organisatie-persoons-GUID's komen te vervallen.

Het moet organisaties verboden worden om hun organisatie-persoons-GUID's uit te wisselen, tenzij de persoon daar, zonder uitgeoefende druk, expliciet toestemming voor geeft die op betrouwbare wijze wordt geregistreerd in het register.

Worden, zonder toestemming, toch organisatie-persoons-GUID's uitgewisseld tussen organisaties, dan is dat een datalek en moet de organisatie-GUID worden vervangen (als dat een boel inspanning kost kan dat datalekken helpen voorkomen).

Aanvulling: het bovenstaande is serieus bedoeld, maar zie ook https://tweakers.net/nieuws/209518/twitter-gaat-inactieve-accounts-archiveren-en-gebruikersnamen-vrijgeven.html?showReaction=18726406#r_18726406 waarin ik eeeder vandaag grapte dat we iedereen bij de geboorte een GUID in plaats van een naam zouden kunnen geven (hoeveel mensen kijken er om als je in een drukke drukke rij op de Efteling "Daan" of "papa" roept?).

HMAC, wat is HMAC? Kun je dat eten?
Bij de overheid hebben ze niet eens hun logging op orde, hoe dacht je dat ze dit wouden gaan implementeren?

Op zich een leuk idee, totdat je beseft dat ze daar bij de overheid toch niet zo competent ingesteld zijn.
Ja, er zijn knappe koppen aanwezig, maar die zijn druk bezig de legacy systemen te onderhouden.
Die hebben dus geen tijd om verbeteringen door te voeren.

helaas

HMAC, wat is HMAC? Kun je dat eten?
Bij de overheid hebben ze niet eens hun logging op orde, hoe dacht je dat ze dit wouden gaan implementeren?

Op zich een leuk idee, totdat je beseft dat ze daar bij de overheid toch niet zo competent ingesteld zijn.
Ja, er zijn knappe koppen aanwezig, maar die zijn druk bezig de legacy systemen te onderhouden.
Die hebben dus geen tijd om verbeteringen door te voeren.

helaas[/quote]Blijkbaar niet veel kaas van informatie beveiliging gegeten (helaas). HMAC implementeren is vele malen makkelijker dan logging. Erik geeft hiervoor een goede implementatie.

De overheid roept steeds van: "Houdt je BSN geheim." en ze smijten het zelf overal naar toe.
Ze gebruiken het zelfs al identificatie en authenticatie.

Kijk dat komt op hetzelfde neer als wat ik al een paar keer heb voorgesteld als reactie op de claim "het is niet mogelijk
om iemand deugdelijk en veilig te authenticeren via internet".
De oplossing die je hier voorstelt lijkt op wat ik voorstelde via een ID kaart, waarbij die HMAC door de kaart gegenereerd
wordt en aan de organisatie die authenticatie vereist wordt verwerkt. Het maakt niet uit of die uitlekt of gecopieerd wordt
door criminelen, want deze is alleen geldig voor dit specifieke doel. Je kunt dus niet met een gestolen identificatie je
ergens anders waar "kopietje ID" gevraagd wordt je legitimeren.

De Overheid moet stoppen met kiekeboe spelen met haar burgers. Wat is een BSN-nummer? Een BSN-nummer is een nummer in een kolom in een tabel met meerdere kolommen. Zonder inhoud van die meerdere kolommen heeft die Overheid niets aan enkel het BSN-nummer. Speel open kaart over de inhoud van de overige kolommen en over alle instanties die het BSN-nummer kunnen en mogen (?) gebruiken met hun overige kolommen. Hou onmiddellijk op met volksverlakkerij en geknoei met zogenaamd pseudonomiseren. Het is weer typisch D'66 broddelwerk om maar mee te mogen doen, altijd ten koste van miljarden of de burger. Meer diploma's dan hersens.

Laat ze eens een keer kijken naar scandinavie... Daar is een BSN een identificatie... iedereen weet je BSN daar... de bank, de gemeente, de telefoonmaatschappij, de garage, de klusjesman... en het boeit allemaal niets.. want het is een identificatie... niet een authenticatie..

Hier is een BSN een magische eenhoorn die alles kan. Vreemd genoeg moeten ZZP-ers en MKB-ers dit nummer op hun facturen zetten. dus moet er een nieuwe komen.. en niet die nieuwe safe houden, nee, die nieuwe moet OOK op de facturen gezet worden.. dus de oude en de nieuwe BSN zijn wereldwijd bekend..

Ik snap de stupiditeit nog steeds niet....

authenticatie doe je met een digid, of een CONTROLE met een ID bewijs of een 2FA of een FIDO... niet met een nummer wat overal bekend is...

Nee, natuurlijk niet, het is niet zoiets als dat jij besluit om te verhuizen!
Het BSN is een kenmerk dat uit de administratie van de overheid komt, dus is zij de verantwoordelijke instantie voor het beheer van BSN-mutaties in deze administratie.
Het is ook de overheid die haar administratie koppelt aan door haar geselecteerde andere administraties, niet jij.

Pseudonimiseren van een naam hoeft ook niet daarvoor is er namelijk het nietszeggende BSN.
Doel van het BSN is administratieve verwisselingen te verminderen.
Helaas is het behulpzaam bij fraude oplichting en erger de verborgen agenda bij privacyactivisten

Nou nee dan zou iedereen meteen ook van naam woning enn meer moeten veranderen omdat iemand iets zou kunnen weten. Plichten en verantwoordelijkheden ontlopen met het onbekend willen zijn is een slechte zaak.

Dit laatste vereist dan wel een "groots opgezette samenzwering" en het heeeeel goed geheim weten te houden van die verborgen agenda. Want niemand (behalve K4) kent daar blijkbaar zowel het bestaan als de inhoud van.

Kan K4 een tipje van de sluier oplichten en linkjes verschaffen naar die heeeeel verborgen gehouden agenda?
Noem ook meteen even wat namen (en BSN-nummers?) van de organisatoren.

Bij voorbaat dank.

Zo te zien begrijp je het verschil niet tussen identificatie en authenticatie.

Overigens denk ik dat burgers hun eigen "master" GUID niet zouden moeten kennen, deels om zich tegen zichzelf te beschermen en om te voorkómen dat iemand verzint dat het kennen van die GUID aantoont dat jij jij bent, en je daarmee zou kunnen authenticeren.

Hoewel het technisch mogelijk is een burgerservicenummer te vervangen dat aan een burger is uitgegeven, en het oude 'uit omloop' te halen.....


Mooi want mijn paspoort is gekopieerd en gedeeld.


Als ik geen privacy krijg waarom moet ik anderen nog beschermen?


Er mag ook wel eens betaald gaan worden......


Waarom moet ik altijd de enige rationele actor blijven terwijl anderen lopen te etteren.

Geen verantwoording

yup en hier zit ook het probleem. Ik verbaas mij telkens waar ik mijn BSN moet afgeven of waar het weer doodleuk in 3 voud nodeloos op een brief vanuit instantie of bedrijf xyz geprint is (alsof ik mijn eigen bsn op een brief moet lezen).

plus als het ooit gejat is, kan je het dan laten vervangen? heb daar wel eens onderzoek naar gedaan (na het ggd bsn schandaaltje), maar das natuurlijk geen optie.

Dus kom maar op met die unieke codes die vanaf een de hoofd secret gegereneerd worden ofzo met specifiek doeleinde erin gecodeerd etc en liefst de hoofd secret ook nog even goed beveiligen en password/encrypten etc. we kunnen daar vast wel iets beters dan een 'laat deze niet lezen door mensen' van maken toch?

Dit gaat niet werken. Iedere instantie mag het weten behalve de persoon waar het over gaat ?

Het probleem is gewoon dat instanties het BSN nummer (met een aantal futiliteiten als postcode en geboortedatum) gebruiken als middel waarmee men kan aantonen de persoon te zijn die men claimt te zijn. Daar ga je de mist in.

Het BSN is gewoon een min of meer willekeurig nummer, als ware het een id in een database en bedoeld om eenduidig over verschillende systemen heen gegevens van degene met dat id aan elkaar te kunnen relateren (daarvoor werd daarvoor NAW + geboortedatums vaak gebruikt, met alle problemen vandien (spelfouten, tweelingen met dezelfde NAW gegevens, etc).

Dus het pseudonimiseren van een BSN (zoals Erik al aangaf is de entropie sowieso te laag, een brute force aanval ligt op de loer (seconden werk)) is symptoombestrijding. De oorzaak van het probleem moet worden weggenomen: er zou moeten worden geregeld dat instanties op basis van dit nummer niet mogen aannemen dat je met die persoon in verbinding bent. Het BSN nummer zou gewoon openbaar moeten kunnen zijn (als een bankrekeningnummer).

Het probleem is overigens nog een slag erger. Vaak hoef je je BSN niet eens te geven om zaken geregeld te krijgen. Bij de bank enkel op basis van NAW en geboortedatum een nieuw pasje aangevraagd en gekregen; bij een verzekeringsmaatschappij mijn account kunnen veranderen (op basis van email adres) enkel door postcode, huisnummer en geboortedatum te geven.

Eea volledig veroorzaakt door de drang tot digitalisatie, zonder voldoende te hebben nagedacht hoe men zich bij de onboarding bij een instantie online identtificeert. Dat gaat ook niet: de meest betrouwbare manier is een fysieke, maar dat past niet in de (commerciele) belangen van deze instanties.

Ik leg het te onduidelijk uit (of je hebt niet goed gelezen): de uitleg verderop met de layout van de "records" verduidelijkt het e.e.a. hopelijk.

In mijn voorstel krijgt iedere burger een geheimgehouden GUID, de "master" zeg maar (verderop noem ik dit een MBSN).

Daarvan wordt, per organisatie, een andere unieke GUID afgeleid: dat noem ik, vanaf nu en voor het gemak, een OSBSN (Organisatie Specifiek BSN). Je kunt erover discussiëren of de OSBSN voor de belastingdienst (BDBSN) moet afwijken van de OSBSN in de BRP (BasisRegistratie Persoonsgegevens, BRPBSN), maar de gezondheidszorg zou al een andere OSBSN kunnen gebruiken (GZBSN) - en andere NGO's zeker.

Dit systeem voorkómt dat allerlei verschillende organisaties databases met persoonsgegevens al te eenvoudig aan elkaar kunnen koppelen; als je het goed aanpakt kan mijn voorstel bovendien tot dataminimalisatie en lagere risico's op datalekken leiden.

Zo'n OSBSN is niet strikt geheim (dus totaal ongeschikt voor authenticatie, als "wachtwoord" zeg maar) maar het gaat wel om privacy-gevoelige informatie (want uniek identificerend binnen een beperkte scope) en moet daarom zoveel mogelijk als vertrouwelijk worden behandeld. Je kunt een afweging maken of het überhaupt noodzakelijk is dat een burger elke OSBSN kent (en zou moeten onthouden, of ergens opschrijven - voor zover het niet op een identiteitsbewijs vermeld staat). Immers, het is vooral in het belang van de burger dat OSBSN's niet in verkeerde handen vallen; als burgers ze zelf niet "hebben" verkleint dat de kans.

Zo'n OSBSN hoeft overigens niet op de gebruikelijke GUID-schrijfwijze getoond te worden. Door een meer uitgebreidere karakterset dan 0..9 en A..F te gebruiken, kunnen ze korter worden (ik zou wel bepaalde letters vermijden om afleesfouten te voorkomen). Een mechanisme (slimme checksum) om fouten bij (zoveel mogelijk te vermijden) invoeren te voorkómen, is waarschijnlijk ook verstandig.

Aanvullingen op het bierviltje
Een iets uitgebreider systeem is denkbaar waarbij per burger, naast diens "master-GUID", er per organisatie een (default niet bestaande) "modifier" wordt toegevoegd (vergelijkbaar met een nummer op een autokentekenplaat nadat de vorige is gestolen of is verloren): de BOMod (Burger Organisatie Modifier).

Die BOMod kan worden ingezet in het geval dat een OSBSN in verkeerde handen is gevallen en de burger deze (met gegronde redenen) wil wijzigen.

Je hebt dan, per burger:
• Uniek identificerende gegevens van deze burger
• Master-GUID: MBSN (Master BSN): strikt geheim
• BOMod: default: bestaat niet (de waarde is dan 0). Anders: per organisatie (OID) een modifier (getal 1..n).

Optioneel, per burger (indien deze ooit wijzigen, ook alle vervallen GUID's):
• BRPBSN (BasisRegistratie Persoonsgegevens)
• BDBSN (BelastingDienst)
• IDBSN (op paspoort, identiteitskaart en rijbewijs)
• GZBSN (algemene GezondheidsZorg)
• Oude BSN (zolang deze nog niet is vervangen door OSBSN's)

Per organisatie:
• Uniek identificerende gegevens van de organisatie
• Geautoriseerd contact en evt. sleutels voor authenticatie en transportversleuteling
• OID: unieke identifier die nooit verandert
• Master-GUID: OSN (Organisatie Service Nummer): strikt geheim
• Desgewenst: een array van oude (vervallen) GUID's (met datum/tijd van vervallen en wellicht andere metadata).

Berekening OSBSN (uitgevoerd door de -noodzakelijkerwijs betrouwbare en vertrouwde) register-organisatie:

OSBSN := HMAC(MBSN, OSN + BOMod)

Een organisatie die een consistente unieke ID (een OSBSN) van een burger wil, moet -om te beginnen- zelf zijn geregistreerd. Door uniek identificerende persoonsgegevens (of BRPBSN, of GZBSN, of IDBSN) aan te leveren, kan de register-organisatie het juiste OSBSN berekenen en retourneren.

Als het bijvoorbeeld om een organisatie gaat die gepseudonimiseerde patiëntgegevens voor onderzoek zal gaan gebruiken (zie de disclaimer onderaan), kan een zorgverlener daar een OSBSN (de Organisatie hier zijn de onderzoekers) voor laten uitrekenen door ofwel uniek identificerende persoonsgegevens, ofwel het GZBSN, aan te leveren bij de register-organisatie. Als de aanvrager daartoe geautoriseerd is (na betrouwbare authenticatie natuurlijk), berekent de register-organisatie het juiste OSBSN; uitsluitend de medische gegevens en OSBSN gaan dan naar de onderzoekers - zonder de persoonsgegevens dus. Bij een volgende set gegevens gebeurt herhaalt zich dit: dat levert hetzelfde OSBSN op.

Als medische onderzoekers hun data lekken, hebben zij pech: hun OSN zal dan moeten worden gewijzigd, waardoor toekomstige medische gegevens van een specifieke patiënt met een ander OSBSN zullen worden verstrekt, en dus niet meer gekoppeld kunnen worden (moet je maar fatsoenlijk beveiligen).

Voor de gezondheidszorg bestaat overigens al zo'n systeem, maar dit is totaal niet transparant (althans, ik heb er niks over kunnen vinden): noch met welk algoritme pseudoniemen worden berekend, noch wat er gebeurt bij datalekken van onderzoeksgegevens.

Met het door mij beschreven systeem kan altijd worden herleid (bijv. i.v.m. een rechtszaak), op basis van uniek identificerende gegevens, of voor een uniek geïdentificeerde persoon een gegeven OSBSN ooit kan zijn uitgegeven.

Overheidsorganisaties zouden (mits geauthenticeerd en geautoriseerd) bijv. een BDBSN kunnen opvragen op basis van een IDBSN, maar mogen slechts één OSBSN per burger opslaan. Fragmentatie betekent iets meer werk, maar de waarde van de gegevens daalt waardoor datalekken minder ernstig zijn én dus de belangstelling voor gegevens door cybercriminelen kan afnemen. Oftewel, dit systeem kan veiliger zijn dan één "universeel" BSN per burger.

Verdere dataminimalisatie
Je zou het systeem zo kunnen uitbreiden dat organisaties, zoals woningverhuurders en autogarages, naast per klant een OSBSN, een beperktere set persoonsgegevens opslaan - en die gegevens, op het moment dat zij deze nodig hebben, bij de registerorganisatie kunnen opvragen (na authenticatie en autorisatie). Bij misbruik heb je dan centrale logging en je kunt een rem zetten op bijv. het aantal persoonsgegevens per tijdseenheid. Het lijkt mij bijvoorbeeld in weinig gevallen noodzakelijk dat organisaties de exacte geboortedatum van hun klanten kennen; vaak zal een 18+ vlag voldoen.

Disclaimer: het concentreren van persoonsgegevens op één plaats is als een "pot suiker voor mieren"; de beveiligingseisen voor zo'n register-organisatie zijn dus zeer hoog. Ook het risico, dat herleid kan worden om exact wie het gaat, bij het -gepseudonimiseerd- tracken van bijvoorbeeld patiënten, is erg groot (hoe meer datasets per OSBSN en/of hoe specifieker de medische gegevens of zeldzamer een combinatie van behandelingen, hoe eenvoudiger dat wordt). Ik ben hier geen fan van, zeker niet als de risico's niet door onafhankelijke en ter zake kundige partijen worden gewogen. Maar ik kan geen hemel en aarde bewegen; integendeel, mijn invloed is verwaarloosbaar. Wat ik nog erger vind is het als malloten denken dat een hash van uitsluitend het huidige 9-cijferige BSN, of van de concatenatie van een salt (een niet-geheim organisatiegegeven) en dat korte BSN, onomkeerbaar zou zijn: dat is het niet. Veel te veel "security-deskundigen" denken dat het zin heeft om korte "strings" zoals telefoonnummers of BSN's te hashen, en/of dat je geen MD5 mag gebruiken om wachtwoorden te hashen omdat MD5 gebroken is (onzin, de enige reden is dat MD5 te snel is - maar dat geldt ook voor niet gekraakte cryptografische hashfuncties).

Daarnaast kan het helpen als organisaties, per cliënt, wel een OSBSN bewaren (waar cybercriminelen en datahoarders niet heel veel aan hebben) indien dat er toe leidt dat zo'n organisatie minder andere persoonsgegevens bewaart. Het aantal organisaties dat nu, zonder duidelijke noodzaak, absurd veel persoonsgegevens online opslaat is krankzinnig (zie bijv. https://www.security.nl/posting/795667/Woningcorporatie+Woonkracht10+betaalt+losgeld+na+ransomware-aanval), dat aantal (organisaties) en de hoeveelheid per organisatie bewaarde gegevens moeten absoluut omlaag.

Is er al > Polymorfe Pseudoniemen

https://www.logius.nl/domeinen/toegang/bsnk-pp/hoe-werkt-het

en is in gebruik (eHerkenning)

https://afsprakenstelsel.etoegang.nl/display/BEHEERAS/Polymorf+Pseudoniem

Daar zit m.i. het grootste probleem, dat als je een BSN aanbied bij een (overheids)partij, ze niet voldoende je identiteit verifiëren en het meteen in een proces gaan gebruiken.