Landelijk Schakelpunt biedt geen end-to-endencryptie patiëntdata

Medische informatie die via het Landelijk Schakelpunt, LSP, wordt gestuurd, is niet end-to-end versleuteld. Gegevens worden alleen over de verbindingen versleuteld verzonden. Dat zegt minister voor Medische Zorg Bruins naar aanleiding van PvdD-vragen.

De minister verwijst in zijn antwoord op de kamervraag naar de NEN-7512-norm, die voorschrijft dat er geen end-to-endencryptie nodig is. "Er zijn meerdere manieren om tot een sterke beveiliging te komen. De norm biedt die ruimte", schrijft Bruins.

Volgens de brief meldt een opvragende zorgpartij zich nu vanaf een GBZ via een 'gecertificeerde, beveiligde verbinding, met een sterk identificatiemiddel (de UZI-pas)' bij de VZVZ, de beheerder van het LSP. Bruins geeft wel aan bij normenonderzoeker NEN te vragen of een aanpassing van de norm wenselijk is, 'naar aanleiding van de stand van de techniek'.

De brief van de minister voor Medische Zorg was een reactie op vragen van Christine Teunissen, Kamerlid van de Partij voor de Dieren. Zij vroeg tijdens een debat of de betreffende informatie end-to-end beveiligd is. Zij zegt 'geluiden' te hebben gehoord dat de Amerikaanse beheerder van het LSP - CSC - tussen de connectie van zorgverleners zou kunnen zitten. Daarnaast is het Kamerlid van mening dat de datawisseling tussen medische instellingen versleuteld zou moeten zijn, van begin tot eind. "Dat is een logische eis."

Het LSP is een zorgnetwerk voor zorgverleners waar zelf geen medische informatie in wordt opgeslagen, alleen een verwijsindex met burgerservicenummers. Het netwerk is ontwikkeld na het stoppen met het epd.

Reacties (117)

[Snuffert]

Het netwerk is ontwikkeld na het stoppen met het epd

Het LSP is niet ontwikkelt nadat men met het EPD is gestopt. Het EPD was het LSP, de terminologie is compleet verkracht in het privacy debat destijds. Het huidige LSP is na het stoppen door de overheid met “het EPD” volledig privaat geworden en voortgezet vanuit het bedrijfsleven. Het LSP is precies wat de overheid voor ogen had met het “het EPD”. Lichtelijk ironisch dat een dergelijk project de nek is omgedraaid om privacy redenen om daarna (zonder fatsoenlijk toezicht) privaat te worden voortgezet.

EPD’s bestaan al jaren, patient gegevens worden ook al jaren elektronisch uitgewisseld. Het LSP is eigenlijk niks meer dan authenticatie, authorisatie, logging en auditing. Het LSP is geen standaard voor gegevensuitwisseling, het biedt infrastructuur voor gegevensuitwisseling in bijv. de HL7 standaard.

Neemt niet weg dat we hier uiterst kritisch op moeten zijn, vooral op gebieden als encryptie authenticatie mechanismes etc. Maar enige nuance is naar mijn mening op zijn plaats

[Reactie gewijzigd door Snuffert op 23 juli 2024 00:34]

[CJ_Latitude]

Eens, het is voor mensen die wel weten hoe het werkt (onze software sluit ook aan op het LSP), bijna ondragelijk te zien hoeveel mensen maar wat roepen, niet gehinderd door enige kennis van zaken. Gelukkig zijn er in deze thread ook mensen die het verhaal compleet maken (dank @Snuffert, @Paul, @icerunner, @stiefen).

Als je ziet door welke hoepels wij als softwareontwikkelaar soms moeten springen om aan gegevens te komen die de zorgverlener nodig heeft om goede zorg te leveren, doet het bijna pijn om door zoveel mensen afgeschilderd te worden als een sector die maar wat aanklooit.

Er zijn echter zeker ook stukken aan het verhaal waar ik kritisch op ben:
- "het EPD" is zo ondenkbaar slecht uitgedragen door de overheid dat het geen verrassing is dat men tegen heeft gestemd;
- UZI-pas is duur, onhandig, instabiel (het werkend krijgen op bijv. een Citrix omgeving is een drama) en de nieuwste versie (wel stuk beter) is al 2 jaar enkel voor Windows te krijgen. Dit werkt de acceptance niet in de hand, maar het slordig zijn erop wél.

[ollie1965]

- UZI-pas is duur, onhandig, instabiel (het werkend krijgen op bijv. een Citrix omgeving is een drama) en de nieuwste versie (wel stuk beter) is al 2 jaar enkel voor Windows te krijgen. Dit werkt de acceptance niet in de hand, maar het slordig zijn erop wél.

UZI pas is toch niet meer dan een PKI(-O) certificaat welke persoonsgebonden (gerelateerd aan de organisatie) is? Dat kan gewoon werken binnen Citrix, althans mijn PKI-O persoonsgebonden certificaat werkt wel (en dat in een oude Citrix omgeving).
Duur? Tja het is het gecertificeerde proces wat de kosten verzaakt, de techniek/middelen zijn volgens mij niet de kosten.
Dat mannetje om de persoonlijke identificatie te doen, paspoortscan op echtheid, zetten en vergelijken van de handtekening, afspraak op gewenste locatie enfin € 150,-- verder was mijn identiteit echt vastgesteld.

[stiefen]

je moet hier een verschil zien tussen een UZI pas en een UZI certificaat.
Het certificaat is niets anders dan een gaaf certificaatje geleverd door de overheid.

De UZI pas is een smartcard die gebruikers (lees artsen en ander BIG geregistreerde medewerkers) bij zich dragen om te identificeren. Die paslezers en pasjes kosten bakken met geld en moeten op naam aangevraagd worden. De infra die je hiervoor moet aanleggen om dit rond te krijgen is simpelweg een hel qua werk en kosten.

[DarkBlazer]

Dit kan ook door middel van een eToken gebasseerd op basis van Gemalto/Thalis.
Een kaart kan uit gelezen worden door een speciale kaart lezer die werkt op RS232/USB.

De eToken is eigenlijk niks anders dan een smartcard en kaart lezer in een die zonder additionele software direct onder Windows werkt. Ja het is mogelijk om met de software van Gemalto/Thalis Safenet Authentication Client je te kunnen aanmelden bij de software en bij Windows, maar ook dat je de geldigheid kan zien van je certificaat.

De productie kosten vallen opzich wel mee, wat gewoon veel kost is de identificatie door de koerier om je identiteit vast te stellen en op basis daarvan om je certificaat aan te maken.

@ollie1965
Bij het bedrijf waar ik werk hebben we het zelfde process door moeten lopen om voor onze 3 directeuren een eiDAS (PKI-O) certificaat aan te vragen.
Het probleem is dat na 3x het verkeerde wachtwoord je weer het hele process moet door lopen om een nieuwe pas/eToken te krijgen om dat de certificaat waar je 3x het verkeerde wachtwoord verkeerd hebt ingegeven ongeldig is verklaard.

Wat ik wel vreemd vind is dat de LSP geen gebruikt maakt van End-to-End encryption terwijl tenderned.nl en https://www.publicprocurement.be/nl dat wel hebben doormiddel van een PKI-Overheidscertifcaat / eiDAS certificaat.

[ollie1965]

Bij het bedrijf waar ik werk hebben we het zelfde process door moeten lopen om voor onze 3 directeuren een eiDAS (PKI-O) certificaat aan te vragen.
Het probleem is dat na 3x het verkeerde wachtwoord je weer het hele process moet door lopen om een nieuwe pas/eToken te krijgen om dat de certificaat waar je 3x het verkeerde wachtwoord verkeerd hebt ingegeven ongeldig is verklaard.

Dat zijn wel hele slordige directeuren, gaan ze ook zo slordig om met hun paspoort*?


_{* Met je eIDAS niveau 4/hoog mag je elektronische rechtmatige handelingen doen en staat dus gelijk aan je paspoort.}

[DarkBlazer]

Nee dat is het probleem niet, het probleem is dat we onze eigen eToken gebruiken voor het inloggen op het systeem. we hebben zelfs de eiDAS token gelabelled, het kan gebeuren van tijd tot tijd dat de mensen hun eiDAS token gebruiken voor het opstarten door SafeBoot/Pre-Boot authentication en dat werkt niet. Daarom hebben wij als IT afdeling de eiDas tokens gemarkeerd met een label zodat duidelijk is welke Token ze gebruiken, maarja fouten maken is menselijk helaas.

[ollie1965]

De UZI pas is een smartcard die gebruikers (lees artsen en ander BIG geregistreerde medewerkers) bij zich dragen om te identificeren. Die paslezers en pasjes kosten bakken met geld en moeten op naam aangevraagd worden. De infra die je hiervoor moet aanleggen om dit rond te krijgen is simpelweg een hel qua werk en kosten.

