Platform Identity Management Nederland (PIMN)

PIMN voor beter identity management

Wie is verantwoordelijk voor de bestrijding van identiteitsdiefstal?

De eigenaar van de identiteit is dat uiteraard altijd, en de dieven hebben ook zo'n natuurlijke rol.
Op het Internet spelen daar ook nog anderen mee, die in sociale netwerken als overheden of autoriteiten opereren.
Opvallend daarbij is dat die ook weer hun eigen autoriteit nodig hebben om diefstal van hun eigen identiteit te voorkomen.
In de huidige infrastructuur komen ze daarbij uiteindelijk terecht bij een certificate authority, die zelf geen overheid of autoriteit meer heeft: een soort independent credentials (rating) agency.

De oorzaak daarvan is een tunnelvisie die technisch eenvoudig te bestrijden is, maar sociaal krachtig in stand wordt gehouden.
Met trieste consequenties voor de mensen die er gedwongen gebruik van maken.


We kijken eerst naar de techniek, en vergelijken daarvoor de volgende werkwijzen:
1: public key identificatie plus password identificatie (DigiD architectuur)
2: lidokey identificatie (zie http://www.jan-hein.info/lkmap.html).

Werkwijze 1: public key identificatie plus password identificatie.

Stap 1: server identificeert zich met een public key en authenticeert die door te bewijzen dat het over de bijbehorende private key beschikt.
Stap 2: client identificeert zich met een user-id en authenticeert die met een password.

Het eerste risico is dat de client niet de correcte public key ziet.
Het tweede risico is dat de private key gedupliceerd is en dus geen unieke eigenaar meer heeft.
Ten slotte bestaat het risico is dat het password gedupliceerd is en dus geen unieke eigenaar meer heeft.

Het gevolg van beide public key risico's incidenten is dat de relaties van de server met alle clients onbetrouwbaar worden.
Het gevolg van het password risico incident is dat de relatie van de server met de client onbetrouwbaar wordt.

Een integriteitsincident van een relatie wordt gedetecteerd zodra iemand merkt dat er iets niet klopt in de sociale interactie.
Dus buiten de technische infrastructuur om.

Voor het herstellen van de integriteit van de server relaties moet de server een ander paar (public key, private key) gaan gebruiken.
Voor het herstellen van de integriteit van de client relatie moet de client een ander password gaan gebruiken.

Vooral de situatie dat de client een verkeerde public key ziet, en het onopgemerkt delen van een password komen veel voor.
Dit wordt soms pas laat opgemerkt, en is moeilijk te voorkomen.
De situatie waarin de private key onopgemerkt is gedupliceerd lijkt nog niet veel voor te komen.


Werkwijze 2: lidokey identificatie

Stap 1: client identificeert zich met een uniek netwerk node nummer en authenticeert die met twee one time passwords.
Stap 2: server identiceert zich met een uniek netwerk node nummer en authenticeert die met een van die one time passwords.
Tijdens deze interactie tussen client en server veranderen de twee passwords tegelijkertijd bij client en server en de interactie wordt vertrouwelijk gehouden door een van de twee passwords als sleutel te gebruiken voor sterke symmetrische encryptie van de berichten.

Het risico is dat het gedeelde paar passwords bij een derde terecht komt die het vervolgens sneller gebruikt dan de legitieme client.
Dit kan gebeuren als de keyring van de client en de passphrase waarmee die versleuteld is onopgemerkt worden gedupliceerd.

Het gevolg van een incident is dat de relaties van de client met alle servers daarvan onbetrouwbaar zijn.

Een integriteitsincident van een keyring wordt gedetecteerd zodra de rechtmatige eigenaar probeert in te loggen bij een server die al door een duplicaat werd gebruikt, of andersom.
Daarnaast kan iemand merken dat er iets niet klopt in de sociale interactie.
Dus buiten de technische infrastructuur om, sneller dan het technische detectie proces.

Voor het herstellen van de integriteit van de keyring moet de client alle relaties op de keyring veranderen door ze te gebruiken.
Dat zal mislukken voor de relaties die tijdens de inbreuk door de aanvaller zijn gebruikt.
Deze relaties moeten volledig opnieuw worden gelegd.


Vergelijk de risico's:
In werkwijze 1 moeten de volgende risico's worden beheerst:
- client ziet verkeerde public key
- private key onopgemerkt gedeeld met aanvaller
- password onopgemerkt gedeeld met aanvaller
In werkwijze 2 moet het volgende risico worden beheerst:
- aanvaller deelt onopgemerkt een keyring met client

Het enige gezamenlijke risico is dat vertrouwelijke data zoals een private key of een lidokey keyring onopgemerkt met iemand wordt gedeeld.
Dit risico is het minst manifest in werkwijze 1, en alle aandacht gaat daar uit naar het oplossen van de twee problemen die lidokey fundamenteel niet heeft.

Vergelijk de gevolgen:
In werkwijze 1 kunnen in 1 klap vele server relaties tegelijkertijd worden gecompromitteerd.
In werkwijze 2 blijft de schade fundamenteel beperkt tot de relaties van de individuele client.

Vergelijk de detecties:
In werkwijze 1 kan een identiteit oneindig lang onopgemerkt door verschillende mensen  gelijktijdig worden gebruikt, omdat de detectie technisch afhankelijk is van de terugkoppeling van het sociale netwerk naar de technische infrastructuur.
In werkwijze 2 is de tijdsduur van zo'n situatie fundamenteel beperkt tot het tijdsinterval tussen twee initiatieven om een clint-server relatie na elkaar te gebruiken.
Verder heeft het dezelfde sociale detectie.

Vergelijk de reparatie processen in het netwerk:
In werkwijze 1 is de minst ingrijpende reparatie van de infrastructuur dat een client zijn password bij een server verandert.
Wat de oorzaak van het probleem precies was is niet altijd goed vast te stellen, dus ontwikkelingen van preventie mogelijkheden zijn zeldzaam en gewoonlijk misleid.
In werkwijze 2 is de meest ingrijpende restauratie van de infrastructuur het opnieuw leggen van relaties met enkele servers, wat vergelijkbaar is met het veranderen van passwords.
Als dit nodig is, geeft het informatie over de aanval die de noodzaak veroorzaakte, en aanwijzingen voor beschermende maatregelen.
In werkwijze 1 is de duurste reparatie van de infrastructuur dat een certificate authority als onderdeel wordt geelimineerd.

Werkwijze 1 heeft dus meer risico's, die vaker tot incidenten leiden, die grotere gevolgen kunnen hebben en langer onopgemerkt blijven en moeilijker te verhelpen zijn dan die van werkwijze 2.


Implementatie van werkwijze 2 in werkwijze 1.

De LidoKey kan eenvoudig worden ondergebracht in de huidige infrastructuur.
Het begint als vervanging van de password identificatie, en maakt uiteindelijk zonder technische fricties de public key identificatie irrelevant.

Als vervanger van het password elimineert het de actuele bedreigingen van de client identiteit (phishing, MITM, etc.) en vermindert het bedreigingen van de server identiteit door versnelde detectie aan de client kant.
Zodra alle clients van een server lidokey identificatie gebruiken, kan die server de public key identificatie stoppen, omdat die dan geen toegevoegde waarde meer heeft.


Typisch gebruik.

Een autoriteit geeft aan de personen en organisaties waarmee ze een sociale relatie heeft een child keyring van de eigen Lidokey.
Deze personen en organisaties kunnen nu via de autoriteit als witness relatie onderling rechtstreekse relaties leggen.
De autoriteit kan op beider verzoek de nieuwe partners ook van elkaars credentials voorzien, zoals referentie nummer binnen de autoriteit, naam, etc.
Als de autoriteit ook nog relaties buiten zijn eigen netnetwerk van children nodes heeft, kan ook daarvoor als witness worden opgetreden.

De organisatie die van de autoriteit een eigen LidoKey heeft gekregen kan zelf ook weer als autoriteit optreden binnen het eigen netwerk van child nodes.


Netwerkstructuur.

De structuur van een LidoKey netwerk sluit zo dicht mogelijk aan bij de sociale netwerken die ermee beschermd worden tegen identiteitsdiefstal.
Hierdoor versterken de technische detecties en de terugkoppeling uit het sociale netwerk elkaar maximaal, en kan de afhandeling van incidenten zo eenvoudig mogelijk worden gehouden.

Daarvoor is het belangrijk dat een autoriteit in een LidoKey netwerk een vergelijkbare rol speelt in het bijbehorende sociale netwerk.
De verantwoordelijkheden en bevoegdheden in het sociale netwerk moeten de autoriteit in het LidoKey netwerk legitimeren.

Voorbeelden van logische verhoudingen tussen de netwerken zijn:
(autoriteit, organisatie) - (client, medewerker)
(autoriteit, overheid) - (client, burger of organisatie)
(autoriteit, service provider) - (client, customer)

Een LidoKey netwerk groeit op twee manieren:
- het aantal nodes in het netwerk
- het aantal relaties tussen child nodes

Bij de groei van het aantal nodes ontstaat een boomstructuur in het netwerk van parent-child relaties.
Bij de groei van het aantal relaties wordt die boomstructuur aangevuld met een webstructuur.
De hierarchie in de boomstructuur kan bijvoorbeeld worden afgeleid van de Internet domain name structuur.

Bij de ontwikkeling van de webstructuur kan de eigenaar van de eerste keyring toestaan dat child nodes onafhankelijk van de parent kunnen opereren, en daarmee de verantwoordelijkheid voor het gedrag in zijn netwerk volledig verleggen naar de eigenaar van de identiteit.
Er kan ook voor worden gekozen om dicht bij de boomstructuur te blijven, met de oncontroleerbare root node, maar dat sluit gewoonlijk minder goed aan bij de onderliggende sociale netwerkarchitectuur in Nederland.


Initiatiefnemers.

Welke organisaties zijn in staat om als eersten een LidoKey netwerk te implementeren?

Technisch en financieel kan een organisatie of samenwerking tussen organisaties vanaf een paar honderd duizend clients dat al eenvoudig aan.
Het probleem is dat die gewoonlijk gevangen zitten in de tunnelvisie van public key encryption.
Door de grote financiele- en reputatie belangen bij deze visie is dat lastig te verhelpen.

Welke organisaties hebben daar het minste last van?
Hoe kan ik die bereiken?
Welke andere fora zijn geschikt voor deze vragen?
Alle hulp is welkom.

Bij voorbaat dank,
Jan-Hein van der Burg.
www.Jan-Hein.info

Weergaven: 23

Opmerking

Je moet lid zijn van Platform Identity Management Nederland (PIMN) om reacties te kunnen toevoegen!

Wordt lid van Platform Identity Management Nederland (PIMN)

Doe mee op LinkedIn

Vaker een update en goede mogelijkheid om zichtbaar te zijn.

© 2018   Gemaakt door Jaap Kuipers.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden