Google introduceert publiekesleutelproject voor verificatie accountgegevens

Google is een opensourceproject begonnen waarmee de relatie tussen een account en een publieke sleutel kan worden geverifieerd. De software is ontwikkeld in samenwerking met Open Whisper Systems, bekend van het Signal-protocol voor end-to-endencryptie.

Key Transparency is volgens Google een transparante directory voor audits van accountgegevens. Deze moet kunnen worden ingezet voor een veelvoud aan beveiligingstoepassingen waarbij encryptie en authenticatie van belang zijn, ook door personen die niet deskundig op dit terrein zijn. Google wijst hierbij naar pgp, dat twintig jaar na de totstandkoming nog steeds moeilijk te gebruiken zou zijn.

Het onderliggende probleem zou liggen bij het vinden van sleutels en dan vooral de verificatie dat de publieke sleutel daadwerkelijk bij de te bereiken persoon hoort. Ook bij chat-apps, het delen van bestanden en het updaten van software speelt dit probleem volgens Google.

Met Key Transparency moeten gebruikers kunnen zien welke publieke sleutels er aan hun account zijn gekoppeld, terwijl de zender moet kunnen zien hoe lang een account bijvoorbeeld al actief is. Ook moet de publieke directory inzage geven in de keren dat accounts bijgewerkt zijn en wie die updates heeft doorgevoerd.

Uiteindelijk streeft Google ernaar dat Key Transparency-directories onderling interoperabel worden en uitgroeien tot een schaalbaar ecosysteem. Google werkt dan ook niet alleen aan het project, maar doet dat samen met onder andere Yahoo, het team achter het Coniks-sleutelbeheersysteem en Open Whisper Systems. Laatstgenoemde is bekend van het Signal-protocol voor end-to-endencryptie, dat in WhatsApp en de Signal-app is geïmplementeerd. Signal laat gebruikers qr-codes gebruiken als ze willen verifiëren dat ze veilig communiceren met de juiste persoon. Ook bij zijn pogingen om dit zo intuïtief mogelijk te maken voor gebruikers, liep Signal tegen problemen aan.

Reacties (26)

[Mr_Light]

Klinkt als https://keybase.io/ maar zie nog niet helemaal hoe dit de wereld gaat veranderen. Immers wil je jouw private key niet delen met google dus het inbouwen van functionaliteit is dan toch nog steeds lastig denk ik.

[kozue]

Het idee achter public-private keypairs is toch juist dat je jouw private key nooit uit handen geeft en iedereen jouw public key mag inzien (ook Google)? Lijkt me sterk dat je jouw private key zou moeten uploaden, dan zou niemand het gebruiken. Maar hoe dit nou verschilt met al bestaande keyservers (zoals gebruikt in pgp) is me verder niet duidelijk uit het artikel, want keyservers zijn geen nieuw concept.

[Mr_Light]

je hoeft je private key voor dit niet te uploaden om in het register te komen, alleen je public key. (net zo als bij keybase.io overigens) Alleen keybase levert dan allerlei apps om dingen makkelijk lokaal te encrypten. Het probleem hiermee is dat je je private key dan dus lokaal op de computer die je gebruikt moet hebben en mensen nog wel eens die vergeten de backuppen. Allemaal voor een tweaker niet zo'n probleem.

De crux zit hem in dat de gemiddelde gebruiker er anders mee omgaat en dat als je het gebruiksvriendelijk het in bv gmail wilt hangen je dan tegen het probleem aanloopt dat je voor het encrypten zo als altijd je private key nodig hebt maar die dan inderdaad niet bij google kwijt wilt en dan zou je iets kunnen doen met een browser plugin of expliciet de javascript code van google moeten vertrouwen. (dat hij het lokaal houd etc.)

Het probleem is ease of use bij pgp, publiekesleuteldiensten lossen een deel van de vergelijking op maar er blijft nog een stuk liggen. (daarom is de populariteit van keybase.io volgens mij ook beperkt) en heeft het gebruik van pgp sinds keybase.io ook niet direct een vlucht genomen en en mis dan ook even wat keytransparancy anders zou doen waardoor dit verhaal veranderd.

[Reactie gewijzigd door Mr_Light op 25 juli 2024 14:52]

[fiftyhillswest]

Het gaat (denk ik) keyservers niet vervangen. Dat is ook niet het doel van dit project of zoiets als Keybase. Het doel van deze projecten is het koppelen van een reeds bestaande, gevestigde identiteit aan het abstracte van een keypair. Bij standaard keypairs is dit onvoldoende te bewijzen zonder fysieke meetings of "key signing parties". Door het te koppelen aan een OpenID/Google account/Twitter/Facebook/Whatever account is er een veel sterkere identiteit gekoppeld dus is communicatie makkelijker.

[CAPSLOCK2000]