Ik weet in hoofdlijnen wat de pas/certificaat enz is (heb zelf een middel op niveau 4 (stork)/hoog (eIDAS).
De paslezer is toch onafhankelijk van de pas met daarop het certificaat, of werkt dat bij de UZI pas anders?
Dan zie ik nog steeds niet de kosten (als het onafhankelijk kan werken).

[DarkBlazer]

De principe is het zelfde als bij je pas wat je hebt bij eH-Niv4 / eiDAS token.
Alleen je eH-Niv4 / eiDAS is token based (Gemalto / Thalis eToken). De UZI pas is niks anders dan een bankpas formaat waar het certificaat in zit in ingebakken SIM chip.

Verschillen zie je hier onder in de link.
https://indeed-id.com/en/cm-hardware

[janbaarda]

Juist, het LSP is volledig privaat en beheerd door een Amerikaans bedrijf dat onder de Patriot Act valt. Een 'end to end' versleuteling zou hier zeker op z'n plaats zijn ...

Ik ben het volledig met je eens dat de politiek het hier verprutst heeft.

[mrozeboom]

Welk Amerikaans bedrijf is dat dan? CSC niet meer toch?

[Reactie gewijzigd door mrozeboom op 23 juli 2024 00:34]

[mrtl]

Dus mijn BSN is opgeslagen bij een Amerikaans bedrijf? Volgens mij heb ik ooit akkoord gegeven bij een apotheek hiervoor, maar dat het hele ding door een buitenlandse mogendheid beheerd wordt is nieuw voor mij.

[demonic]

Als ik het goed begrijp is potentieel alle (medische) informatie opgeslagen bij een buitenlandse toko.

Geen end-to-end encryptie betekent ten slotte dat de tussenpersoon alles kan meelezen. (dus ook opslaan)

[FreezeXJ]

Hangt er een beetje vanaf, maar het LSP slaat zelf geen medische data op, alleen bij welke provider je die data kunt opvragen. Daarna verstuurt jouw arts een (digitaal ondertekend) bericht met het verzoek om die info. Daar krijgt hij dan een (wederom digitaal ondertekend) antwoord op van de andere partij, als z'n ondertekening klopt. Let wel dat de data alleen ondertekend is, en niet encrypted.
Dat is dan precies waar de PvdD terecht vragen over stelt.

[Paul]

Hoe het de pijp uit komt (lees: de data die terug komt op de SOAP of RESt-call) kan ik je niet vertellen, maar de pijp zelf is zowel ondertekend als encrypted; er wordt van client- en serverauthenticatie gebruik gemaakt; de ontvangers zijn de enige die het kunnen decoderen want dat zijn de enige met de benodigde sleutels.

Aan de kant van het LSP zelf weet ik het niet, maar eenmaal aangekomen bij de zorgverlener (ik neem even mijn werkgever als voorbeeld) wordt het wel degelijk encrypted opgeslagen. Het systeem kan er wel bij, maar als je de harddisks steelt heb je een paar leuke SSD's, maar geen medische gegevens.

Het is niet end-to-end in de zin dat huisarts Klaas iets in die database zet, en ziekenhuis Piet de enige is die het kan lezen. Dat is ook zeer lastig te bewerkstelligen, want je weet van te voren helemaal niet wie die database gaan raadplegen. Ziekenhuizen komen er niet zo heel veel bij, maar huisartsen en andere praktijken bijvoorbeeld wel vaker, en je kunt niet iedere keer naar Klaas gaan met de vraag om alles wat ze al ooit een keer geüpload hebben nog een keer te uploaden maar dan encrypted met de eigen private key en de publieke sleutel van huisarts Jan.

Het LSP is geen communicatiekanaal wat je on the fly e2e kunt encrypten, het is een database. Je kunt het aan alle kanten encypten, maar van origineel endpoint, tussendoor opslaan, en dan ergens in de toekomst naar een nu nog onbekende ontvanger, ik zou niet weten hoe ze dat moeten doen.

[Reactie gewijzigd door Paul op 23 juli 2024 00:34]

[MadEgg]

Tussendoor opslaan? Ik heb van de week de folder van LSP doorgelezen en zoals het daar staat komen de gegevens rechtstreeks van de betreffende zorgverlener. Lijkt me technisch onhoudbaar aangezien dan elke zorgverlener een heus serverpark moet gaan draaien daarvoor, maar zo wordt het wel verteld.

Hoe verschilt het dan van het EPD? Het “voordeel” van het LSP zou zijn dat het niet gecentraliseerd opgeslagen wordt maar juist bemiddeld tussen de zorgverleners.

[Paul]

Zoals ik het lees weet het LSP alleen welke patiënt bij welke zorgverlener is geweest. Die data hebben ze opgeslagen staan.

Wat die patiënt bij die zorgverlener heeft gedaan, het dossier, dat hebben ze niet. En een EPD is nu juist dat: een elektronisch patiënten dossier. Zodra jet LSP je vertelt bij wie je moet zijn weet je dus bij wie je aan moet kloppen om het dossier van de patiënt op te vragen, maar dat deel gaat buiten het LSP om.

[MadEgg]

Is het in met elkaar in contact brengen niet juist ook onderdeel van het LSP? Als je medewerking van de andere zorgverlener nodig hebt heeft het toch geen voordelen meer als je bijvoorbeeld midden in de nacht bij het ziekenhuis bent?

[Paul]

Dat het niet via het LSP loopt wil niet zeggen dat het niet elektronisch kan En misschien heeft het LSP ook de gegevens hoe je het dan elektronisch opvraagt bij die andere zorgverlener, geen idee, ik werk niet met dat deel van de software Ik weet wel dat onze verbinding met het LSP alleen van ons naar het LSP faciliteert, er draaien geen services, zijn geen open poorten of firewall regels voor verbindingen die het LSP initieert naar ons.

Als je midden in de nacht bij het ziekenhuis staat sta je meestal op de spoedeisende hulp, en die vragen bij mijn weten sowieso al amper externe dossiers op. Het is voor bijvoorbeeld een reumatoloog handig te weten wat de reumatoloog in je vorige woonplaats allemaal heeft gedaan, maar als de SEH een gebroken been in het gips moet zetten hoeven ze niet te weten of je apneu hebt, of een ruisende hartklep. Die zetten gewoon je been in het gips. Even kort door de bocht dan

Nu heeft het LSP het vooral over huisartsen en apotheken en werk ik voor een ziekenhuis, mogelijk dat huisartsen en apotheken wel hun dossiers delen met het ziekenhuis maar dat andersom niet of amper voor komt? Ik weet dat ons EPD wel een optie biedt om bij andere ziekenhuizen (sowieso die dezelfde software gebruiken als wij, maar volgens mij ook bij gestandaardiseerde document exchanges) dossiers op te vragen, daar is wel inbound en outbound infrastructuur voor.

[Reactie gewijzigd door Paul op 23 juli 2024 00:34]

[icerunner]

Ik ben huisarts. Onze data staat 'in the cloud' (Promedico-ASP). Promedico heeft een verbinding via het gesloten zorgnetwerk (E-zorg) naar het LSP. Als ik op de huisartsenpost werk, vraagt het HIS automatisch de laatste contacten en medicatie uit bij de eigen huisarts, indien de patiënt toestemming heeft verleend voor het LSP. Altijd. Superhandig - ik zie direct wat er gister door de eigen huisarts gedaan is, en kan de patiënt gerichter helpen. Ook wordt medicatie uitgevraagd. Veel ziekenhuizen doen dit oom automatisch, voor medicatie. Schrijf je maar eens in op Volgjezorg.nl en vink aan dat je een alert wilt als jouw dossier uitgevraagd wordt. Ik kreeg keurig 3 dagen voor een poli-afspraak een melding: de Meander-apotheek vroeg alvast mijn medicatielijst op. Idem bij een keer een recept bij de dienstapotheek: direct melding per mail dat er een LSP-uitvraag werd gedaan.
Overigens kun je ook met een lokale server in je praktijk aangesloten zijn. Nadeel van lokaal werken is de dure E-Zorg verbinding (laatste keer dat ik 'm had €120 per maand voor 8/4mbit oid, medio 2014). Je server krijgt een servercertificaat op aorta.e-zorg.nl.
Gezien het feit dat alle systemen verbonden zijn vraag ik me sterk af of de servers van CSC wel de inhoudelijke data ontvangen, zoals hierboven soms genoemd wordt - volgens mij zijn ze echt alleen een telefoonboek, die A verteld dat C de gegevens heeft die A aan het zoeken is, en dat A dus bij C aan moet gaan kloppen...?

[GMJansen]

Interessant verhaal.
Je laatste conclusie klopt volgens mij ten dele.

Wat ik eruit haal is:
A vraagt aan het LSP wie de gevraagde patiënt data heeft.
Vervolgens stuurt het LSP je door naar C.
C geeft de data aan A.

Wat hier nu de discussie is, is dat die data stroom niet tussen A en C end to end encrypt wordt;
Alleen tussen A en LSP en C en LSP.
P.s. Volgens mij is de lijn overigens niet encrypted, dat zou dus betekenen dat alleen het verkeer encrypt wordt. Maar dat terzijde.

M.a.w. de data die door het LSP wolkje loopt kan theoretisch prima ontsleuteld worden door CSC (en dus doorgesluisd worden naar derden)

[stiefen]

Klopt bijna helemaal.
De data terug van C naar A gaat niet via een aparte site-to-site verbinding maar ook terug via het LSP.
Het hele LSP is ingepakt via het netwerk van KPN e-Zorg die ervoor zorgen dat de verbinding sterk afgesloten is van de buitenwereld.
Daarnaast moet iedere partij die hier gebruik van wil maken aan de client-side een UZI certificaat hebben staan. Dit is een SSL certificaat uitgeleverd door de overheid.
In mijn ogen zie ik geen mogelijkheden voor CSC om te ontsleutelen, hoewel ik daarbij moet aangeven dat ik niet zeker ben welk onderdeel ze precies beheren of in handen hebben.
De data wordt in ieder geval niet opgeslagen in het LSP, dus al helemaal niet op buitenlandse servers.

[RobZw]

de Amerikaanse beheerder van het LSP - CSC

Volgens Wikipedia (en) is CSC defunct. In 2017 overgenomen door HP

[stiefen]

Hmm fair enough, kan het echter nog altijd niet in de keten plaatsen. Ik ben op dit moment bezig met een LSP integratie en heb alleen met KPN en VZVZ te maken.
Stel dat ze netbeheerders zijn van de onderlaag, dan komen ze er nog niet aan omdat er een SSL encryptie op de verbinding hangt.

[[Yellow]]

Als ik Snapchat gebruik zie ik ook nergens dat ik eigenlijk Amazon AWS aan het gebruiken ben. Of waar de servers staan. Dat je er niet mee te maken hebt wil niet zeggen dat je data er niet doorheen gaat (imho uiteraard).

[TheDutchChief]

Nu ja, de tijd dat de patiëntgegevens bij de huisarts op de harde schijf stonden is wel voorbij. Bij ons in de regio één huisartssysteem, maar de HA kan alleen bij zijn eigen patiënten. Dus ja, er staat een serverpark met alle toeters en bellen. Maar de weekenddienst kan met toestemming van de patient in zijn dossier. En als een patient toestemming geeft kan het ziekenhuis-EPD ook weer gegevens ophalen uit de systemen van de apotheek. Maar dan moet je wel weten welke apotheek. Daar zorgt het LSP weer voor. Bijhouden waar toestemming voor is en waar de gegevens zijn.

[Mellow Jack]

In feite krijg je de vraag bij het wisselen van bijv huisarts of ze jou gegevens mogen opvragen bij je oude huisarts. Natuurlijk zullen hier wat softwareboeren op in gesproken zijn maar in feite is dat in theorie het mooie aan het systeem. Kan me daarentegen ook wel weer voorstellen dat het ziekenhuis dit ook weer kan doen bij je huisarts en er een spoedlijn is voor uuh spoed

Het is dus vrij simpel bij te houden wie bij welke gegevens mogen maar of dat ook zo is gebouwd weet ik niet. De usecase alleen is niet zo onmogelijk als het lijkt

[Verwijderd]

Als ze de data versleuteld versturen over niet E2EE dan hebben ze nog steeds maar een versleuteld stukje data. Mits dat goed versleuteld is, is er niet echt een issue.

[MSalters]

mijn BSN is opgeslagen bij een Amerikaans bedrijf?

Waar lees je dat??

Zoals in het artikel al staat: geen medische informatie wordt opgeslagen.

Net zoals een telefoonbedrijf informatie kan versturen zonder het op te slaan, zo kan deze berichtendienst medische informatie versturen zonder het op te slaan.

[Verwijderd]

BSN is ook geen medische informatie.

[Recursio]

Ik heb ooit begrepen dat BSN's uitgegeven worden met een volgorde (geen willekeurige cijferreeks waar uit getrokken wordt zeg maar).

*Als* dat inderdaad zo is, *dan* zou je een goede schatting van de leeftijd van de eigenaar van het BSN kunnen maken.
Leeftijd is bij benadering een persoonsgegeven, en inderdaad nog geen medisch gegeven. Maar wie ouder wordt krijgt een grotere kans op het maken van "zorgkosten". Als je honderd jaar oud bent, durf ik de gok wel aan dat je steunkousen hebt, bijvoorbeeld. Klopt niet altijd, maar daar gaat het niet om.

Waar het wel om gaat; kunnen diegenen van wie de gegevens zijn (over wie die gegevens iets zeggen) erop vertrouwen dat die gegevens niet in *verkeerde handen* komen?

*Verkeerde handen* wil zeggen: een partij die deze gegevens niet mag verwerken, en/of een partij die deze gegevens wel mag verwerken maar niet op dat moment en/of voor dat doel en/of door de persoon die op dat moment de gegevensverwerker is?
=> Als dat technisch *niet* mogelijk is (zoals bij end-to-end-encryptie) dan is er geen reden tot zorg, tenzij de encryptie zwak is.
=> Als het technisch *wel* mogelijk is, dan mogen we ons best zorgen maken, want de intentieverklaring "we zullen er vertrouwelijk mee omgaan" doorstaat nogal eens de praktijktoets niet.

[trab_78]

Wat betreft je ingewikkelde redenatie om uit een BSN een leeftijd af te leiden: leuk bedacht. Maar het BSN zélf is een persoonsgegeven. Het mag maar om een beperkt aantal redenen door een beperkt aantal partijen verwerkt worden. Zorginstellingen vallen daar onder. Maar daarom dus wel een reden om er voorzichtig mee om te gaan!

[bazs2000]

Ik werk dagelijks met vele honderden BSN-nummers en kan je vertellen dat een lage nummering niet per definitie is gekoppeld aan een persoon met een hoge leeftijd. Ja, lage nummeringen zie je vaker bij mensen met hogere leeftijden al is dit niet altijd het geval dus kun je bij een lage nummering niet zomaar de leeftijd schatten.

Verder ga ik wel wet jouw vraag mee en persoonlijk denk ik niet dat je erop kunt vertrouwen dat de gegevens niet in verkeerde handen vallen. Wat nu veilig is kan morgen onveilig zijn. Morgen wordt er misschien een email verzonden met een excelletje als bijlage met daarin de gegevens van vele mensen. Dit is al eerder gebeurd en niemand kan uitsluiten dat het in de toekomst ook zal gebeuren.

"We zullen er vertrouwelijk mee omgaan" is per definitie waar omdat alle bedrijven en instanties wel goede bedoelingen hebben. Helaas heeft niemand iets aan goede bedoelingen wanneer gegevens uitlekken.

We kunnen alleen maar hopen dat het voor nu, en in de toekomst goed zal gaan.

[R4gnax]

"We zullen er vertrouwelijk mee omgaan" is per definitie waar omdat alle bedrijven en instanties wel goede bedoelingen hebben. Helaas heeft niemand iets aan goede bedoelingen wanneer gegevens uitlekken.

Behalve data bedrijven gezeteld in andere landen onder de wetgeving van die landen gedwongen kunnen worden mee te werken aan het exfiltreren van data en gedwongen kunnen worden daar hun mond over te houden.

Bijv. zoals onder de Amerikaanse Patriot Act.

[Reactie gewijzigd door R4gnax op 23 juli 2024 00:34]

[Verwijderd]

Maar wel een bijzonder persoonsgegeven die niet elke partij mag verwerken.

[The Lord]

Officieel is het BSN geen bijzonder persoonsgegeven volgens de AVG.

Dit laat onverlet dat er afdoende maatregelen moeten worden genomen om een BSN te verwerken; als er überhaupt al een wettelijk grondslag voor het verwerken van de BSN is.

[Verwijderd]

https://autoriteitpersoon...e/burgerservicenummer-bsn

Organisaties buiten de overheid mogen het BSN alleen gebruiken als dat wettelijk is bepaald. Dit geldt bijvoorbeeld voor zorgverleners, zoals huisartsen, apotheken en zorgverzekeraars.

Een nummer dat bij wet is voorgeschreven om een persoon te identificeren, mag alleen mag worden gebruikt voor de uitvoering van die wet. Of voor doeleinden die in de wet staan. Dat staat in artikel 46 van de Uitvoeringswet Algemene verordening gegevensbescherming (UAVG).

Het BSN is zo’n identificatienummer. Organisaties kunnen het verbod om het BSN te gebruiken niet doorbreken door toestemming aan mensen te vragen voor het gebruik van hun BSN.

[R4gnax]

Officieel is het BSN geen bijzonder persoonsgegeven volgens de AVG.

Klopt.

Artikel 87 betr. de verwerking van nationale identificatie-nummers stelt dat lidstaten zelf aanvullende condities mogen stellen voor de verwerking van deze gegevens, mits dat plaatsvindt met voldoende waarborgen voor de rechten en vrijheid van het subject, in overeenstemming met wat er in de Verordening geschreven staat.

Maar de AVG zelf schaart dit soort ID-nummers niet onder extra beschermde bijzondere persoonsgegevens.

[Loggedinasroot]

Het LSP is een zorgnetwerk voor zorgverleners waar zelf geen medische informatie in wordt opgeslagen, alleen een verwijsindex met burgerservicenummers.

...dat de Amerikaanse beheerder van het LSP - CSC

Dus ik gok dat ze wel de BSN's hebben. En medische data wordt er niet in opgeslagen, maar ze kunnen er wel makkelijk tussenkomen en deze data alsnog bemachtigen als ik het goed begrijp en de mevrouw het goed heeft "gehoord".

[FreezeXJ]

En medische data wordt er niet in opgeslagen, maar ze kunnen er wel makkelijk tussenkomen en deze data alsnog bemachtigen als ik het goed begrijp en de mevrouw het goed heeft "gehoord".

Dan ben ik heel benieuwd hoe, want ze zien de informatie-berichten zelf niet. Alleen het verzoek om info, waarna partijen het zelf verder wel kunnen regelen.

[mrdemc]

Als ik de AORTA-documentatie erbij pak zo gauw op Mn telefoon zie ik dat er geen directe communicatie tussen de systemen is en de dataoverdracht via dit systeem gaat. Gezien de verbinding beveiligd is tussen de applicatie en de server, maar de data zelf niet, heeft de server dus de data onbeveiligd in het geheugen.

]...[ = encrypted
Client]....[server]....[client
I.p.v. e2ee:
Client]....server....[client

[Reactie gewijzigd door mrdemc op 23 juli 2024 00:34]

[R4gnax]

[...]

Dan ben ik heel benieuwd hoe, want ze zien de informatie-berichten zelf niet. Alleen het verzoek om info, waarna partijen het zelf verder wel kunnen regelen.

Verbindingen voor overdracht lopen schijnbaar via de LSP servers, die letterlijk - de naam zegt het al - als Landelijk Schakel Punt dient, en waarbij de encryptie getermineerd wordt bij de LSP servers.

Dat wil zeggen: er is bij overdracht van gegevens tussen systeem A en B encryptie van systeem A tot het LSP en van het LSP tot aan systeem B. Maar aan beide kanten is het een LSP server waarmee gecommuniceerd wordt, en heeft deze server inzicht in de niet-versleutelde brondata.

Je moet de beheerder dan ook maar geloven als er gezegd wordt dat er niemand iets aftapt en vastlegt voor nadere inspectie. Hard maken via degelijke encryptie-technologie zoals end-to-end encryptie van de payload met gevoelige medische data, kunnen ze in deze namelijk niet.


En gezien het hier een Amerikaanse uitvoerder betreft, is dat aftappen een niet ondenkelijk scenario. Het zou enkel weer het zoveelste schandaal zijn wat met alle geweld een doofpot in geduwd moet worden.

[Reactie gewijzigd door R4gnax op 23 juli 2024 00:34]

[Loggedinasroot]

Ik heb in ieder geval geen idee. Ken dit hele systeem niet.

[Chicken]

Staat er toch echt:
Het LSP is een zorgnetwerk voor zorgverleners waar zelf geen medische informatie in wordt opgeslagen, alleen een verwijsindex met burgerservicenummers.
Een BSN is geen medische informatie.

[jqv]

Maar het zijn wel persoonsgegevens. En met een aantal andere gegevens erg handig bij identiteitsfraude.

[WaaaghNL]

Beetje offtopic, Maar waarom geeft de Belastingdienst je BSN nummer als BTW nummer met B01 aan het einde wanneer je een eenmanszaak begint? Dit nummer ben je nog een verplicht rond te strooien aan een hoop instanties. Dat ook nog vaak met je naam, adres, en geboortedatum.

[TweakingRens]

Dat wordt ook veranderd binnenkort, AP heeft daar een stokje voor gestoken als ik het mij goed herinner.

[jqv]

https://www.mondtadviesgr...r-zzp-er-wordt-aangepast/

Dat klopt.
In 2020 pas

[latka]

En het speelt pas 10+ jaar.

[CH4OS]

Een BSN is dan ook vooral dat geen medische informatie, maar persoonsgegevens. Dus ik begrijp even niet waarom je specifiek dat stukje tekst aanhaalt. Gezien het 'geen medische informatie' is, kan het blijkbaar dus wel opgeslagen worden?

[Reactie gewijzigd door CH4OS op 23 juli 2024 00:34]

[totaalgeenhard]

Je moet eens naar preferred partners kijken van overheid daar staan volop Europese en non-Europese bedrijven tussen.

[Wallus]

Je vingerafdruk(als je die ooit hebt afgeven) staan volgens mij bij een Frans bedrijf meen ik

[Z80]

Niet waar. De vingerafdrukken mogen niet centraal opgeslagen worden.
https://tweakimg.net/file...n-Haag-geanonimiseerd.pdf

[WillySis]

Ja, dat zou zomaar kunnen. De overheid heeft meerdere contracten met Amerikaanse bedrijven.
Zie: https://www.security.nl/p...s+niet+in+handen+VS+komen

[slijkie]

Tegenwoordig (al aantal jaar) als je via Independer afsluit krijg je er vaak iets van een ‘tandongeval’ verzekering erbij, vaag verhaal, maar na uitzoeken blijkt dat dus een Amerikaanse verzekeraar te zijn. Was ik niet blij mee toen ik daar achter kwam.

[Jace / TBL]

Medische informatie die via het Landelijk Schakelpunt, LSP, wordt gestuurd is niet end-to-end versleuteld. Gegevens worden alleen over de verbindingen versleuteld verzonden.

En dus hoogstwaarschijnlijk ook niet eens encrypted opgeslagen. Of "encrypted" opgeslagen met de sleutel erbij.
Het is dus een kwestie van tijd voordat er een keer een database gaat lekken, en verzekeringsmaatschappijen of afpersers al die data in handen krijgen.

Dit krijg je er nu van als je incompetente overheids-beleidsmakers zonder kennis van zaken de regels laat verzinnen voor dit soort zeer privacygevoelige zaken.

De minister verwijst in zijn antwoord op de kamervraag naar de NEN-7512-norm, die voorschrijft dat er geen end-to-endencryptie nodig is.

De norm voor encryptie zou "end-to-end or GTFO" moeten zijn

[MSalters]

End-to-end encryption vereist 100% dat er (session) keys gedeeld worden tussen de end points. Hoe had je dat key management voor je gezien in deze situatie? Die endpoint pairs zijn niet bij voorbaat bekend maar hangen af van de medische urgentie.

Point-to-point encryption betekent dat de links beveiligd moeten worden met key pairs, maar die links zijn dan weer relatief statisch. Zo vaak komen er geen nieuwe deelnemers bij, en dat is ook nooit urgent.

Ik snap goed dat overheden zich weinig aantrekken van de beschuildiging van incompetentie. Die komt maar zelden van partijen die er wél wat van af weten.

[Armin]

Ik snap goed dat overheden zich weinig aantrekken van de beschuldiging van incompetentie. Die komt maar zelden van partijen die er wél wat van af weten.

In dit geval eens. End-to-end is in dit geval ook een mode woord, maar in de praktijk levert het in dit geval weinig op.

End-to-end is nuttig indien je data van A via B naar C gaat en je B niet vertrouwt. Het heeft weinig meerwaarde als je bang bent dat iemand bij C inbreekt en meeleest of als A 's login gehacked kan worden. Ook zijn er bij deze dossiers nog A2, A3 t/m A200659 die ook allemaal een dossier moeten kunnen inzien. Dus het idee dat B niet te vertrouwen is, maar al die talloze A's wel, is ook maar subjectief.

Het belangrijkste is dat de authenticatie bij C is met twee-traps authenticatie voor alle A's en een goede audit zodat een gehackde A meteen eruit gekiepert wordt. Ofwel concreet dat dokters, medische instellingen, etc verplicht met niet enkel wachtwoord moeten inloggen, maar met een 2FA of pasje/chip. Plus dat er een actieve audit is zodat men snel kan ingrijpen als een individuele 'client' (dokter, etc) gehacked is.

Men spreekt van een sterk identificatiemiddel, maar ik vermoed dat men bedoeld sterk identificatie- én authenticatiemiddel ("chip in die pas"). Zo ja, dan ben ik niet zo bezorgd dat er geen end-to-end is.

[janbaarda]

End-to-end is nuttig indien je data van A via B naar C gaat en je B niet vertrouwt.: dat is nu net het geval. B, het LSP, wordt beheerd door een Amerikaans bedrijf!...

[Armin]

En Amerikaanse bedrijven kunnen we niet vertrouwen? Dan ook alle Cisco en Huawei apparatuur eruit?

Als het argument is dat data zelf niet in het buitenland mag zijn, ben ik het overigens met je eens. Dat plus goede waarborgen voor deze LSP-beheerder. Maar of dat nu een Belgisch, Nederlands of Amerikaans bedrijf is maakt dan niet zo veel uit. Liefst wellicht Nederlands, maar we moeten ook erkennen dat Amerikaanse bedrijven nu eenmaal in de ICT vaak ook kwalitatief erg competatief zijn.

[janbaarda]

Je zegt het: alleen EU bedrijven hebben de voorkeur. Deze kunnen niet door zoiets als de Patriot Act onder druk worden gezet. HW/infrastructuur is een ander probleem.

Wat betreft het LSP, dit hoort in overheidshanden. Net als andere crusiale infrastructuur (Persoonsregister, Belastingsystemen, enz.)

[Armin]

Deze kunnen niet door zoiets als de Patriot Act onder druk worden gezet.

De Patriot Act bestaat al enige jaren niet meer. Overigens heeft Nederland ook haar eigen equivalent van wat de Patriot Act was. Zo vragen wij data opgeslagen in de USA gewoon regelmatig op.

Wat betreft het LSP, dit hoort in overheidshanden

Maar hadden we nu net niet besloten dat we geen centraal landelijk medisch dossier wilden?

[janbaarda]

LSP is GEEN centraal medisch dossier. Slechts een doorgeefluik met de nodige autorisatie.

[Armin]

Precies, maar als de staat het doorgeefluik wordt wat is dan het verschil?

[janbaarda]

Het verschil is dat ik een buitenlandse partij minder vertrouw dan de Nederlandse staat. Wellicht onterecht, maar de staat kun je ter verantwoording roepen via ons democratisch proces; er is meer controle op.

In het geval van LSP is de buitenlandse partij ook nog eens verplicht (bij buitenlandse wet; ergo geen controle) om desgevraagd onze gegevens beschikbaar te stellen.

[Armin]

In het geval van LSP is de buitenlandse partij ook nog eens verplicht (bij buitenlandse wet; ergo geen controle) om desgevraagd onze gegevens beschikbaar te stellen.

Ja, echter zoals ik al zei is dat niet meer zo.

De befaamde Patriot Act bestaat al enige tijd niet meer, en de rechter in de VS heeft verder al restricties opgelegd.

Verder kun je veel regelen met lokale opslag en sleutels. Zo'n buitenlands bedrijf heeft doorgaans geen enkel belang bij 'bij de data kunnen'.

[3raser]

Als het om medische informatie gaat vind ik dat die de landsgrenzen sowieso niet mogen overschrijden. Iedere partij in de keten zou dus een Nederlands bedrijf moeten zijn zonder dubbele regelgeving (zoals een patriot act die mogelijk van toepassing is). Er moet zonder blikken of blozen kunnen worden uitgelegd dat in alle gevallen alleen het Nederlandse recht van toepassing is op de gegevens.

[Verwijderd]

Geloof je serieus dat Amerika te vergelijken is met Europa? Het zit dichter tegen China aan. Als een bedrijf gegevensbescherming (en continuïteit, want ze kunnen gewoon de hardware meenemen waar jouw hostingpakketje opstaat of je nou het doelwit bent of niet) serieus neemt, host het 100% binnen Europa. Er bestaat geen recht op privacy in Amerika, net zoals wij dan weer niet kunnen toetsen aan de grondwet. De Patriot Act is een geweldig argument als je wel eens bij een hostingbedrijf hebt gewerkt. Voor medische informatie van Nederlandse mensen geldt natuurlijk dat het gewoon in beheer moet zijn onder Nederlands recht.
Dit moet natuurlijk door een onafhankelijke overheidsinstelling terechtkomen, en dan moeten we er goed op toezien dat geen enkel ander overheidsonderdeel met zijn tengels erin gaat graven naar terroristen die helemaal niet bestaan.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:34]

[Armin]

Geloof je serieus dat Amerika te vergelijken is met Europa? Het zit dichter tegen China aan

Geklets!

China is een dictatuur met concentratiekampen. Letterlijk concentratiekampen! Een land waar gevangen on-demand geexuteerd worden om organen te oogsten voor rijke kopers. Een land waar christen en moslims vervolgd worden voor hun geloof. Een land wat mensen met een bepaalde nationaliteit arresteerd worden als wraak voor een politiek conflict met een buitenland. Een land wat geen vrijheid van meningsuiting heeft, waar corruptie hoogtij voert en wat alles los en vast kopieert van elk ander land. Een land met nihil moraal betreft milieuvervuiling etc.

Als je een land als Amerika serieus met China wilt vergelijken, kan ik enkel zeggen dat je je emoties aan de kant moet schuiven en je meer moet verdiepen in de realiteit betreft China. Kritiek op Amerika kan, maar het is nog steeds de werelddeel dat het dichtst bij ons staat. En China is een land dat ons goedkope spullen en een leuke afzetmarkt geeft, maar eigenlijk een land is dat qua ethiek bijna niet verder weg kan staan van waar wij voor staan in Europa.

[MrFax]

Ja maar als B nu het internet is? Die kan je niet vertrouwen. De connectie is end-to-end encrypted, maar de data zelf blijkbaar niet. SSL is in feite toch al end-to-end encryptie? Ik snap het artikel dan ook niet echt. Er staat een beveiligde verbinding. Maar het gaat hier dus of C wel te vertrouwen is? Dan maakt het toch niet uit of er end-to-end encryptie is, als je je afvraagt welke end wel te vertrouwen is?

[Reactie gewijzigd door MrFax op 23 juli 2024 00:34]

[Armin]

B is niet het internet. Data is encrypted over het netwerk. Dus enkel zender en ontvanger kunnen de onversleutelde data zien. De kritiek was dat als een ontvanger enkel een doorschakelpunt is, je die niet kunt vertrouwen en dus end-to-end encryptie moet hebben. Ik leg uit waarom ik dat een overbodige stap vindt.

[Stoelpoot]

SSL is E2EE, als E en E de verzender en ontvanger zijn. In dit geval is het dus A -> B (internet) -> C (LSP) -> B (terug over de internet) -> D.

A en D zijn hierin Nederlandse zorgproviders en de E en E om eventueel tussen te encrypten.

[FreezeXJ]

Berichten worden al gesigned (door de UZI-pas, die z'n eigen interne logica met private key daarvoor heeft) dus volgens mij moet het goed te doen zijn om daar een mooi public-key-pair mee te maken.

[squaddie]

Het gaat niet om dat wij nu hier de oplossing gaan bedenken, maar om het feit dat praktisch de meest privacy gevoelige informatie die er bestaat met een vorm van encryptie wordt verzonden via een beveiligd netwerk en wie garandeert dat dit netwerk nooit gekraakt wordt of dat een kwaadwillende beheerder van het LSP een datatap heeft lopen?

Bij dergelijke informatie moet meerdere lagen beveiliging de norm zijn, daarbij denk ik aan perfect forward secrecy, end-to-end encryptie zodanig dat alleen de verzender en ontvanger het kunnen ontsleutelen, het LSP kan de inhoud dus niet ontsleutelen en een beveiligd netwerk. Zodat als er een beveiligingslaag wordt gekraakt dat niet meteen privacy gevoelige informatie op straat ligt, maar er meerdere lagen te kraken zijn om de informatie in handen te krijgen.

Dat als iemand de vraagt stelt over de NEN-normering dat je oprecht kan zeggen dat deze norm niet goed genoeg is bevonden voor uitwisseling van dergelijke privacy gevoelige informatie en dat je in contact ben om het nieuw ontwikkelde niveau van beveiliging te laten certificeren. In plaats van de norm te gebruiken als excuus.

[martijnvanegdom]

Er daar hebben we al jaren RSA voor.. In combinatie met AES en certificaten, moet het prima mogelijk zijn om tussen zorg instellingen end-to-encryptie toepassen..

[DCK]

Je kunt niet zomaar met cryptografische termen strooien en zeggen 'dat moet vast lukken'. Je kunt niet willekeurig cryptografische constructies aan elkaar plakken en er vanuit gaan dat veilig is.

De reden dat je end-to-end encryptie bijna alleen ziet in real-time chatberichten is omdat je te maken hebt met vaste groepen die sleutels uitwisselen en zeer regelmatig online zijn. Dan is de sleuteluitwisselingsproblematiek op te lossen.

In dit geval is het voor mij niet duidelijk dat je 1) te maken hebt met voorgedefinieerde partijen of 2) deze partijen actief mee kunnen doen in de sleuteluitwisseling. Dan heeft strooien met termen als "end-to-end-encryptie", RSA en AES geen zin, als je niet ook kan vertellen hoe je ze aan elkaar moet plakken en alle betrokken partijen veilig van sleutels voorziet.

