Clientsideversleuteling voor zakelijke Gmail-gebruikers komt naar iOS en Android

Google brengt de clientsideversleuteling van Gmail naar iOS- en Android-apps. Dankzij deze versleuteling worden zowel de body als de bijlagen van e-mails versleuteld voordat ze de servers van Google bereiken. Voorheen was de encryptie enkel beschikbaar via de desktopomgeving.

Voordat de encryptie te gebruiken valt, moeten admins de functie eerst activeren in de Admin Console van Google Workspace. Daarna kunnen de zakelijke eindgebruikers de versleuteling inschakelen door op het slotje te drukken dat volgens Google verschijnt in een nieuw e-mailbericht.

Clientsideversleuteling is sinds begin dit jaar beschikbaar voor Google Workspace- en Google Education-gebruikers, maar dat was enkel via de desktopomgeving. Dankzij deze versleuteling is de inhoud van e-mails niet door derden te onderscheppen, ook door Google niet. Een organisatie kan in sommige gevallen wel de decryptiesleutels achterhalen om berichten te ontsleutelen en dat is soms nodig vanuit compliance-eisen.

Deze versleuteling kan enkel worden gebruikt in het Google Workspace Enterprise Plus-pakket en in de Education Plus- en Education Standard-pakketten. De encryptie is voorlopig niet beschikbaar voor persoonlijke Google-accounts.

Clientsideversleuteling in Gmail-app - Bron: Google

Reacties (38)

[GertMenkel]

Ik zoeken naar wat voor nieuw versleutelingsschema VCZ zou moeten zijn, blijkt het gewoon de Nederlandse afkorting die ze voor Client Side Encryption gebruiken te zijn

Zo te zien gebruiken ze S/MIME met de sleutels op Google's server. Niet heel gek voor een webmailclient, maar toch redelijk nutteloos als je vanaf een Gmaildomein mailt naar een ander Gmaildomein aangezien Google beide sleutels heeft.

[MrMonkE]

Ja, de jip en janneke IT taal die door de parlementaire ICT commissie werdt gepushed. Vakmensen snappen het zelfs niet meer als je alle terminologie gaat vertalen.

[Frame164]

Als er (teveel) Engels wordt gebruikt is het ook niet goed.

[Raventhorn]

En toch kan je ook makkelijk teveel vertalen, zéker als het gaat om (redelijk ingeburgerde) terminologie.
Het is zeer waarschijnlijk dat niemand snapt wat je bedoeld als je het hebt over een VSS (Vaste Staat Schijf) om je data op te slaan, in plaats van een SSD. Wat in dit geval ook nog eens heerlijk verwarrend kan werken, gezien de overlap met de Volume Shadow Copy Service die VSS als afkorting gebruikt...

Gelukkig zijn daar ook prima oplossingen voor te verzinnen. Laat terminologie vooral voor wat het is, maar biedt er eventueel een kort stukje uitleg bij. Of vertaal het, en benoem daarnaast de vakterm.
Dan heb je beiden; je voldoet aan de Jip-en-Janneke-taal die gepushed wordt, maar je houdt het ook begrijpelijk voor de vakmensen. En als bijkomend voordeel houdt je dat mensen die wat meer willen weten van of doorlezen over onderwerpen in ieder geval weten waar ze naar moeten zoeken...

[moonlander]

Wat gebeurt er dan als je mail verstuurd naar een hotmail account?

[Zer0]

Dan kan de ontvanger de email niet lezen, tenzij je eerst de sleutel uitwisselt, en hun client het ondersteunt.
E-mails met VCZ naar een extern domein sturen
Voordat je e-mails met VCZ naar een ontvanger buiten je domein kunt sturen, moet je eerst digitale handtekeningen uitwisselen met de ontvanger.
https://support.google.co...id=1576252804546492991-NA

[com2,1ghz]

Stuur je de key mee als bijlage. Oh wacht

[Skit3000]

"De deur zit op slot maar de sleutel ligt onder de mat."

Wat jij zegt is trouwens niet hoe assymmetrische encryptie werkt. Je codeert daarbij een bericht met de public key van de ontvanger, dus je hoeft hooguit je eigen public key mee te sturen zodat ze weer versleuteld kunnen antwoorden.