Het delen van je private key is niet nodig, in ieder geval niet voor dit project. Als je PGP wil gebruiken vanuit GMail ligt dat misschien anders, maar dit project is heel beperkt in scope.
Dit project doet niet veel meer dan een publiek lijstje maken van welke _publieke_ sleutels er bekend zijn. Bij al die publieke sleutels hoort ook een privé-sleutel maar die blijft geheim.

Het heeft inderdaad wat van Keybase.io maar dan veel beperkter. Het is een soort keybase.io met alleen Google. In weze is het gewoon een PGP key-server voor Gmail gebruikers. Het probleem met die keyservers is dat je ze op zich niet kunt vertrouwen, de keyserver controleert niks, die publiceert alleen wat anderen er in hebben gezet. Het systeem weet niet of emailadres1 en key2 echt bij elkaar horen of niet. Vertrouwen moet je zelf maar regelen buiten het systeem om, bv door elkaar fysieke te ontmoeten en elkaars paspoort te controleren, of zo iets.

Google weet dat wel, voor gmail-gebruikers in ieder geval. Als je Google blind vertrouwt dan is dat mooi en nuttig, maar fundamenteel is dat minder mooi. We zouden onze veiligheid niet in handen moeten geven van een enkel commercieel bedrijf. Alles staat of valt bij de kwaliteit en het vertrouwen dat Google kan leveren. Wat dat betreft is het Web of Trust veel mooier, daarbij ga je alleen één op één relaties aan met mensen die jij persoonlijk vertrouwt.

[SPee]

In principe hoeft het systeem niet te controleren of het emailadres en de key van dezelfde gebruiker zijn. Als je met die public key encrypt, kan enkel degene met de bijbehorende private key het weer ontcijferen. Dus dat betekent dat een ongeauthoriseerde gebruiker het bericht moet bruteforcen om het te kunnen lezen. Veel werk.

Die key verificatie is dus makkelijk te doen:

• De gebruiker registreert zijn Public key
• De server genereert een code, die hij encrypt met de opgegeven public key
• De gebruiker gebruikt zijn private key om de code te krijgen en deze in te voeren (evt met tijdlimiet)
• Het systeem geeft aan dat de sleutel gevalideerd is

[CAPSLOCK2000]

In principe hoeft het systeem niet te controleren of het emailadres en de key van dezelfde gebruiker zijn. Als je met die public key encrypt, kan enkel degene met de bijbehorende private key het weer ontcijferen. Dus dat betekent dat een ongeauthoriseerde gebruiker het bericht moet bruteforcen om het te kunnen lezen. Veel werk.

Ja en nee. In principe heb je gelijk maar dat is niet waar het hier om gaat. Jij gaat er namelijk van uit dat de zender weet wat jouw publieke sleutel is. Als je bericht wordt versleuteld met de juiste sleutel dan is het net erg dat het bericht naar het verkeerde e-mail-adres wordt gestuurd. Als je het bericht versleuteld met de sleutel van het email-adres dan kan de ontvanger het altijd lezen, ook als jij per ongeluk het verkeerde e-mail-adres pakt, want het systeem kiest dan ook automatisch de "verkeerde" sleutel.

Ergens moet je een koppeling maken tussen een persoon en een sleutel.
Wat Google doet is een koppeling maken tussen een e-mail-adres en een sleutel. De aanname is dat e-mail-adres en persoon altijd bij elkaar horen. Google controleert dat door je om een wachtwoord te vragen als je wil inloggen op gmail.com.
De rest van de wereld moet er maar op vertrouwen dat Google dat betrouwbaar doet.

[Verwijderd]

Lijkt me meer een probleem dat op te lossen is met een Blockchain. Daarnaast lijkt het me ook niet fijn dat Google op deze manier metadata heeft van public keys die aan elkaar te relateren zijn. Een social graph zeg maar.

[robvanwijk]

De rest van de wereld moet er maar op vertrouwen dat Google dat betrouwbaar doet.

Voor de volledige-overduidelijkheid: dit is fictief, een gedachte-experiment. Maar het is wel zeer verhelderend en iets om toch maar een keer goed over na te denken: Single Point of Failure: The (Fictional) Day Google Forgot To Check Passwords.

[walteij]

Verwacht google dan dat je je private key bij hun gaat opslaan?
Want als dat zo is, is het al gedoemd om te mislukken.

Als het alleen maar gaat om je public key die je bij google opslaat, zie ik weinig problemen.

Het mooiste zou zijn, als ze een goede methode kunnen ontwikkelen waarbij de persoonsverificatie goed verloopt, zodat de persoon zelf een private/public keypair kan genereren en de public key dus op de google/OWS infrastructuur kan gaan plaatsen.

Op die manier is persoonsverificatie dus geregeld, maar is er ook de infrastructuur om public keys te kunnen checken (in plaats van 500 keyservers en mensen die hun public keys op hun eigen website plaatsen). Public keys moeten nu eindelijk eens via een goed centraal systeem gecontroleerd kunnen worden.