[Reactie gewijzigd door DCK op 23 juli 2024 00:34]

[R4gnax]

Iedere organisatie moet een eigen certificaat in beheer hebben welke uiteindelijk aan een root certificaat hangt wat door een trusted root certificate authority beheert wordt. Deze worden met regelmaat onderworpen aan audits om te zorgen dat er niet mee geklooid wordt.

Daarnaast zou bijv. de Nederlandse staat zelf als root certificate authority kunnen dienen.


Als organisatie A gegevens met organisatie B wil dienen, dan moet er een sleutel afgesproken worden. Communicatie voor deze key-exchange gaat over een verbinding die in principe niet te vertrouwen is - met het LSP als middle-man.

Dat is niet veel anders (eigenlijk helemaal niet anders) dan een key-exchange voor een TLS-versleutelde verbinding. Dezelfde algoritmes die daar gebruikt worden, kunnen dus ook gebruikt worden om hier de payload aan medische data te versleutelen.

Daarna is het enkel een kwestie van unencrypted de benodigde gegevens naast die payload toevoegen die het Schakel Punt moet kunnen zien om haar werk te doen.

Die complete payload gaat daarna van het bronsysteem naar het LSP en het LSP door naar het doelsysteem via een standaard TLS-versleutelde verbinding. Het LSP kan daarbij enkel de buitenste laag ontsleutelen, waar enkel de gegevens in zitten die zij nodig hebben om het verkeer te routeren.

