> 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-unwrapping.md).

# Google DEK Unwrapping

## Overview 

####  :warning:Checklist Required 

To unwrap a Google DEK using **Oten KMS** (workspace level) in order to view a Google file, the user must:

:white\_check\_mark: Have access to the file (the user is the owner or the file is shared with them)

:white\_check\_mark: Belong to the workspace that contains the wrapping key

:white\_check\_mark: Have permission to use the key for unwrapping within the workspace

:white\_check\_mark: Ensure the wrapping key AND the key version used to wrap the Google DEK are still active.

#### Google DEK unwrapping process

When you open an encrypted Google document:

1\. Google retrieves the encrypted document and wrapped DEK

2\. Google sends the wrapped DEK to **Oten KMS**

3\. **Oten KMS** verifies your authorization and unwraps (decrypts) the DEK

4\. Google uses the unwrapped DEK to decrypt document content

5\. You view the document normally in Google Workspace

## Guideline Video 

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

## System Integration

### Sequence Diagram

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

### Step-by-Step Description

**Step 1:** A user attempts to open an existing encrypted document within Google Workspace.

**Step 2:** Google Workspace sends a request to the **Key Management Service (Oten KMS)** to "unwrap" (decrypt) the DEK. This request includes several critical pieces of information:

* An authentication token (JWT) from the Oten Identity Provider (IdP).
* Google's own authorization credentials.
* The **`wrapped_DEK`** (the encrypted DEK stored with the document).
* The **`KeyID`** (the identifier for the CMK that was originally used to wrap the DEK).

**Step 3:** The **Oten KMS** must first validate the user's right to perform this operation. It sends the JWT token to the **Oten IdP** for verification. The IdP confirms the token's signature and validity.

**Step 4:** The Oten IdP returns the user's context claims (e.g., `org_id`, `workspace_id`, `group_id`, `user_id`) extracted from the valid JWT. This context defines who the user is and what resources they belong to.

**Step 5:** The **Oten KMS** queries the **Policy Store** to check if this specific user has the necessary permissions to access and unwrap the DEK for this document.

**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** performs two internal actions:

* It uses the provided **`KeyID`** to locate the correct **Customer Master Key (CMK)** in its storage.
* It then uses that CMK to **unwrap** (decrypt) the `wrapped_DEK`, recovering the original, plaintext DEK.

**Step 8:** The **Oten KMS** returns the **clear DEK** (the decrypted, plaintext key) to Google Workspace. It is critical that this transmission occurs over a secure, encrypted channel.

**Step 9:** Google Workspace uses the returned clear DEK in memory to decrypt the encrypted content of the user's document.

**Step 10:** Finally, Google Workspace presents the decrypted, human-readable document to the user.

#### Key Security Note:

The clear DEK exists only in memory for the shortest time necessary to decrypt the file content. It is never stored in plaintext by Google Workspace, ensuring that the master key (CMK) in the **Oten KMS** is the only way to persistently access the data.