Het enige lastige hiervan is dat je nooit 100% zeker weet of de publieke sleutel die je ontvangt daadwerkelijk van de persoon is waarvan je denkt, behalve als je 'm in persoon uitwisselt.

[the_stickie]

De encryptie/ondertekening gebeurt juist met de private key? Aan de hand van je public key kan je ontvanger decrypten en de handtekening controleren, maar niet zelf dergelijke berichten maken (want daar heb je de private key voor nodig).

[mjz2cool]

Als versleutelen met de private key zou moeten gebeuren, hoe zorg je dan dat alleen de juiste persoon het weer kan ontsleutelen? De public key is zoals de naam al zegt publiek, die is niet geheim. Dan zou iedereen het kunnen ontsleutelen.
Nee de public key van de ander wordt voor versleutelen gebruikt, die hoort bij de private key van diegene. Alleen die private key kan het weer ontsleutelen.

[jurroen]

Dat PKI. Je versleuteld het met de publieke key van de ontvanger, welke het weer kan ontsleutelen met zijn private key. Zie voor een uitgebreidere uitleg bijvoorbeeld dit stuk van Varonis.

[eamelink]

Ondertekenen doe je met je private key, dus dat kan alleen jij.
Iedereen kan aan de hand van jouw public key controleren dat jij ondertekend hebt.

Versleutelen doe je met de public key van de ontvanger. Alleen de ontvanger kan het bericht met zijn private key ontsleutelen.

[lenwar]

Publiekesleutelversleuteling is gebaseerd op twee sleutels. Een privé. Een publiek. Ze zijn een op een met elkaar verbonden. Dat concept is essentieel. Een op een. Wat door de ene versleuteld wordt wordt alleen met de andere ontsleutelt. Dat werkt twee kanten op.

Met dit soort systemen (wat Google gebruikt) werkt men met certificaten. Zo’n certificaat is uit meerdere landen opgebouwd. Een essentieel onderdeel daarvan is een hash van het hele bericht dat versleutelt is door de privé sleutel van de verzender.

Die wordt meegestuurd met het versleutelde bericht, welke wordt versleuteld door de publieke sleutel van de ontvanger.

Alleen de ontvanger kan het hele bericht ontsleutelen met zijn privé sleutel. Vervolgens ontsleutelt de ontvanger de versleutelde hash van het bericht met de publieke sleutel van de verzender en voert daarna deze zelf hash uit.

Als die hashes overeen komen weet de ontvanger dat het bericht van de eigenaar van de bij hem bekende publieke sleutel af komt.


Bovenstaande is de versimpelde versie. In de partij wordt er ook nog extra ‘willekeurige’ data toegevoegd om de hash minder voorspelbaar te maken.

[Skit3000]

In dit geval is Google inderdaad de CA (Certificaat Autoriteit) en kun je er van uit gaan dan emailadressen die door hen worden gehost authentieke zijn en behoren bij de natuurlijke persoon die je verwacht. Wil je echter een versleutelde bericht sturen naar iemand buiten Google, dan weet je natuurlijk nooit of [e-mail] echt van onze koning is of niet, ongeacht of je de public key behorende bij dat mailadres kent.

[lenwar]

Klopt, maar daar is die publieke sleutel ook niet voor. De publieke sleutel zorgt er alleen voor dat berichten die bestemd zijn voor de eigenaar van de publieke sleutel alleen door die persoon gelezen kunnen worden.

Het versleutelen van de hash met je privesleutel toont aan dat ‘jij’ het bericht hebt verstuurd.

Niemand anders dan jij kan versturen namens [e-mail] met die privesleutel. Daar is tenslotte die CA voor. Jij kan niet versleutelen met de sleutel van [e-mail]


In het kort: de publieke sleutel van de ontvanger zorgt ervoor dat alleen de ontvanger het kan lezen. De privesleutel toont aan dat de verzender de verzender is.

[kodak]

Hopelijk geeft de client dan een waarschuwing of je dat wel wil versturen. En anders krijg je waarschijnlijk een bericht van de ontvanger met de opmerking dat het niet te lezen is.

