Asymmetric Encryption for CMMC: Public-Key Cryptography Explained

Word count: ~1,820

Specificity markers hit:

1. ✅ NIST/CMMC control references (SC.L2-3.13.8, SC.L2-3.13.11, IA.L2-3.5.10, SC.L2-3.13.15)
2. ✅ Cost/time estimate (key sizes, TLS handshake overhead, certificate costs)
3. ✅ Tool/product names (DigiCert, Let's Encrypt, OpenSSL, YubiKey)
4. ✅ Common mistakes
5. ✅ Decision point (RSA vs ECC; when to use each)

---

Asymmetric Encryption for CMMC: Public-Key Cryptography Explained

If someone asks you how your organization proves it's really you on the other end of a secure connection, the answer runs through asymmetric encryption. It's the technology that makes digital signatures, certificate-based authentication, and TLS handshakes work. For CMMC, you don't have to understand the math — but you do have to know where asymmetric encryption shows up in your environment, whether it's FIPS-validated, and what your assessor will check.

Here's what you actually need to know.

How Asymmetric Encryption Works

Symmetric encryption uses one key to lock and unlock data. Fast, efficient, good for bulk data. The problem: how do two parties that have never communicated before securely exchange that shared key? You can't email it — that's the channel you're trying to secure.

Asymmetric encryption solves this with a key pair:

• Public key — shared openly. Anyone can use it to encrypt data or verify a signature.
• Private key — kept secret. Only you can use it to decrypt data encrypted with your public key, or to create a signature others can verify.

The two keys are mathematically linked, but deriving the private key from the public key is computationally infeasible with current hardware. That's the whole basis of the system.

In practice, asymmetric encryption isn't used to encrypt bulk data — it's too slow for that. It's used for two things: secure key exchange (negotiate a session key for symmetric encryption) and digital signatures (prove something came from you and hasn't been modified). Almost every secure protocol you rely on uses both.

The Algorithms That Matter for CMMC

RSA (Rivest-Shamir-Adleman) is the most widely deployed asymmetric algorithm. For CMMC compliance, RSA keys must be at least 2048 bits, though NIST recommends 3072+ bits for anything needing protection past 2030. RSA is mature, well-understood, and supported everywhere. The downside: larger key sizes are computationally expensive.

ECC (Elliptic Curve Cryptography) provides equivalent security to RSA at much smaller key sizes. A 256-bit ECC key is roughly equivalent in strength to a 3072-bit RSA key. ECC is faster, uses less power, and is increasingly favored in modern implementations — including in FIPS 140-3 validated modules. ECDH (Elliptic Curve Diffie-Hellman) handles key exchange; ECDSA (Elliptic Curve Digital Signature Algorithm) handles signatures.

The decision point: Use ECC (P-256 or P-384 curves) for new implementations. It's faster, generates smaller certificates, and the TLS handshake overhead is measurably lower than comparable RSA. If you're replacing aging infrastructure, ECC is the right choice. If you're dealing with legacy systems that only support RSA, 3072-bit or 4096-bit RSA is acceptable.

Avoid anything else for CMMC. MD5 and SHA-1 are deprecated. DSA with 1024-bit keys is deprecated. DH groups below 2048 bits are deprecated. If your systems still use these, that's a finding waiting to happen.

Where Asymmetric Encryption Shows Up in Your CMMC Environment

TLS for CUI in Transit

CMMC practice SC.L2-3.13.11 requires FIPS-validated cryptography to protect CUI during transmission. In practice this means TLS 1.2 or 1.3 with FIPS-validated cipher suites. The TLS handshake uses asymmetric encryption — specifically, the server presents a certificate (containing its public key) and negotiates a session key using ECDH or RSA key exchange. The bulk data transfer then uses symmetric encryption (typically AES-256).

Your web servers, email gateways, VPN concentrators, and API endpoints all do this handshake. The certificates on those servers must be issued by a trusted Certificate Authority and use a FIPS-compatible algorithm. SHA-256 or higher for the signature hash. RSA-2048+ or ECC P-256+ for the key.

Certificate-Based Authentication

IA.L2-3.5.10 covers cryptographic mechanisms used for authentication. PIV cards and CAC cards — the smart card credentials used across the federal government — use asymmetric cryptography: the private key lives on the card, the public key in a certificate. When someone authenticates with a CAC, the system challenges their card with a random value; the card signs it with the private key; the system verifies the signature against the certificate.

For organizations that process CUI under DoD contracts, certificate-based authentication for privileged accounts is increasingly expected. MFA hardware tokens that use asymmetric cryptography (like YubiKeys in FIDO2/WebAuthn mode) are a practical alternative for contractors who aren't issuing PIV credentials.

Digital Signatures and Document Integrity

SC.L2-3.13.8 requires protecting CUI at rest with FIPS-validated encryption, and SC.L2-3.13.15 addresses communications authenticity. Digital signatures — which rely on asymmetric cryptography — provide proof that a document came from a specific source and wasn't modified after signing.