Zowel A als B kunnen het certificaat controleren (middels de trusted root authority) op de initiële key-exchange. Hiermee is niet alleen de binnenste laag encrypted data beschermd op zo'n manier dat enkel deze twee partijen deze kunnen inzien, maar is ook de authenticiteit van de verzender en ontvanger controleerbaar.

[Reactie gewijzigd door R4gnax op 23 juli 2024 00:34]

[DCK]

Dat is leuk en aardig, maar werkt alleen als je een bericht moet versleutelen en bij voorbaat al weet wie de lezer is van dat bericht. Het is mij niet duidelijk of dat bij dit systeem geldt.

[Armin]

Sterker nog in dit systeem zijn er honderden zo niet duizenden lezers. Immers elke medische instelling die een dossier potentieel moet kunnen inzien, moet toegang hebben. Dus in de praktijk is er niet echt end-to-end want of de lees-sleutel is dan potentieel in handen bij die honderden partijen. Een kwaadwillende kan vast wel ergens een van die partijen hacken.

Het belangrijke punt is dus veel meer audits en goede authenticatie van die honderden partijen.

[pheppy]

De Nederlandse overheid is al root CA: PKI-overheid.

De key exchange hoeft niet zo complex. Als de op vragende partij zijn PKI-certificaat in de aanvraag meestuurt (of een verwijzing naar Netwerk Metadata waar het certificaat in staat) dan kan met de publieke sleutel op dat certificaat gebruikt worden om daarmee de vertrouwelijke gegevens te versleutelen.