Het is ontworpen om open gebruikt te kunnen worden, dus ook door clients die niet van Google zijn. Maar open zijn is niet genoeg om het te kunnen gebruiken. Die andere clients moeten het dan wel ondersteunen. Anders ontvang je een mail waarvan je de body niet kan lezen. En andersom net zo. Een client die geen ondersteuning geeft kun je dus ook niet gebruiken om de berichten naar dit soort Gmail-gebruikers met deze clientside versleuteling te versleutelen.

[Sando]

Alleen voor betalende gebruikers. Met dit bericht wordt het eens te meer duidelijk dat Gmail al 19 jaar geen versleuteling of PGP wil ondersteunen omdat jij het product bent. Daarom zijn versleuteling-plugins als Mailvelope en Flowcrypt zo populair. Overigens wordt OpenPGP.js, gebruikt door Flowcrypt, Mailvelope, ProtonMail en anderen, gesponsord door de Europese Unie.

[jurroen]

Ik ben zelf groot voorstander van PGP. Maar helaas is het behoorlijk hard gefaald - het heeft vrijwel geen adoptie (behalve door een kleine groep techies), fatsoenlijke key management is veel te lastig, etc.

Ik hoop dat hier nog verandering in komt, maar dat is waarschijnlijk positieve naïviteit. Waarom zou het - als applicaties als Signal E2EE zo makkelijk maken?

[readefries]

Ik kom naast mezelf weinig mensen tegen die het gebruiken. Ik gebruik het weleens als ik veilig als ik data veilig moet delen, al kost het wat moeite uit te leggen hoe het te gebruiken.

[Sando]

fatsoenlijke key management is veel te lastig, etc.

Ze hebben het bij Mailfence, Posteo, ProtonMail etc eigenlijk alles wat OpenPGP.js gebruikt wel erg makkelijk gemaakt. Net zo makkelijk als bij Signal. Het probleem is dat de massa niet meer gewend is om voor dienstverlening te betalen, en dan komt de winst uit datamining en emailscanning waardoor E2E versleuteling niet compatibel is met het verdienmodel.

[Frame164]

Weer die kromme conclusie dat "wij" het product zouden zijn. Advertentieruimte verkopen is het product van Google. En de prijzen daarvan worden bepaald door de profielen die van ons gedrag worden gemaakt. Google verkoopt niet de gegeven van Redsandro maar een profiel waar jij in past. De adverteerder weet helemaal niet wie Redsandro is en dat hij een advertentie krijgt te zien.

[Sando]

Dat komt omdat Google zo groot is dat het (tot nu toe) intern kan blijven. Maar dat ze de mededingingsregels overtreden en onderzocht worden door zowel de EU, US als AU om mogelijk gedwongen opgesplitst te worden is een andere discussie.

Advertentieruimte verkopen is één van de 'producten', maar het wereldwijd dominante dataverzamelen en de bijbehorende aantrekkelijke clickthrough rate is natuurlijk het nectar waarmee ze de kopers van advertenties lokken. Een beetje als klanten naar het bordeel lokken. De werknemers worden in principe ook niet verkocht.

[The Zep Man]

De volledige productnaam is Google Workspace Client-side encryption (CSE) for Gmail. Onderwater is het S/MIME.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 07:17]

[klaaskeesrand]

Ik lees: "Een organisatie kan in sommige gevallen wel de decryptiesleutels achterhalen om berichten te ontsleutelen en dat is soms nodig vanuit compliance-eisen."

Encryptie met een backdoor dus?

[swhnld]

Zoiets, er zijn beroepen waar wettelijk de verplichting is om alle communicatie te bewaren en te kunnen lezen. Misschien herinner je nog de verwijderde SMS berichten van Mark Rutte om een bekent voorbeeld te noemen waar de communicatie bewaard moet blijven.
Daarnaast is er nog de situatie dat gebruikers soms een foutje maken en hun sleutel kwijtraken, en dan hun mailgeschiedenis kwijt kunnen zijn. Niet handig als dat gebeurt met de CEO met contracten in zijn mailbox.

