The Automata FIPS (AFIPS) Model

note

This whitepaper defines the Automata FIPS (AFIPS) Model: a layered way to plan, implement, and assess FIPS 140 validated cryptography across modern platforms. It is the conceptual bridge between the CMVP and day-to-day engineering in federal systems and systems targeting federal authorizations.

Scope

The purpose of the AFIPS Model is to provide a clear and repeatable structure for mapping Federal Information Processing Standards (FIPS) 140 validated cryptography to real systems. AFIPS focuses on how cryptography is selected, enforced, and evidenced across operating systems, validated modules, runtimes, applications, data services, networks, and key management. It is meant for architects, practitioners, and assessors who must align modern delivery practices with FIPS 140 requirements.

This document builds on the context established in the previous AutomataSECURE publication on The CMVP and FIPS 140 2/3 which orients readers to the CMVP, Security Policies, and the role of FIPS 140 in federal assessments.

AFIPS organizes the layers of cryptography into eight layers:

• Layer 0 - Hardware Crypto Boundary
• Layer 1 - Platform OS and Policy
• Layer 2 - Validated Crypto Providers
• Layer 3 - Execution Environment
• Layer 4 - Applications and Middleware
• Layer 5 - Data Protection Services
• Layer 6 - Network and API Security
• Layer 7 - Key and Trust Management

The layers in this whitepaper are referred to as Layer (N) or L(N) with (N) representing any value from 0 through 7.

Definitions

FIPS - Federal Information Processing Standards.

Cryptographic Module - The set of hardware, software, and or firmware that implements approved cryptographic algorithms and key generation. It is contained within a defined cryptographic boundary and provides roles, services, self tests, and error handling consistent with FIPS 140.

Cryptographic Algorithm - A well defined procedure used to protect data or establish keys. In this paper the term covers approved algorithms for encryption, hashing, signatures, key agreement, and deterministic random bit generation, and any non approved but allowed algorithms used in approved key establishment modes.

Introduction to the Automata FIPS (AFIPS) Model

FIPS layers at a glance

AFIPS explains how cryptography is realized in practice. L2 provides the validated cryptographic module. L1 configures a platform policy that constrains algorithms and module selection. L3 hosts workloads that must resolve to the validated provider. L4 through L6 are where most cryptographic operations occur. L7 governs keys, trust anchors, and lifecycle.

Who uses this model

• Product and platform engineers
• Security architects and crypto SMEs
• SRE and platform teams operating federal workloads
• Assessors and authorizing officials

What this page covers

• Where crypto operations live: L4 through L6 call validated providers from L2. L2 uses L0 when hardware backed operations are required.
• Who enforces policy: L1 sets FIPS mode and system crypto policy. L3 controls admission and image integrity so workloads inherit the policy.
• Trust and lifecycle: L7 manages keys, attestation, rotation, separation of duties, archival, and destruction across the stack.

Why the AFIPS Model

Teams need a precise way to connect CMVP artifacts to design and control points. AFIPS standardizes that language so engineers and assessors reason about boundaries, approved algorithms, module selection, and evidence without guesswork.

The AFIPS Layer and Cryptographic Alogrithms

By design, only L2 (crypto provider) and L0 (hardware) should execute cryptographic primitives. All other layers call into L2 or L0 through defined interfaces. As such, L2 and L0 are the only direct users of algorithms. Other layers are indirect users that consume those algorithms by invoking L2 or orchestrating L0 through handles.

Cryptographic algorithms such as AES or RSA can be mathematically strong, but the security you achieve in practice is determined by the cryptographic module that implements and exposes them. Vulnerabilities in the module, for example weak randomness, timing or cache side channels, and other known vulnerabilities can compromise the guarantees of even the strongest algorithms. Effective protection requires modules that enforce:

1. Approved modes and suites.
2. Run constant-time code where required.
3. Protect keys with hardware.
4. Manage key lifecycles and rotation correctly.
5. Emit auditable evidence.

Within the AFIPS model, primitives execute only in L0 hardware and L2 providers, while higher layers invoke those services rather than reimplementing them. This separation lets L1 set policy, L3 enforce provider and suite selection, and L4 to L6 consume cryptography without handling raw secrets. Assurance improves when validated modules are bound to hardware roots of trust and continuously attested for configuration and version, for example through FIPS 140-3 validations, measured boot, SBOM pinning, and runtime attestation. Treat the algorithm as a specification and the module as the trust boundary, and design systems so that correct use is enforced by architecture, not by developer discipline.

AutomataSECURE developed the AFIPS Core Rings to help contextualize the relationship between the underlying cryptographic algorithms and the modules which implement those algorithms.

AFIPS Core Rings

Think of cryptography as nested responsibility zones. Algorithms are at the core, implemented and enforced by a validated module. That module is selected and constrained by platform policy and is consumed by runtimes and applications. In practice, L4 through L6 call into L2 for AEAD, signatures, KDFs and hashing. L1 keeps the system in FIPS mode and restricts algorithms. L7 governs keys, rotation, audit, and attestation.

Algorithms: AES GCM or CCM, SHA 2 or 3, HMAC, HKDF, ECDSA or ECDH, RSA PSS, DRBG

Module: CMVP validated provider in approved mode with self tests

Platform: HSM or TPM, hardware RNG, and CPU instructions under OS policy

Runtime: Containers, VMs, serverless with SBOM pins and admission gates

Automata FIPS (AFIPS) Layers

