One Article Review
| Source |  GoogleSec |
|---|---|
| Identifiant | 8350827 |
| Date de publication | 2023-06-29 18:11:49 (vue: 2023-06-30 00:06:18) |
| Titre | Cryptage côté client Gmail: une plongée profonde Gmail client-side encryption: A deep dive |
| Texte | Nicolas Lidzborski, Principal Engineer and Jaishankar Sundararaman, Sr. Director of Engineering, Google WorkspaceIn February, we expanded Google Workspace client-side encryption (CSE) capabilities to include Gmail and Calendar in addition to Drive, Docs, Slides, Sheets, and Meet.CSE in Gmail was designed to provide commercial and public sector organizations an additional layer of confidentiality and data integrity protection beyond the existing encryption offered by default in Workspace. When CSE is enabled, email messages are protected using encryption keys that are fully under the customer\'s control. The data is encrypted on the client device before it\'s sent to Google servers that do not have access to the encryption keys, which means the data is indecipherable to us–we have no technical ability to access it. The entire process happens in the browser on the client device, without the need to install desktop applications or browser extensions, which means that users get the same intuitive productivity and collaboration experiences that they enjoy with Gmail today. Let\'s take a deeper look into how it works.How we built Client-side Encryption for WorkspaceWe invented and designed a new service called, Key Access Control List Service (KACLS), that is used across all essential Workspace applications. Then, we worked directly with customers and partners to make it secure, reliable, and simple to deploy. KACLS performs cryptographic operations with encryption keys after validating end-user authentication and authorization. It runs in a customer\'s controlled environment and provides the key management API called by the CSE- |
| Envoyé | Oui |
| Condensat | at ability able access across actively acts add addition additional additionally advanced advantage after against all already also anyone api application applications applicationworkspace are assertion asymmetric authenticate authenticated authentication authorities authority authorization authorized authorizing available been before being between beyond both broadly browser browsers built business but calendar call called calls can capabilities capability card centrally certificate certificates chain challenges claim client clients closely code collaboration commercial communicate communication composition conference confidentiality configurations connect container containing contains content control controlled controls cover covering create crypto cryptographic cse current custom customer customers data decided decrypt decrypted decryption deep deeper default dek delight deliver delivery deploy deployable designed desktop detailed details develop developed device diagram digital digitally directly director display dive docs domain done drive driven during duty each easily easy email emails enable enabled enables enabling encrypt encrypted encryption encryption/decryption encryption: encrypts end engineer engineering enjoy ensure enterprise entire envelope environment essential every example existing expanded experiences extended extensions extensive facilities february field files finally flows:when follow forcing from fully functionalities further generates generation get getting gmail gmailgoogle google happens hard have having high how however https identifying identities identity idp iframe implementations important important cse include included incoming indecipherable individually insight install instance instead integrated integrity interoperability intuitive invented isolated isolation its jaishankarsundararaman journey json jwt kacls keep kept key keys last latest layer layers let level leverage leveraging lidzborski links list local locked log look mail make management matches means mechanisms meet meeting message messages mime mind more most multiple need new next nicolas not now offered oidc open openid openness operation operations order organizations origin other outgoing outside over paradigm paramount partnering partners perform performs phishing pki policy portal possible postmessage practical presentation principal private process productivity products: progress proprietary protect protected protecting protection protects provide provided provider providers provides providing provision public random read receiving recipient recipients reference regardless reliable render request required research rest returning root rsa run runs s/mime safe safety same scheduled seamlessly sector secure securely security see sender sending sends sensitive sent separation servers service services sheets side sign signature signed similarly simple simplified slides software some standard standards stays strategies strict such supplied support supported take takes tampering teams technical technology them then these those tls today token tokens transit transparently transport trust trusted under underlying us–we use used user users uses using valid validates validating verify virtual web well what when where which whitepaper why will without work worked works workspace workspacein workspacewe would year years |
| Tags | Conference |
| Stories | |
| Notes | ★★★ |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.