Appendix Q: Cryptographic Modules

Cryptographic Modules Implemented for Data-in-Transit (DIT)

OSCAL's component model treats independent validation of products and services as if that validation were a separate component. This means when using components with FIPS 140 validated cryptographic modules, there must be two component assemblies:

• The Validation Definition: A component that provides details about the validation.

• The Product Definition: A component that describes the hardware or software product.

The validation definition is a component that provides details about the independent validation. Its type must have a value of "validation". In the case of FIPS 140 validation, this must include a link field with a rel value set to "validation-details". This link must point to the cryptographic module's entry in the NIST Computer Security Resource Center (CSRC) Cryptographic Module Validation Program Database.

The product definition is a product with a cryptographic module. It must contain all of the typical component information suitable for reference by inventory-items and control statements. It must also include a link field with a rel value set to "validation" and an href value containing a URI fragment. The fragment must start with a hashtag (#) and include the UUID value of the validation component. This links the two together.

Component Representation: Data-In-Transit Example Product with FIPS 140-2 Validation

system-security-plan:
  uuid: 11111111-2222-4000-8000-000000000000
  system-implementation:
    components:
    - uuid: 11111111-2222-4000-8000-009000300003
      type: software
      title: OpenSSL
      description: 'Provide a description and any pertinent note regarding the use
        of this CM.'
      props:
      - name: asset-type
        value: cryptographic-module
      - name: version
        value: 3.0.8
      - name: vendor-name
        ns: http://fedramp.gov/ns/oscal
        value: OpenSSL FIPS Provider
      - name: function
        ns: http://fedramp.gov/ns/oscal
        value: data-in-transit
        remarks: Usage statement
      links:
      - href: '#11111111-2222-4000-8000-009001200002'
        rel: validation
        text: A link to the 3rd party validation information related to this cryptographic
          module.
      status:
        state: operational

    - uuid: 11111111-2222-4000-8000-009001200002
      type: validation
      title: OpenSSL FIPS 140-2 Validation
      description: Describe any relevant information regarding this validation of
        the CM.
      props:
      - name: asset-type
        value: cryptographic-module
      - name: validation-type
        value: fips-140-2
      - name: validation-reference
        value: '4811'
      status:
        state: operational

Understanding the Data-in-Transit (DIT) Mapping

When documenting cryptographic protections for data-in-transit, the OSCAL model focuses on the relationship between the specific software provider and its validated state.

• Software Component & Function: The first block defines the actual implementation (e.g., OpenSSL). The property name: function with the value data-in-transit explicitly categorizes the module’s role. This allows auditors and automated tools to identify which software is responsible for protecting communication channels, such as TLS or SSH connections, across the system boundary.
• Decoupled Validation Metadata: Rather than burying version-specific details in a text field, OSCAL uses a link to connect the software component to a separate validation component. This second component (highlighted by the validation-reference value 4811) points directly to the NIST CMVP certificate.
• Operational Status: The state: operational field confirms that the module is currently in use within the environment. If a module were undergoing an update or was in a "historical" state, this status could be updated to reflect the current risk posture without needing to rewrite the entire narrative.

By structuring the SSP this way, you ensure that every cryptographic module used for DIT is traceable to a specific FIPS 140-2 or 140-3 certificate, satisfying the requirements for SC-13 (Cryptographic Protection) in a machine-verifiable format.

Cryptographic Modules Implemented for Data-at-Rest (DAR)

The approach is the same as in the cryptographic module data-in-transit section.

Component Representation: Data-At=Rest Example Product with FIPS 140-2 Validation

system-security-plan:
  uuid: 11111111-2222-4000-8000-000000000000
  system-implementation:
    components:
    - uuid: 11111111-2222-4000-8000-009000300012
      type: software
      title: Database Row Encryption Module
      description: Briefly describe the cryptographic module.
      props:
      - name: asset-type
        value: cryptographic-module
      - name: version
        value: 1.2.3
      - name: vendor-name
        ns: http://fedramp.gov/ns/oscal
        value: Databases-R-Us
      - name: function
        ns: http://fedramp.gov/ns/oscal
        value: data-at-rest
        remarks: Used to encrypt and decrypt rows in the database.
      status:
        state: operational

    - uuid: 11111111-2222-4000-8000-009001200001
      type: validation
      title: Database Row Encryption Module (DREM)
      description: Briefly describe the cryptographic module.
      props:
      - name: asset-type
        value: cryptographic-module
      - name: validation-type
        value: fips-140-2
      - name: validation-reference
        value: '0000'
      status:
        state: operational

Understanding the Data-at-Rest (DAR) Mapping

In the OSCAL representation of data-at-rest protections, the focus shifts from communication protocols to the specific encryption mechanisms securing stored information.

• Defining the Storage Function: The property name: function with the value data-at-rest explicitly categorizes the module’s role. The accompanying remarks field—such as "Used to encrypt and decrypt rows in the database"—provides the necessary context for human reviewers to understand the scope of the encryption (e.g., full-disk vs. application-layer encryption).
• Asset Categorization: By using the asset-type: cryptographic-module property, the component is tagged for automated compliance auditing. This allows the system to verify that every component handling sensitive federal data is linked to a valid cryptographic implementation, directly supporting SC-28 (Protection of Information at Rest).
• Validation Linkage: Similar to the data-in-transit model, the software component is linked to a validation component that holds the NIST CMVP metadata. The validation-reference (e.g., 0000) acts as the source of truth for the FIPS 140-2 or 140-3 certificate number, ensuring that the module meets the mandatory federal security standards for data storage.

By organizing DAR in this manner, the SSP provides a granular inventory of encryption at every layer of the technology stack—from the database row level up to the storage volume—while maintaining a clear audit trail to the validated cryptographic provider.