Dat gaat trouwens in twee stappen omdat PKI versleuteling niet heel efficiënt is bij het versleutelen van data. De verzender kiest een willekeurige eenmalige lange symmetrische sleutel en versleutelt daarmee de data. En vervolgens wordt deze symmetrische sleutel zelf versleuteld met de (asymmetrische) publieke sleutel op het certificaat van de opvragende partij. Dit is standaard XML versleuteling. Dat hoef je zelf niet te bouwen.

Dit is vrij standard en zeker Good-Practice als gegevens via een derde partij lopen. Ook als dat een betrouwbare partij is. Security- en Privacy-by-Design, niet -by-Trust. Wat je niet nodig hebt moet je niet (onversleuteld) ontvangen, dat kan je het ook niet verliezen. Dat geldt zeker voor een een Hotspot. En het geldt zeker nu er State-Supported-Actors er op uit zijn om democratieën te ontwrichten en Georganiseerde Misdaad zich met cybercrime bezig zijn gaan houden.

Ik hoop maar dat het LSP geen man-in-the-middle is, maar slechts een verwijsindex. Het LSP mag in elk geval wel iets meer transparant zijn over hun ontwerp. Ik kan het in elk geval niet heel vlot vinden.

[Sando]

Zij zegt 'geluiden' te hebben gehoord dat de Amerikaanse beheerder van het LSP - CSC - tussen de connectie van zorgverleners zou kunnen zitten. Daarnaast is het Kamerlid van mening dat de datawisseling tussen medische instellingen versleuteld zou moeten zijn, van begin tot eind. "Dat is een logische eis."

