Advent Business Company, Inc.

Enablement® Platform
End-to-End Encryption

FedRAMP High-Ready · Zero Trust · CMMC Level II Compliant
The only SECaaS platform purpose-built to protect CUI with true client-side E2EE.

How Enablement® Protects CUI End-to-End

Data is encrypted on the client before transmission, stored encrypted at rest, and decrypted only on the authorized recipient's device. The server never has access to plaintext data or encryption keys.

ENCRYPTION FLOW — SENDER

🔐

Authenticate

MFA + time-sensitive encrypted token generated

🔑

Key Exchange

ECDH P-256 derives shared secret on client

🛡️

Encrypt

AES-256-GCM encrypts data + signs with ECDSA

📦

KB02 Bundle

Ciphertext + metadata sealed in KB02 structure

☁️

Store

Encrypted bundle stored on server — zero plaintext

DECRYPTION FLOW — RECIPIENT

🔐

Authenticate

Recipient verifies identity via MFA

📥

Retrieve

Download encrypted KB02 bundle from server

Verify

SHA-256 integrity check + ECDSA signature validation

🔑

Derive Key

ECDH + HKDF reconstructs AES key on client

📄

Decrypt

AES-256-GCM decrypts — plaintext visible only to recipient

⚡ ZERO-KNOWLEDGE ARCHITECTURE

The Enablement® server never sees plaintext data, encryption keys, or shared secrets. All cryptographic operations happen client-side.

Cryptographic Implementation Details

Every component is FIPS 140-2 aligned and mapped to NIST SP 800-171 / CMMC Level II controls.

Phase 1
Key Establishment — ECDH P-256 Ephemeral-Static
Algorithm Elliptic Curve Diffie-Hellman on NIST P-256 curve
Output 32-byte shared secret (never stored, never transmitted)
Mode Ephemeral-static: new key pair per encryption session
CMMC Alignment SC.L2-3.13.11 — CUI confidentiality via FIPS-validated crypto
Phase 2
Key Derivation — HKDF with SHA-256
Input ECDH shared secret
Salt 16 random bytes (stored in KB02 bundle)
Info Context string e.g. "KB02-CEK-v1.0" (stored in bundle)
Output 256-bit AES key (derived, never stored)
Phase 3
Symmetric Encryption — AES-256-GCM
IV 12 random bytes, unique per encryption
Auth Tag 16-byte GCM tag — cryptographic tamper proof
AAD Manifest artifactId, objectKey, mime, size, createdAt, policy flags (view/print/download), version
Result Ciphertext + tag — authenticated encryption with associated data
Phase 4
Key Wrapping & Multi-Recipient
Key Wrap AES-KW (RFC 3394) or AES-KWP (RFC 5649)
RSA Fallback RSA-OAEP-3072 with SHA-256 for CEK wrapping
Multi-Recipient Wrapped CEK per recipient — one ciphertext, N key wraps
Forward Secrecy Ephemeral EC keys ensure past sessions stay secure
Phase 5
Digital Signature & Integrity
Signature ECDSA P-256 with SHA-256 — authenticity & non-repudiation
Ciphertext Hash SHA-256 of encrypted data — public integrity check
AAD Hash SHA-256 of metadata — separate metadata integrity
Verification Hash check before decrypt; signature verifies origin
📦 KB02 BUNDLE STRUCTURE
CiphertextN bytes
IV12 bytes
Auth Tag16 bytes
AAD Manifest~300 bytes
Ciphertext SHA-25632 bytes
AAD SHA-25632 bytes
HKDF Salt16 bytes
HKDF Info~20 bytes
ECDSA Signature~72 bytes
Ephemeral EC PubKey~65 bytes
Wrapped CEK(s)per recipient

Total overhead: ~500 bytes + per-recipient wrapped keys. AES key is never stored — derived at runtime via ECDH + HKDF.

Why FedRAMP ≠ CMMC Compliance

FedRAMP-certified cloud storage providers protect infrastructure, not CUI data. CMMC requires end-to-end CUI protection that Box, OneDrive, Google Drive, AWS S3, and Dropbox fundamentally cannot provide.

