Roadmap: System Infrastructure Encryption Using Common Access Cards (CAC)

TL;DR: tiCrypt plans to support Common Access Card (CAC) usage beyond authentication, where the CAC private key becomes a cryptographic root of trust for end-to-end protection of infrastructure workflows, disk encryption, virtual machine communication, and secure data exchange.

Common Access Card (CAC) in tiCrypt

The Untapped Cryptographic Potential of CAC

Common Access Cards (CAC) are one of the most widely trusted cryptographic identity systems used by the U.S. Federal Government. Across the Department of Defense ecosystem, millions of CAC credentials are used to authenticate users to secure networks every day.

In most environments, CAC credentials are used primarily for identity verification, while the infrastructure that stores and processes sensitive data continues to rely on traditional trust assumptions. Despite their widespread deployment and strong cryptographic design, CAC cards are used far below their full cryptographic potential.

Below is a cover from NIST Special Publication 500-157 (1988) titled “Smart Card Technology: New Methods for Computer Access Control.”

NIST Special Publication 500-157 cover

Source: NIST Special Publication 500-157 (1988), U.S. Department of Commerce

The publication introduced the concept of private-key-based smart cards as a stronger alternative to magnetic stripe access cards, which were easily duplicated. As the title of the NIST publication suggests, the technology was originally deployed for computer access control rather than full infrastructure encryption.

Today, the same class of smart card technology forms the basis of Common Access Cards (CAC) used across the Department of Defense.

In practice, CAC cards remain primarily used for authentication, access control, and secure email, reflecting their original access control deployment model. The embedded circuit chip (ICC) verifies who is accessing a system but is not typically used to protect the data and infrastructure workflows within that system. The underlying architectural model remains largely unchanged.

In contrast, each CAC contains an integrated circuit chip (ICC) capable of securely storing hardware-protected private keys and performing cryptographic operations such as:

  • Encryption (e.g., AES-256 key exchange and wrapping)
  • Decryption (within TLS/SSL and secure channels)
  • Digital signatures (any operation requiring a user’s private key within a PKI system)

Cryptographic protection based on public-key infrastructure (PKI) is widely recognized as a strong security control and is foundational to federal security frameworks, including NIST SP 800-171 and NIST SP 800-172.

As a result, CAC credentials play a central role in enabling users to perform secure, identity-bound operations within CMMC 2.0 (and emerging CMMC 3.0) compliant environments, where actions are tied directly to verified user identities.

Using tiCrypt with CAC

tiCrypt is built around a public-key cryptography architecture in which encryption, decryption, and digital signatures are embedded directly into the system workflow. At certain stages, a user’s private key may be present in system memory. While this is permissible under NIST SP 800-171, it nonetheless represents a potential attack surface.

Common Access Cards (CAC) contain a secure cryptographic chip that stores hardware-protected private keys and can perform cryptographic operations directly on the card.

As part of the tiCrypt roadmap, the architecture can be extended so that operations requiring a user’s private key are executed on the CAC itself rather than within system memory.

In this model, the CAC becomes the hardware root protecting sensitive operations within the enclave, including securing files, data transfers, user groups, projects, storage volumes, virtual machines, and protected communications.

As a result, the role of CAC evolves from authentication and access control toward cryptographic enforcement within a NIST SP 800-171 / 800-172 aligned system architecture.