Dus de beheerder van je mail omgeving heeft dan de mogelijkheid om te zorgen dat de zaak zo ingesteld is dat dit goed gaat.
Echter de communicatienetwerken tussen de mail client kunnen die mails dan niet zomaar lezen. Alleen verzender, ontvanger, en de mailserver van de verzender.

[Zer0]

Niet handig als dat gebeurt met de CEO met contracten in zijn mailbox.

Sowieso niet handig als de CEO contracten alleen in zijn mailbox bewaard. Mail is een communicatie middel, geen documentatie archief. (waar het helaas vaak voor misbruikt wordt)

[Reactie gewijzigd door Zer0 op 23 juli 2024 07:17]

[the_stickie]

Maar email heeft wél juridische waarde.
Die waarde wordt nog sterker als bewezen kan worden dat de mail echt (onvervalst is) is, wat door encryptie en ondertekening zeker zo is.

[Zer0]

Ja en? Er zijn genoeg andere methoden om een contract (juridisch) te borgen.
De mailbox van een CEO is echter over het algemeen persoonlijk, en mag niet zomaar door anderen geopend worden als hij bijvoorbeeld vertrekt.

[the_stickie]

Stuur je me gauw een email waarin je me bevestigd dat je me nog 25000€ moet?

[Frame164]

Dat geldt overigens niet alleen voor de mailbox van de CEO. Onze zakelijke mailboxen mogen ook niet zomaar worden geopend door derden.

[Aikon]

Nee, gewoon de optie om hetgeen wat je encrypt ook weer te decrypten wanneer nodig en/of vereist. Niks bijzonders. Een backdoor is echt fundamenteel anders, want dat is verborgen en/of geeft mensen toegang die je juist buiten wilt houden.

[Verwijderd]

It’s not a bug, it’s feature.

Zoiets?😂

[Martijntjeh]

Hebben we het hier over s/mime of pgp of zo?

[Joseph]

Dankzij deze versleuteling is de inhoud van e-mails niet door derden te onderscheppen, ook door Google niet.

Niet helemaal, want op het moment dat de mail van een derde partij bij Google binnenkomt is deze plain tekst (indien deze niet versleuteld is). In het proces tussen binnenkomst en versleuteling valt dit bericht nog steeds te onderscheppen (dat is ook de achilleshiel bij Proton). Het komt er dus echt op neer of je de partij in kwestie vertrouwt.

Helaas is er nog steeds geen goed self-hosted alternatief voor Protonmail (zeker niet met hetzelfde gebruikersgemak), maar zoiets bouwen is een enorme berg werk. Door de aard van het type versleuteling kan je protocollen als IMAP en JMAP niet (goed) gebruiken. Daarom is hier ook een custom protocol voor ontwikkeld.

Bij uitlevering van mails tussen zakelijke Gmail accounts zou het technisch gezien wel mogelijk moeten zijn, omdat het clientside al direct versleuteld kan worden met de key van de tegenpartij (indien deze database te raadplegen is uiteraard). Dat kan natuurlijk ook met PGP of S/MIME, maar dan ben je er wel van afhankelijk dat de tegenpartij het ook gebruikt. En daar zit nou net het probleem...

[ScuL]

Het zou fraai zijn als ze eerst wat chronische bugs oplossen. Ik heb al bijna een jaar het probleem dat ik mijn vakantie / out of office reply niet kan inschakelen omdat er te veel emails in de inbox staan en Gmail gewoon vastloopt als ik het probeer op te slaan. Verschillende PC's of browsers maken geen verschil en support geeft geen antwoord Hilarisch gezien ik betaal voor Gsuite..

[MrMonkE]

Dit laatste is het grootse probleem met MegaCorp.
Je kunt beter bij een kleinere partij zitten met je email.

[Verwijderd]

PGP was te makkelijk
Compliance....

[intraxi]

Google heeft beide sleutels op de server. Nou das lekker veilig! Gewoon een pdf maken en met key versleutelen en als attachment met gmail versturen. Hoe komt de sleutel bij de ontvanger? Ff bellen of iets gebruiken, waarvan je weet, dat de ontvanger het weet..