AFIPS Layer	Layer name	Purpose	FIPS focus
7	Key and Trust Management	Key lifecycle, trust anchors, attestation, certificates	Approved key establishment and wrapping, separation of duties, attestation of module state
6	Network and API Security	TLS, mTLS, IPsec, SSH, API gateways	Enforce approved cipher suites and certificate validation using a validated provider
5	Data Protection Services	Encryption at rest, tokenization, hashing, anonymization	Envelope encryption patterns using approved algorithms with keys from L7
4	Applications and Middleware	Business logic, frameworks, service meshes, brokers	Use system or bundled validated providers. Avoid non approved algorithms and modes
3	Execution Environment	Containers, VMs, serverless runtimes	Images and runtimes resolve to validated providers and inherit OS FIPS policy
2	Validated Crypto Providers	Software or hardware modules that implement algorithms	Only CMVP validated modules in approved mode are present and selected at load time
1	Platform OS and Policy	Operating system and baseline crypto policy	OS is configured for FIPS mode and system crypto APIs use validated modules
0	Hardware Crypto Boundary	Physical roots such as HSMs, TPMs, true RNGs	Device is in scope and validated. Tamper resistance and self tests operate inside the boundary

Relationship Between the AFIPS Layers

As part of cryptographic operations, AFIPS layers collaborate by issuing calls down the stack and returning validated results back up. A single TLS connection touches several layers at once.

The initiator at L4 or L6 drives policy and I/O, L2 performs approved cryptographic operations, L0 provides protected key storage and high-assurance primitives, L7 manages identity and trust, and L1 and L3 enforce platform policy and execution controls:

• Asymmetric key establishment and signatures: ECDHE for key agreement, RSA-PSS or ECDSA for authentication.
• Symmetric encryption and AEAD: AES-GCM or ChaCha20-Poly1305 for record protection.
• Hashes, MAC, and KDFs: SHA-256 or SHA-384, HMAC in TLS 1.2 PRF, HKDF in TLS 1.3 key schedule.
• Random bit generation: DRBG for nonces, ephemeral keys, and ticket keys.
• X.509 and PKI processing: certificate parsing, path building, and revocation checks for trust decisions.

L2 Call Dataflows

The diagram below shows the high level dataflows between L2 and the other AFIPS layers. The fundamental idea behind the AFIPS Model is that L2, the validated cryptographic provider, is the execution core. All other layers call into L2 for approved cryptographic operations. L2 returns results while enforcing platform policy from L1 and L3, consuming keys and trust material from L7, and delegating protected operations to L0 when hardware backing is required.

How to read the diagram

• Execution vs. policy: L4 through L6 perform cryptographic work in their domains, but they do not implement algorithms. They invoke L2 through stable APIs. L1 and L3 are not in the hot path of every operation. They set, constrain, and attest the configuration so that calls land on a validated provider in approved mode.
• Hardware delegation: When security policy or platform rules require hardware protection, L2 routes eligible operations to L0. Only public, wrapped, or handle based material leaves L0. Private key bytes do not.
• Trust and keys: L7 provides the trust and key backbone for the system. It issues and distributes anchors, certificates, and wrapping keys, and places sensitive roots in L0 where required. L2 consumes this material through approved interfaces.
• Data services: L5 centralizes encryption and integrity for data at rest by calling L2. Typical patterns include envelope encryption where L2 generates a DEK, encrypts data, and wraps the DEK under a KEK sourced from L7 and anchored in L0.
• Applications: L4 uses L2 for signing, verification, encryption, decryption, and key derivation. Verification material such as trust anchors and peer certificates is fetched from L7.
• Network and APIs: L6 terminates or originates secure channels using only approved suites. L2 supplies handshake primitives and record protection, and L7 manages credentials, stapling inputs, and resumption secrets when applicable.

Layer to Layer Dataflow Quick Map

For each caller layer, this table lists all allowed destination layers. Each layer is hyperlinked to jump to the caller's layer page which goes further in depth into each path that calls from and to the layer.

From	To	Description of Dataflows
L0	L7	Hardware generates and protects sensitive keys, then returns handles or public material to the keystore.
L1	L2, L3	Platform pins validated crypto providers and propagates policy to runtimes.
L2	L0, L7	Provider uses hardware for key operations and returns handles or material to the keystore.
L3	L2, L4, L5, L6	Admission and runtime controls enforce provider selection and suites across app, data, and network.
L4	L2, L7	Applications consume crypto via the provider and fetch verification material from the keystore.
L5	L2	Data services centralize encryption and MAC through the provider.
L6	L2	Network layer uses approved suites and provider for TLS handshakes and channels.
L7	L0, L2, L4, L5, L6	Keystore and PKI distribute anchors and KEKs and place sensitive roots in hardware.

Conclusion

AFIPS gives product, platform, and security teams a shared map for how approved cryptography lives in real systems. The layers clarify who owns what, where approved mode is enforced, and how evidence flows from design through operations. With this model, teams can pin validated providers, shape platform policy, and show assessors exactly how keys, ciphers, and controls are realized across the stack.

The next step is to turn the model into day-to-day work. We do that with the AFIPS Lifecycle. The lifecycle ties each layer to the activities, gates, and deliverables that move a change from intent to evidence, then back into governance. It explains when policy is written, how it is tested, what is promoted, and how runtime state is measured and attested.

The next paper in this series walks each AFIPS Lifecycle phase in detail. We will map activities to AFIPS layers, list the required controls and artifacts, and provide checklists you can reuse in federal and regulated workloads.