Je kunt niet zomaar met cryptografische termen strooien en zeggen 'dat moet vast lukken'.

De reden dat je end-to-end encryptie bijna alleen ziet in real-time chatberichten is omdat je te maken hebt met vaste groepen die sleutels uitwisselen en zeer regelmatig online zijn. Dan is de sleuteluitwisselingsproblematiek op te lossen.

Als ik het goed begrijp zijn er zorgen dat er tussen partij A en partij C een partij B kan zitten die de gegevens niet moet kunnen inzien. Dan kan partij A toch gewoon aan partij C om de public key vragen, een bericht met deze key encoderen, en vervolgens naar C sturen?

Je bedoelt met real-time chatberichten waarschijnlijk messengers die van het Signal protocol gebruik maken, zoals WhatsApp. Wanneer ik iemand tegenkom en zijn/haar nummer toevoeg, dan kan ik deze persoon direct berichten sturen. Als je in de instellingen key-notificaties aan hebt staan, dan zie je namelijk dat je direct de public key van deze persoon ontvangt.

Waarom zou dat met het versturen van medische data niet kunnen? Je geeft aan te veronderstellen dat relevante partijen in tegenstelling tot messengers niet regelmatig online zijn. Die aanname lijkt me niet juist, anders kan je immers bij elkaar geen gegevens opvragen. Maar ook al is deze aanname wel juist, dan kan je gewoon afspreken dat er een key server wordt opgezet. Dit gebeurt inderdaad al jaren lang. Bekendste voorbeeld is email met PGP. Zie bijvoorbeeld pgp.mit.edu. Ik neem aan dat @martijnvanegdom met RSA doelt op X.509.

Ik bedoel, ik kan de complexiteit van het schakelpunt onderschatten, maar geef dan aan waarom dit in dit specifieke geval niet kan werken. Het werkt voor email, ssh, chat en bitcoin transacties.

[Reactie gewijzigd door Sando op 23 juli 2024 00:34]

[CH4OS]

Dit krijg je er nu van als je incompetente overheids-beleidsmakers zonder kennis van zaken de regels laat verzinnen voor dit soort zeer privacygevoelige zaken.

Je beticht een ander van incompetentie, terwijl jij zelf ook duidelijk laat zien niet te weten hoe het systeem werkt en ook niet weet waarvoor E2EE bedoeld is.

Bij het LSP kan alleen bevraagd worden welke partij ergens mee bezig is geweest. Basicly moet partij A naar partij Lsp, om te vernemen welke partij C is. C heeft alle informatie wel, waar de informatie versleuteld wordt opgeslagen en verzonden naar A.

E2EE is vooral een leuke (en momenteel hippe) term, maar dat gaat voor dit soort zaken ook niet werken. Voor diensten als Whatsapp is E2EE perfect, maar voor dit soort diensten totaal niet; dan moet voor elk verzoek (elke keer dus) sleutels aangemaakt worden voor 1 reactie... Ik hoop dat je snapt dat dat gewoon niet handig is.

Bij diensten als Whatsapp kan dat wel, omdat je dan 1 sleutel hebt voor alle conversaties van 1 persoon, maar dat wil je dan weer niet voor berichten die zo privacy gevoelig zijn (zoals deze); met 1 sleutel kun je dan immers ook bij alle berichten van alle patiënten, wat je imo ook niet moet willen en lost E2EE dus verder weinig op.

PvdD is naar mijn mening duidelijk op zoek naar stemmers hiermee want verkiezingstijd komt er aan.

[Reactie gewijzigd door CH4OS op 23 juli 2024 00:34]

[The Zep Man]

E2EE is vooral een leuke (en momenteel hippe) term, maar dat gaat voor dit soort zaken ook niet werken. Voor diensten als Whatsapp is E2EE perfect, maar voor dit soort diensten totaal niet; dan moet voor elk verzoek (elke keer dus) sleutels aangemaakt worden voor 1 reactie... Ik hoop dat je snapt dat dat gewoon niet handig is.

Geef de patiënt een smartcard (bijvoorbeeld een identiteitsbewijs), en alleen met die smartcard in combinatie met die van een medisch personeelslid kan een dossier opgehaald worden/één enkele partij (tijdelijk) gemachtigd worden om die gegevens op te halen en in te zien.

En er zijn zat andere manieren om het op te lossen. Het probleem is alleen dat de maatschappij en de overheid zich hier niet verantwoordelijk voor voelen. Als die zich niet verantwoordelijk voelen, waarom zouden private instanties dat dan wel zijn?

[CH4OS]