In practice: digitally signed emails (S/MIME), signed PDF documents sent to the government, and code signing for software deliverables all use asymmetric cryptography. If your organization delivers software or technical documentation under a DoD contract, ask your contracting officer whether code signing or document signing is expected. Many aren't — but when it is required, the certificate must be from a trusted CA and use a FIPS-compliant algorithm.

VPN and Encrypted Tunnels

Site-to-site VPNs and remote access VPNs use asymmetric cryptography during the key exchange phase (IKEv2, for example, uses ECDH for forward secrecy). The certificate your VPN gateway presents to remote clients is an asymmetric key pair. Your VPN configuration needs to specify FIPS-validated algorithms for both the asymmetric key exchange and the symmetric bulk encryption that follows.

What FIPS Validation Actually Means

FIPS 140-3 (replacing FIPS 140-2) is a federal standard for cryptographic modules. A module is "validated" when it has been tested by an accredited lab and listed in the NIST Cryptographic Module Validation Program (CMVP) database.

This matters because "using AES-256 and RSA-2048" is not sufficient for CMMC. The implementation of those algorithms must be FIPS-validated. OpenSSL, for example, is not inherently FIPS-validated — but OpenSSL with the FIPS-validated provider module (currently OpenSSL 3.x with the FIPS module enabled and validated) is. Windows' CNG (Cryptography: Next Generation) has FIPS-validated implementations for the algorithms it supports. macOS uses Apple's Corecrypto module, which has FIPS-validated status for current macOS versions.

When your assessor asks about encryption, they'll want the CMVP certificate number for the module protecting CUI, not just the algorithm name. Before your assessment, run through every system that stores or transmits CUI and document which FIPS-validated module it uses. Pull the certificate numbers from csrc.nist.gov/projects/cryptographic-module-validation-program.

Common Mistake: Mixing Up "Supports TLS 1.2" with "Uses FIPS-Validated Crypto"

A system can support TLS 1.2 and still not be FIPS-compliant. The cipher suite matters. TLS_RSA_WITH_AES_256_CBC_SHA256 uses RSA and AES-256 — both FIPS-compliant algorithms — but the specific implementation library must be validated. Meanwhile, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 with a non-validated OpenSSL build is not FIPS-compliant regardless of how strong the algorithms look on paper.

The other common mistake: using self-signed certificates for CUI-facing services. Self-signed certificates use asymmetric cryptography, but they don't establish trust — any client that accepts them is open to man-in-the-middle attacks. CUI-facing systems need certificates from a trusted CA. For internal systems, you can run a private CA (Microsoft ADCS, or HashiCorp Vault as a CA), but it must be properly integrated with your trust stores. Public-facing systems need certificates from a recognized public CA — DigiCert, Sectigo, Let's Encrypt (for web) all work.

Practical Setup for a Small Defense Contractor

If you're running a small shop (under 100 users) handling CUI, here's what asymmetric encryption looks like in practice:

• TLS certificates: Use certificates from a trusted CA on all CUI-facing web services, email gateways, and VPN concentrators. For internal services, set up a Microsoft ADCS private CA or use your domain controller's built-in PKI. Certificate costs range from free (Let's Encrypt for public web) to $100–$500/year per certificate for OV/EV certificates from commercial CAs.
• VPN: IKEv2 with ECDH-based key exchange (P-256 or P-384) and AES-256-GCM for bulk encryption. Cisco, Palo Alto, and Fortinet VPN products all support FIPS mode.
• MFA for privileged accounts: FIDO2/WebAuthn hardware tokens (YubiKey 5 series, ~$50/key) for admin accounts and remote access. These use ECC asymmetric cryptography and are significantly more phishing-resistant than TOTP apps.
• Code/document signing: If your contract requires software delivery, get a code signing certificate from DigiCert or Sectigo ($300–$500/year for an OV code signing cert).

What Your Assessor Expects

For SC.L2-3.13.11 (encryption in transit), the assessor will verify: - TLS 1.2 or 1.3 is configured on systems that transmit CUI - Weak cipher suites (RC4, 3DES, TLS 1.0/1.1) are disabled - The cryptographic module used is FIPS-validated (they'll ask for the CMVP certificate number)

For IA.L2-3.5.10 (cryptographic authentication), if you're using certificate-based authentication, they'll verify: - Certificates are issued by a trusted CA (not self-signed) - Private keys are stored securely and not exportable - Certificate validity periods are managed (no expired certs in active use)

The most common evidence request: network configuration screenshots showing TLS settings, plus documentation identifying the FIPS-validated module in use. Have those ready before the assessment starts.

---

For the broader picture on how encryption fits into your CUI protection requirements, see the companion article on NIST 800-171 encryption controls for CUI at rest and in transit.