CMMC Requirement Enablement® Box OneDrive /
SharePoint
Google
Drive
AWS S3 /
GovCloud
Dropbox
Client-Side E2E Encryption True E2EE — keys never leave client Server-side only Server-side only Client-side via API only SSE-C (you manage keys) Server-side only
Zero-Knowledge Architecture Server never accesses plaintext Provider holds keys Microsoft holds keys Google holds keys Depends on config Dropbox holds keys
CUI Classification & Tagging Automated via AAD manifest Manual labels Sensitivity labels No CUI awareness No CUI awareness No CUI awareness
FIPS 140-2 Encryption AES-256-GCM, ECDSA P-256 AES-256 AES-256 AES-256 AES-256 AES-256
Policy-Enforced Access (View/Print/Download) Cryptographically bound in AAD UI-level only IRM (limited) UI-level only Not available UI-level only
Non-Repudiation (Digital Signatures) ECDSA on every bundle Not available Not built-in Not available Not available Not available
Tamper Detection (Integrity) GCM tag + SHA-256 hashes Checksums only Checksums only Checksums only Checksums + versioning Checksums only
CMMC Level II Certified Purpose-built for CMMC FedRAMP only GCC High (partial) FedRAMP only FedRAMP only No FedRAMP
Multi-Recipient Key Distribution Wrapped CEK per recipient Shared link model ACL-based ACL-based Bucket policies Shared link model
Audit Trail for Each Process Per-process action audit with retention Basic admin logs Unified audit log Activity dashboard CloudTrail Basic events

Why FedRAMP Cloud Storage Fails CMMC

These providers protect their infrastructure — not your CUI. Here's where each falls short.

📦

Box

Server-side encryption means Box holds the keys. CUI is decrypted at rest on their servers. No digital signatures, no cryptographic access policy enforcement, no CUI-aware classification. FedRAMP authorization covers Box's infrastructure, not your data protection.

Not CMMC Compliant
☁️

Microsoft OneDrive / SharePoint

Even GCC High still uses Microsoft-managed encryption keys. Sensitivity labels provide UI-level classification but no cryptographic enforcement. IRM offers limited protection but keys are managed server-side by Microsoft.

Not CMMC Compliant
🔍

Google Drive

Client-side encryption available via API but requires custom implementation. Google holds standard encryption keys. No CUI awareness, no CMMC-specific controls, no policy enforcement at the cryptographic layer.

Not CMMC Compliant
🗄️

AWS S3 / GovCloud

SSE-C allows customer-managed keys but places the entire implementation burden on the contractor. No built-in CUI tagging, no access policy binding, no digital signatures. FedRAMP covers AWS infrastructure, not the CUI workflow.

Partial — Heavy DIY
💧

Dropbox

No FedRAMP authorization. Server-side encryption with Dropbox-held keys. No CUI awareness, no compliance controls, no digital signatures. Not viable for any DoD contractor handling CUI.

Not CMMC Compliant

The Enablement® Advantage

Purpose-built from the ground up for CMMC compliance — not retrofitted from consumer cloud storage.

01

True Zero-Knowledge E2EE

Encryption and decryption happen exclusively on the client. The server never has access to plaintext data, encryption keys, or shared secrets — eliminating insider threat risk.

02

Cryptographic Policy Enforcement

Access policies (view, print, download) are bound into the AAD manifest and verified during decryption. Unlike UI-level restrictions, these cannot be bypassed.

03

Built-In Non-Repudiation

Every KB02 bundle includes an ECDSA digital signature, providing mathematical proof of who encrypted the data — critical for DoD audit and legal requirements.

04

CUI-Native Architecture

The AAD manifest automatically classifies and tags CUI metadata — artifactId, sensitivity, permissions — all cryptographically sealed and tamper-evident.

05

CMMC + FedRAMP High Ready

Not just infrastructure compliance — full CMMC Level II coverage including SC, AC, AU, and IA control families, validated through Enablement's Zero Trust architecture.

06

Multi-Recipient Without Shared Keys

Each recipient gets their own wrapped Content Encryption Key — no shared links, no shared passwords. Revocation is per-recipient without affecting others.