![BYOK: Bring Your Own Key in Pachca](https://pachca.com/68889bebf7ad7a37342e11c8_cover byok-p-2000.webp) # BYOK: Bring Your Own Key in Pachca > How encryption with your own key (BYOK) works in the Pachca team chat app. A detailed guide with examples to help your team work effectively Источник: https://pachca.com/en/help-center/administration/byok ## How encryption with your own key (BYOK) works in the Pachca team chat app Pachca combines the convenience of a SaaS platform with full control over your encryption keys. Your company's messages stay confidential, and you can meet strict security requirements. ### Overview Pachca supports the Bring Your Own Key (BYOK) model. Your organization creates and manages its own encryption keys, and Pachca performs cryptographic operations without access to your master keys. This article covers the problems BYOK solves, the envelope encryption architecture, use cases, supported KMS providers and how different types of data are encrypted. ### Why BYOK What it provides How BYOK helps Confidentiality of messages and files Encryption keys stay in the part of the infrastructure your organization controls. Access control An admin can revoke or rotate a key at any time and immediately block decryption of the data. Data sovereignty You can keep keys in a local data center, even if the data itself is hosted elsewhere. Full access transparency Puts "Privacy by Design" into practice: key operations are audited, and you rely less on trusting the provider. ### How it works: envelope encryption architecture Advanced encryption is based on envelope encryption. To encrypt data, Pachca calls your Key Management Service (KMS) to generate a Data Encryption Key (DEK) for a piece of data, along with its encrypted version. Only the encrypted version is stored in the database. When Pachca needs to access encrypted data, it asks the KMS to decrypt the data key using the master key. ### Operation flow ![BYOK operation flow in Pachca](https://pachca.com/688899393085dfa3249f4782_byok-scheme.png) 1. **Sending a message.** The client app sends unencrypted content over SSL to the EKM service inside Pachca's infrastructure. 2. **Generating the DEK.** EKM calls your Key Management Service and requests a DEK and an EDEK based on the provided encryptionContext (chat, organization, time). This connection can run over a VPN tunnel. 3. **Returning the DEK and the encrypted DEK.** The KMS returns the DEK and the EDEK. The event is recorded in the KMS logs, which you can access. 4. **Encrypting the message.** EKM immediately encrypts the content with the DEK. The plaintext is no longer stored. 5. **Saving to the database.** EKM deletes the plaintext DEK from memory and saves the encrypted message and the EDEK to the database. 6. **Audit.** A record of each wrap/decrypt operation is automatically sent to your logging system, providing full traceability. **Important:** The master key never leaves your KMS. Decrypted encryption keys are kept in RAM only and are never written to disk. ### Key hierarchy Level Purpose Typical lifetime Master Key (your key in the KMS) Stored in the KMS and carries the access policy. Used to derive the KEK. Years; rotated rarely. KEK (Key Encryption Key) Derived from the Master Key + Encryption Context. Defines access boundaries (chat, time, organization) Constant for a given context; may be recreated when the policy changes DEK (Data Encryption Key) Encrypts a specific message or file Minutes to hours; destroyed right after encryption ### Use cases 1. **Full access transparency.** KMS and app logs record every decryption operation. This speeds up incident investigations and builds customer trust. 2. **Flexible access control ("Kill Switch").** An admin can instantly disable the KEK and make all or part of the message history unavailable. This is a key part of a Zero Trust strategy and an incident response plan. 3. **Separation of duties (SoD).** The security team manages the keys, the SaaS provider is responsible for the infrastructure and internal IT handles user administration. 4. **Contractual obligations and audits.** Keys stay with your company, so you can clearly demonstrate compliance with NDAs, customer requirements and the terms of regulatory audits. ### Advanced encryption vs. standard encryption Advanced encryption works on top of the standard encryption all Pachca users get. Data state Advanced encryption Standard encryption In transit Data is encrypted with customer-managed keys as early as possible: at the HTTP proxy or an equivalent entry point. All interactions with the Pachca interface and API are encrypted over public networks using standard HTTPS and TLS 1.2+. This keeps traffic between you and Pachca secure in transit. At rest Data in the database stays encrypted. If a third party tries to access the live database, the data is returned as ciphertext. Service data is encrypted at rest in Pachca using AES-256 keys. In use Data stays encrypted even while in use and is decrypted only when there's a specific business need. Every decryption operation is logged and can be reviewed in an external SIEM system. Data is retrieved from storage and processed as plaintext. ### Supported KMS providers (currently) - **[Yandex Key Management Service](https://yandex.cloud/ru/services/kms)** - **[Cloud.ru](https://console.cloud.ru/spa/key-manager/)** - **[HashiCorp Vault](https://www.hashicorp.com/en/products/vault)**. Unlike Yandex KMS, HashiCorp Vault also lets you restrict permissions through the encryption context. You can: - Limit a key to a specific chat or a list of chats. - Set a time window: for example, allow decryption only until a certain date or on a specific day. - Combine conditions (chat + date/period) in policies. - **[Deckhouse Stronghold](https://deckhouse.ru/products/stronghold/)** ### How different data is encrypted **Messages:** A DEK is generated for each message or, when a conversation is active, for a group of messages. **Search index:** The index is also encrypted through the KMS with a single KEK, so global search keeps working. **Files:** Encrypted with the key of the message they belong to. Encryption runs asynchronously right after the file is uploaded to storage. ### Setup guides Detailed guides for setting up BYOK with different KMS providers: - [Set up BYOK with Yandex KMS](https://pachca.com/en/help-center/administration/instrukciya-po-nastroyke-byok-s-yandex-kms) - [Set up BYOK with Cloud.ru KMS](https://pachca.com/en/help-center/administration/instrukciya-po-nastroyke-byok-s-kms-cloud-ru) - [Set up BYOK with HashiCorp Vault](https://pachca.com/en/help-center/administration/instrukciya-po-nastroyke-byok-s-hashicorp-vault) Updated: September 16, 2025