Oh, ik wil ook zeker niet zeggen dat er geen alternatieven zijn, begrijp mij niet verkeerd.
Maar E2EE is in elk geval geen goed middel.

Ook zie je dat artsen veel in overleg zijn zonder de patient, dus je zult ook iets moeten hebben waardoor de artsen het dossier kunnen openen zonder dat de patient ergens een smartcard oid dient te trekken. Dus hoewel jouw alternatief zeker sterk is, dekt het weer niet alle cases, helaas.

Aan de andere kant, weet de patiënt dan natuurlijk wel weer wanneer men bezig is met dienst dossier, dus dat zou ergens ook wel fijn kunnen zijn.

[Mellow Jack]

Volgens mij praat je over 2 uitdagingen waarbij e2ee een oplossing kan zijn dat we de tussen partij niet vertrouwen is het geen oplossing voor het niet vertrouwen van de afnemers, laat staan de "contributors".

Het is en blijft zoeken naar de juiste combinaties

[R4gnax]

[...]
Je beticht een ander van incompetentie, terwijl jij zelf ook duidelijk laat zien niet te weten hoe het systeem werkt en ook niet weet waarvoor E2EE bedoeld is.

Bij het LSP kan alleen bevraagd worden welke partij ergens mee bezig is geweest. Basicly moet partij A naar partij Lsp, om te vernemen welke partij C is. C heeft alle informatie wel, waar de informatie versleuteld wordt opgeslagen en verzonden naar A.

E2EE is vooral een leuke (en momenteel hippe) term, maar dat gaat voor dit soort zaken ook niet werken. Voor diensten als Whatsapp is E2EE perfect, maar voor dit soort diensten totaal niet; dan moet voor elk verzoek (elke keer dus) sleutels aangemaakt worden voor 1 reactie... Ik hoop dat je snapt dat dat gewoon niet handig is.

Bij diensten als Whatsapp kan dat wel, omdat je dan 1 sleutel hebt voor alle conversaties van 1 persoon, maar dat wil je dan weer niet voor berichten die zo privacy gevoelig zijn (zoals deze); met 1 sleutel kun je dan immers ook bij alle berichten van alle patiënten, wat je imo ook niet moet willen en lost E2EE dus verder weinig op.

Alle HTTPS websites op het internet zijn met het oogpunt op apparatuur die in routering voorziet, E2EE.
Geen enkel probleem om daar voor elke verbinding een key-exchange te doen.

Dus waarom zou dat hier ineens een probleem zijn?

[CH4OS]

Omdat ik nu ook niet zou willen dat in het geval iemand zichzelf een weg hacked naar die database in plain text een medisch dossier kan zien?

HTTPS is versleuteling voor transport en daar is het ook zeker prima voor, maar dat is slechts de helft van het verhaal.

[Reactie gewijzigd door CH4OS op 23 juli 2024 00:34]

[R4gnax]

Omdat ik nu ook niet zou willen dat in het geval iemand zichzelf een weg hacked naar die database in plain text mijn medisch dossier kan zien?

HTTPS is versleuteling voor transport, maar dat is slechts de helft van het verhaal.

Nee. Dat is het hele verhaal. Het LSP routeert gegevens tussen partij A en B door identificatie-nummers te koppelen. De daadwerkelijke payload met medische gegevens loopt via hun servers - nu in plaintext omdat zij zelf het eindpunt van de versleutelde verbindingen zijn - maar ze slaan deze niet op.

In plaats hiervan zou het LSP een key-exchange tussen partij A en B moeten faciliteren, waarbij beide partijen een certificaat gebruiken wat gedwongen ondergebracht is bij een te vertrouwen root authority. Bijv. via de root van de Nederlandse staat.

Dan is het mogelijk voor deze partijen om de medische payload apart intern nog eens te versleutelen en signeren op zo'n manier dat enkel partij A en B er toegang toe hebben en niet het LSP; wat enkel de 'buitenste laag' kan inzien waarin enkel de informatie zit die zij nodig heeft om in de routering te voorzien. Daarnaast kunnen partij A en B op dat moment ook elkaars identiteit authenticeren middels signering.


Eigenlij zou dat hele LSP in de basis gewoon benaderd moeten worden als een geval VPN met custom routering.

[Reactie gewijzigd door R4gnax op 23 juli 2024 00:34]

[CH4OS]

Zoals jij het nu schetst, is het LSP eerder een man-in-the-middle, wat beveiligingstechnisch ook niet interessant of verstandig is.

Voor LSP is HTTPS wellicht voldoende, aangezien zij tegen A zeggen wie de ander is, wie zij moeten contacteren en daar houdt het (mag ik hopen althans) op.

[Reactie gewijzigd door CH4OS op 23 juli 2024 00:34]

[R4gnax]

Voor LSP is HTTPS wellicht voldoende, aangezien zij tegen A zeggen wie de ander is wie zij moeten contacteren en daar houdt het (mag ik hopen althans) op.

Zoals de beheerders van het systeem zelf schetsen lopen die gegevens ook gewoon via hun systeem, waarbij alleen de verbindingen -- dus van A naar LSP en van LSP naar B -- versleuteld zijn.

Minister Bruno Bruins schrijft in zijn antwoord:
Indien er relevante gegevens beschikbaar zijn in het brondossier, worden deze over diezelfde gecertificeerde verbindingen in versleutelde vorm verzonden, met het schakelpunt als zwaar beveiligd tussenstation.

Dus ja; het LSP is een plain-text man-in-the-middle van alle medische gegevens die er overheen gaan. Kwestie van wachten op de eerste keer dat er op die systemen binnengedrongen wordt (of door de Amerikaanse staat toegang opgeeist wordt) en alles maandenlang afgetapt wordt.

Iedereen die zo'n opzet sterk genoeg beveiligd vindt, is een godverdomd uilskuiken - met deze minister stipt op plek #1 als hij niet gaat afdwingen dat er iets aan gaat gebeuren.

[Reactie gewijzigd door R4gnax op 23 juli 2024 00:34]

[jpfx]

Jou gegevens staan in principe bij jou arts(en). Als iemand een legitieme aanvraag doet, komen de gegevens bij jou arts(en) vandaan. De zorgverleners zijn via een vertrouwde netwerken met elkaar verbonden. Er gaat niets over het (open) internet. Onderlinge verbindingen tussen de verschillende netwerken zijn via beveiligde verbindingen gemaakt. Als een arts over het (open) internet verbinding maakt met zo'n netwerk (bijvoorbeeld voor een RDP sessie) dan gebeurt dat via een versleutelde VPN verbinding.

[Verwijderd]

Prima toch dat het een keer toch lekt. Als er dan ook gelijk maar de verantwoordelijke ceo en CIO persoonlijk vervolgd worden; dus geen vage afkoopsom door de organisatie. Eventueel aangevuld met beroepsverbod in bepaalde sectoren.

[WoutervOorschot]

End to end encryption kan helemaal niet in deze situatie. Data komt van meerdere instanties en gaat naar meerdere instanties, dan is het per definitie niet e2e (zie telegram online chats vs e2e, alleen tussen 2 devices).

Goede encryptie is nodig, end to end voegt in deze situatie niets toe volgens mij.

[GMJansen]

Hoho, dat is stemmingmakerij.
Er wordt nergens gemeld dat data opgeslagen wordt.
Het LSP wordt alleen als transport gebruikt.

[Verwijderd]

Euhm, dit is toch in tegenspraak met de GDPR/AVG? Subcontractors (CSC) moeten aan dezelfde voorwaarden voldoen als Gegevensverwerker (LSP). De Patriot Act maakt het onmogelijk dat een Amerikaans bedrijf daaraan kan voldoen en volgens mij Safe Harbor al ontoereikend bevonden....

Maar goed, fijn dat een buiten de EU gesitueerde subcontractor van kleine IT projecten door allerhande hoepels moet springen om de data van zijn Europese opdrachtgevers en hun klanten binnen de EU te houden zodat er zo min mogelijk “gedoe” met de GDPR kan ontstaan maar de Nederlandse overheid wel even alle medische gegevens van de Nederlandse burger oncontroleerbaar (ga CSC maar auditen) cadeau doet aan de Amerikanen...

[burne]

Als je gelezen zou hebben zou je geweten hebben dat er geen medische gegevens via het LSP uitgewisseld worden. Dat staat goed leesbaar in de laatste paragraaf.

[jobvr]

Nee, hij wordt er niet opgeslagen maar gaat wel via hun. Zoals ik het nu begrijp werkt dit systeem als een switch en zetten zij de connectie op tussen 2 zorgeverleners. Het enige punt is dat de data vanaf de switch naar de zorgverleners ecrypted is, maar in de switch even unecrypted is, om het daarna weer te encrypten voordat het weer verzonden wordt. Dit betekend dat CSC alle data wel kan inzien.

[burne]

Zoals ik het nu begrijp werkt dit systeem als een switch en zetten zij de connectie op tussen 2 zorgeverleners.