[kozue]

Public keys moeten nu eindelijk eens via een goed centraal systeem gecontroleerd kunnen worden.

Op zich heb je met die zin inderdaad gelijk, het wordt tijd dat public keys eens gebruiksvriendelijk worden gemaakt. Maar niet dat we afhankelijk worden van Google of social media voor het gebruik ervan. Wat dat betreft had ik dit soort initiatieven liever gezien van een onafhankelijke instantie, of een bedrijf dat zich netjes gedraagd op privacygebied (Mozilla?).

[Robbaman]

Gelukkig hebben we zometeen niet langer 500 keyservers.... maar 501

[walteij]

Dat is dus inderdaad het grootste probleem.

Behalve dus als Google samen met Open Whisper Systems ook een goed authenticatie systeem opsteld om te verifieren dat jij ook bent wie je zegt dat je bent.
Dus niet 'zomaar' toestaan om je naam en een public key te uploaden naar die keyserver, maar ook een authenticatie systeem voor de uploader toevoegen.

Dan heeft de keyserver extra toegevoegde waarde, namelijk dat person achter de public key ook daadwerkelijk Robbaman is en niet iemand die doet alsof hij Robbaman is. Dat is namelijk iets dat ik nog steeds mis bij de meeste keyservers.

[3raser]

Het zou wel eens net zoiets als keybase kunnen zijn maar dan alleen met het verschil dat Google de naam en userbase heeft om ook daadwerkelijk een grote speler te worden in het distribueren en verifieren van public keys. Zoals ze zelf al aangeven is het huidige PGP te ingewikkeld voor veel mensen. Als Google het voor elkaar krijgt om hun dienst in veel software in te bouwen dan wordt het gebruik ervan een stuk makkelijker.

[UPPERKEES]

En over 2 jaar trekken ze zeker weer de stekker eruit

[RielN]

Naja, het is een opensourceproject, succes met het verstoppen van de source, ze kunnen zich hoogstens zelf terug trekken...

[RADRIGUZ]

Precies, net zoals ze bij Gmail, android en de andere google producten gedaan hebben..

Hoezo zouden ze er na 2 jaar de dienst stopzetten?

[Ethirty]

Google Code, Picasa, Project Ara, Panoramio, Orkut, Wave, zomaar wat diensten en producten van de laatste jaren die gewoon de nek om zijn gedraaid. Een aantal daarvan waren redelijk veelgebruikt.

De rest: https://en.wikipedia.org/...ued_products_and_services

[MaffeMaarten]

Oja, Google Reader en iGoogle. Die hebben toch erg lang bovenaan mijn lijstje meestbezochte pagina's gestaan, totdat ze er mee ophielden.

Ik gebruik nu voor best wel wat dingen Google Keep, maar dat is er ook zo één waar ik een beetje bang voor om er vol op in te zetten, omdat het zomaar eens zou kunnen ophouden.

[Tozz]

Omdat Google wel vaker diensten opdoekt die niet goed lopen. Gmail en Android zijn wel geslaagd. Maar genoeg Google projecten falen en worden dan uiteindelijk opgedoekt.

[Patrick_Wolf]

Omdat ze wel vaker stoppen met producten die toch niet blijken te werken maar wel veel tijd kosten om te onderhouden.

Als het niet rendabel is op een bepaalde manier, dan stoppen ze met tijd erin steken. Lijkt me ook niet meer dan logisch.

[Verwijderd]

Als facebook mee gaat doen is het interessant, anders gaan ze nooit een kritische massa bereiken.

[BertG]

Bedoel je met een "kritische massa" veel kritische mensen of bedoel je de grote groep mensen die facebook gebruiken en die nodig zouden zijn om het tot een succes te maken? Deze laatste groep mensen zijn niet perse allemaal kritisch.

[Reactie gewijzigd door BertG op 25 juli 2024 14:52]

[Verwijderd]

https://en.wikipedia.org/wiki/Critical_mass_(sociodynamics)

[BertG]

[mutley69]

Hoe gaat men vermijden dat het zoals met OpenID misloopt door bugs in de api's? De schaal waarop dan aanvallen kunnen gepleegd worden, vergroten net het risico. Het siert Google dat ze 't willen proberen - maar de risico's zijn groot.
Google zelf heeft er natuurlijk baat bij dat het inloggen veiliger wordt, en er nagetrokken kan worden wie zich aanmeldt ook echt is wie hij beweert te zijn. Tevens schuilt er ook een gevaar in - nl. zo kan men data oogsten. Dus mogelijks zijn de intenties toch weer niet zo zuiver als men zou denken - vergeet niet doel nummer één van elk bedrijf is geld verdienen - en dat maakt dat u altijd een gezond wantrouwen moet koesteren tegen ELK bedrijf - geen enkel bedrijf verdient het dat u een fan van wordt. Zo simpel is't.