> For the complete documentation index, see [llms.txt](https://oten.gitbook.io/kms-support/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://oten.gitbook.io/kms-support/google-cse-integration/google-dek-wrapping.md).

# Google DEK Wrapping

## Overview  

When you create/edit a Google document:

1\. Google generates a unique DEK for that document

2\. Google encrypts the document content using this DEK

3\. Google sends the DEK to **Oten KMS** for protection

4\. **Oten KMS** wraps (encrypts) the DEK using your CMK

5\. Encrypted document + wrapped DEK are stored by Google

## Guideline video 

{% embed url="<https://app.supademo.com/demo/cmhd2xyjg2dcpfati415mmwv7?utm_source=link>" %}

## System Integration&#x20;

### Sequence Diagram

<figure><img src="/files/S0Q7WDpLQLpxBN94N0mI" alt=""><figcaption></figcaption></figure>

### Step-by-Step Description

**Step 1:**

* &#x20;User initiates the process by creating a new document within Google Workspace (e.g., a new Google Doc).
* Google Workspace generates a unique, one-time-use **Data Encryption Key (DEK)**. This DEK will be used to encrypt the user's document content.

**Step 2:** Google Workspace sends a request to the **Key Management Service (Oten KMS)** to "wrap" (encrypt) the newly generated DEK. This request includes two critical pieces of information:

* The plaintext DEK.
* An authentication token (a JWT) issued by the Oten Identity Provider (IdP).

**Step 3:** Before performing any cryptographic operations, the **Oten KMS** must validate the request. It sends the JWT token to the **Oten IdP** for verification. The IdP decodes the token to confirm its authenticity and integrity.

**Step 4:** The Oten IdP returns the user's context claims extracted from the valid JWT. These claims (e.g., `org_id`, `workspace_id`, `group_id`, `user_id`) are essential for making an access control decision.

**Step 5:** The **Oten KMS** now queries the **Policy Store** to check if the user (with the provided context) has the necessary permissions to use the **Oten KMS** and, by extension, encrypt a document in this context.

**Step 6:** The Policy Store responds with a grant or deny decision. The process only continues if permission is **granted**.

**Step 7:** Since permission is granted, the **Oten KMS** uses the context from the IdP (e.g., `org_id`, `user_id`) to select the appropriate **Customer Master Key (CMK)** to use for wrapping. The policy determines which CMK is linked to that specific organizational context or user.

**Step 8:** The **Oten KMS** performs the core cryptographic operation: it **wraps** (encrypts) the user's plaintext DEK using the selected CMK.

**Step 9:** The **Oten KMS** returns two items to Google Workspace:

* The **`wrapped_DEK`**: The encrypted version of the DEK.
* The **`KeyID`**: An identifier for the CMK that was used to perform the wrapping.

Google Workspace then stores the `wrapped_DEK` and `KeyID` alongside the encrypted document data. The plaintext DEK is discarded from memory, and the document is now securely protected. To decrypt the file later, Google would send the `wrapped_DEK` and `KeyID` back to the **Oten KMS** with a valid authentication token to "unwrap" (decrypt) it

To unwrap DEK, refer to&#x20;

{% content-ref url="/pages/Wouy2GavUuh80OAMT4DQ" %}
[Google DEK Unwrapping](/kms-support/google-cse-integration/google-dek-unwrapping.md)
{% endcontent-ref %}

<br>