Nadat jij daar schriftelijk toestemming voor gegeven hebt. Geen toestemming: geen toegang.

(Een van de klachten van hulpverleners over het LSP is dat ze in noodgevallen niet bij patiëntendata kunnen omdat die patient eerst toestemming moet geven maar bewusteloos op de eerste hulp ligt.)

[jobvr]

Ja, maar de enige optie die hebt om dat te voorkomen, is om iedereen toestemming te geven om je data te bekijken. Als ik de verschillende reviews lees, werkt het LSP redelijk voor het checken van medicatie geschiedenis, maar (nog) voor geen meter wat betreft behandelingen enzo. Wat zoals aangegeven. het is een schakelpunt. Dus als iemand navraag doet moet hij bij alle aangesloten instanties langs om te kijken of ze informatie over jou hebben.

Ik blijft dit een moeilijk dilemma vinden om verschillende redenen. In de eerste plaats is geen enkel systeem dat op het inter is aangesloten ook maar een beetje veilig. En ook dit systeem werkt via het internet. Er hoeft maar een iemand een foutje te maken en alles ligt op straat en wat op het internet staat, gaat er nooit meer vanaf. Ik was een groter voorstander geweest van het EPD door de overheid. Waarom moet een commerciele partij die werkt in opdracht van voornamelijk zorgverzekeraars de coordinatie krijgen over onze patient gegevens. Om in het gerne te blijven: "Daar krijg ik niet het switserleven gevoel van" Maarja wat is het alternatief. Je gegevens bij de huisarts op een niet gepatchde windows XP computer is ook geen topper. Je ziet nu al dat sommige ziekenhuizen door malware worden plat gelegd https://webwereld.nl/secu...us-legt-ziekenhuizen-plat. Dan vraag ik me af. waarom moeten die op het internet zijn aangesloten. Een dedicated netwerk of aansluiting op het defensie/overheid nafin netwerk had mij een betere optie geleken. Maar daar is meer coordinatie voor nodig.

[Reactie gewijzigd door jobvr op 23 juli 2024 00:34]

[Verwijderd]

En precies dat scenario “wat als je bewusteloos op de eerste hulp ligt en ze kunnen niet bij je medische gegevens” zorgt ervoor dat mensen toestemming geven zonder verder na te denken want “oh god wat als ik daar lig”. Tenzij er sprake is van zaken die ervoor zorgen dat SEH goed mis kan gaan (allergieën bv) is het vrij onzinnig. En voor dat soort noodzakelijke medische informatie kun je je afvragen of je wel afhankelijk wilt zijn van de beschikbaarheid van een of ander IT systeem “ja sorry we waren net platgelegd door ransomware”.

[Epep]

Er staat volgens "opgeslagen." Er gaat wel degelijk medische informatie via het lsp van de ene zorgverlener naar de andere zorgverlener. Waar het LSP heel onduidelijk over is wat er gebeurt met de gegevens als deze daadwerkelijk zijn opgehaald. Deze kan je dan zo vaak en door verschillende personen van die zorgvelener bekeken worden, zonder dan je dit kan volgen. (Volg de zorg, ofo)

[Reactie gewijzigd door Epep op 23 juli 2024 00:34]

[flossed]

Lsp is een hub, issue heb ik destijds bij de dpo van het bedrijf waar ik werkte gemeld. Maar niemand begreep de impact. Technisch beheer van lsp kan in principe data dat op hub uitgewisseld cleartext uitlezen. Dat terwijl vpn tot op dc op privenetwerk aangesloten worden of eigenlijk epd. Is schakelpunt dis vpn tunnelen over vpn werkt ook niet. Tis wel een fysiek gescheiden netwerk. Maar bij nader onderzoek, noemt men de vpn dat

[Reactie gewijzigd door flossed op 23 juli 2024 00:34]

[CH4OS]

Punt is dat LSP geen gegevens verstrekker is in deze en daarbij wat ze niet hebben, kunnen ze niet delen of lekken.
Zij kunnen namelijk alleen aangeven dat voor behandeling X (van persoon Y) partij A contact dient op te nemen met partij B.

[Reactie gewijzigd door CH4OS op 23 juli 2024 00:34]

[Verwijderd]

Waarna partij A en partij B via het LSP de informatie uitwisselen, zonder end-to-end encryptie, zodat in theorie CSC die gegevens zou kunnen afvangen en er vanalles mee kan doen. Terwijl er geen duidelijke bezwaren kleven aan het zorgen voor end-to-end encryptie van de communicatie tussen A en B...

[totaalgeenhard]

End-to-end is SSL dat is niet alleen om tijdens transport te voorkomen dat iemand het kan zien maar ook integriteit van te transporteren content.

Daar boven wil je nog een laag die persoon-2-persoon is, zodat alleen de beoogde (authenticated) aanvrager/behandelaar het kan inzien. En je wilt daar ook een versleutelingslaag in hebben.

[kaas-schaaf]

Het artikel vind ik nogal kort door de bocht. Veel van dit soort systemen zijn complex en is meestal te weinig geld beschikbaar om het goed te implementeren. Zeker end-to-end encryptie met meerdere te koppelen systemen is niet eenvoudig.

"Dat is een logische eis."

Dat hangt volledig af van de rest van de eisen. Hoewel het wel netjes zou zijn (en beter uiteraard), kan het zijn dat de tender waarmee dit gebeurde dit niet voorschreef en daar dus ook geen geld voor is vrij gemaakt. Zo'n systeem is veel complexer (door o.a. de aanmeldingseisen en nodige forward security). Ik ga even er van uit dat dit een zorgvuldig opgezet systeem is en dat daar dus afwegingen zijn gemaakt. Vermoedelijk is alleen de communicatie beveiligd (TLS) en is de rest vrij gelaten gezien de norm.

Zij zegt 'geluiden' te hebben gehoord dat de Amerikaanse beheerder van het LSP - CSC - tussen de connectie van zorgverleners zou kunnen zitten.

Dit klinkt als "hey, is dat niet het moederbedrijf?" en daarna linea recta naar "dus de Amerikanen kunnen er bij". Tenzij hier concreet bewijs voor is, is het klinkklare onzin. Het zou uiteraard wel volledig voorkomen kunnen worden door in de norm end-to-end encryptie op te stellen maar dat is een ander verhaal. De vraag die ze dus stelt is dat CSC zijn reputatie wil verkloten door non relevante informatie, onveilig, op te slaan in het buitenland. Voor nu geeft ik CSC het voordeel van de twijfel aangezien dat nogal een claim is die alleen onderbouwd is met "iets gehoord".

Is het wenselijk om e2e encryptie te doen? Ja. Maar de vraag is wat er allemaal aan het systeem hangt en of dit haalbaar is binnen het budget. Dit zijn niet de simpelste systemen en hangen vol met legacy welke ook ondersteund moet worden.

Note: met end-to-end bedoel ik dus de eindpunten (aanvrager naar provider en terug) zoals in dit artikel en niet zoals gebruikelijk de individuele communicatiekanalen.

[Reactie gewijzigd door kaas-schaaf op 23 juli 2024 00:34]

[flossed]

Beetje simpele opmerking. Berichten verkeer wordt tissen gemeente e2e versleuteld uitgewisseld. Niet moeilijk.

[johnkeates]

"De norm biedt die ruimte". Typisch politiek gelul. Gewoon end-to-end implementeren, anders heeft het geen zin.

[SubSpace]

CSC bestaat overigens niet meer; is overgegaan in DXC Technology na een merger met een deel van HPE.

[SinergyX]

Misschien dat ik het niet snap, maar waarom gehamer op de e2e principes? Natuurlijk, kan niemand 'meelezen', maar wat als ze nu een deel van de beveiligingsfocus op e2e hadden gezet die ten koste komt op de beveiligingen van de systemen zelf? Of de 'versleuteling' van de bestanden zelf die worden verzonden? Klinkt beetje als iedereen verplicht e2e te hebben, maar ondertussen elke idioot dat kantoor kan binnenlopen en vrij zaken kan inzien.

Het is zo sterk als de zwakste schakel, databaseje die uitlekt, login-gegevens op straat, een e2e gaat daar weinig in verbeteren.

Natuurlijk is het een verhaal van en/en/en, maar bij zo'n beetje overheidsdingetje, schiet gigantisch ver over het beoogde budget en moeten er ergens een compromis worden gesloten.

[burne]

Misschien dat ik het niet snap, maar waarom gehamer op de e2e principes?

Omdat Nederland geregeerd wordt door Dunning-Kruger.

[TheDutchChief]

CSC heeft vastgelegd aan de Nederlandse privacy-eisen te moeten voldoen (contract). Bovendien is ze bouwer en beheerder van het systeem, wat niet per definitie ook eigenaarschap oplevert. De patriot-act maakt het nog niet technisch mogelijk dat elke met Word getypte brief door Microsoft aan de NSA gegeven kan worden.