Architecting a BYOK (Bring Your Own Key) Encryption Model

Introduction

As organizations move sensitive operations into SaaS platforms, one major concern is encryption control. Enterprises, especially regulated industries like finance, aviation, government, and healthcare, are no longer satisfied with applications simply encrypting data using platform-owned encryption keys.

They want control.

They want governance.

They want the ability to revoke access instantly.

And this is where BYOK (Bring Your Own Key) emerges as an essential encryption pattern. BYOK allows each customer (tenant) to supply their own encryption key. The platform encrypts the tenant’s data using that key, but does not store the key permanently unless explicitly configured. When a tenant rotates or revokes the key, their encrypted data becomes unreadable, enforcing true cryptographic ownership.

This article explains how to design, build, and deploy a complete BYOK encryption model using .NET, SQL Server, and Angular.

Why BYOK Matters

A standard encryption model stores the encryption keys inside the system. BYOK reverses this control role.

With BYOK:

The customer owns the key
The platform uses it only to encrypt/decrypt
The platform cannot access unencrypted data without tenant approval
Revocation instantly makes data inaccessible

This provides strong guarantees around:

Data sovereignty
Compliance (GDPR, HIPAA, PCI-DSS)
Legal control
Forensics and auditability

Requirements for a Secure BYOK Model

A BYOK-enabled platform must support:

Requirement	Description
Secure key import	No plaintext keys should persist unprotected.
Key wrapping	Keys should be encrypted using a system master key or HSM.
Key rotation	Tenant keys can rotate periodically without data loss.
Revocation	Tenant can disable access at any time.
Audit trail	All key usage must be logged.
Multi-encryption domain	Files, structured data, and documents must be encryptable.

High-Level Architecture

 ┌───────────────────────────────────────────────────────┐
 │                     Tenant User                        │
 └───────────────┬───────────────────────────────────────┘
                 │ Upload Key (UI)
                 │
 ┌───────────────▼───────────────────────────────────────┐
 │                  Angular Frontend                      │
 │ (Key Upload, Rotation Request, Revocation Control)     │
 └───────────────┬───────────────────────────────────────┘
                 │ Secure TLS Transfer (Key Never Logs)
                 │
        ┌────────▼────────────────────────┐
        │   .NET Key Management Service   │
        │ (Key Validation, Wrapping, HSM) │
        └───────┬───────────────┬────────┘
                │               │
       ┌────────▼───────┐   ┌──▼─────────────────────┐
       │   HSM / KMS    │   │ Application Encryption │
       │  (AES/RSA)     │   │ Engine (SQL + File)    │
       └───────────────┘   └───────────┬────────────┘
                                       │
                          ┌───────────▼─────────────┐
                          │   Encrypted Data Store  │
                          └─────────────────────────┘

Key Lifecycle Stages

A secure BYOK implementation supports the following lifecycle:

Stage	Description
Import	Tenant submits key securely
Validate	Check format, length, signature
Wrap	Re-encrypt using platform security key or HSM
Use	Encrypt/decrypt tenant data
Rotate	Replace key without breaking existing data
Revoke	System must immediately stop decrypting
Destroy	Delete from storage if necessary

Angular Frontend: Secure Key Upload

The frontend must:

Never store the key locally
Send via HTTPS only
Display rotation and revocation control
Support passphrase-protected key files

Sample upload component

uploadKey(file: File) {
  const formData = new FormData();
  formData.append("keyFile", file);

  return this.http.post("/api/byok/import", formData, {
    headers: {
      "X-Key-Action": "import"
    }
  });
}

The UI must clearly communicate:

Key import success
Current status (active, pending rotation, revoked)
Last usage stamp

Backend (.NET): Key Wrapping and Secure Storage

Keys must never be stored in plaintext.

Use:

AES-256 for symmetric wrap
RSA for tenant-provided key signing validation
HSM where available

Example wrapping logic

public async Task<byte[]> WrapKey(byte[] tenantKey)
{
    using var aes = Aes.Create();
    aes.Key = _systemMasterKey;
    aes.GenerateIV();
    
    using var encryptor = aes.CreateEncryptor();
    var encrypted = encryptor.TransformFinalBlock(tenantKey, 0, tenantKey.Length);

    return Combine(aes.IV, encrypted);
}

SQL table design:

TenantKeys
---------
TenantId
WrappedKey
KeyHash
IsActive
CreatedAt
RotatedAt
RevokedAt

Encryption Path: How Data Gets Encrypted

Workflow

 ┌───────────────┐
 │ Application   │
 │ Request       │
 └───────┬───────┘
         │
 ┌───────▼───────────────────────────────┐
 │ Retrieve Tenant Active Wrapped Key     │
 └───────┬────────────────────────────────┘
         │ Unwrap (AES/RSA/HSM)
 ┌───────▼───────────────┐
 │ Encryption Processor  │
 └───────┬───────────────┘
         │ Encrypt using tenant key
 ┌───────▼───────────┐
 │ Persist in DB     │
 └────────────────────┘

Decoding Path: Enforcing Authorization

Decryption cannot occur unless:

Key exists
Key is active
Revocation state is checked
Authorization rule passes

Example

if (tenantKey.IsRevoked)
    throw new SecurityException("Key revoked. Decryption not allowed.");

Key Rotation Strategy

Two common models:

Model	Behavior
Encrypt new data with new key; old stays encrypted under old key	Faster; common
Re-encrypt entire tenant data during rotation	Strongest model

For enterprise platforms, use Model 1 with background re-encryption scheduler.

Revocation Behavior

When key is revoked:

All decrypt operations fail
Existing encrypted data remains stored securely
Logs must indicate attempted access

This ensures legal compliance in data access disputes.

Auditing and Logging

Audit table includes:

Field	Purpose
KeyId	Which key was used
Action	Encrypt / Decrypt / Rotate / Import
Timestamp	When action occurred
User	Who initiated access
SourceIp	For forensic tracing

Compliance Considerations

A BYOK system supports compliance for:

GDPR (Right to restrict access)
FedRAMP (Key ownership)
ISO 27001 Annex A
HIPAA (Encryption mandates)
PCI-DSS (Cardholder data control)

Testing Strategy

Include:

Key import validation tests
Encryption/decryption round-trip verification
Revocation enforcement tests
Rotation with backward compatibility
Performance benchmarking
Load testing for large tenant base

Summary

A Bring Your Own Key model gives customers true control of their encryption lifecycle. Building this system requires careful design across key management, cryptography, metadata modeling, policy enforcement, auditing, and API workflows. Using Angular for controlled key administration and .NET with secure key wrapping provides a scalable and compliant framework for enterprise applications.