Security & Compliance

The QUAC 100 and QuantaCore SDK are designed from the ground up for FIPS 140-3 Level 3 certification. This page documents the operational security requirements, approved algorithm boundaries, key management lifecycle, zeroization guarantees, and audit capabilities that govern cryptographic operations in compliance-sensitive deployments.

Overview #

Compliance is not an afterthought — it shapes every layer of the system architecture. The QUAC 100 hardware implements a cryptographic boundary that encompasses all key material, algorithm implementations, and random number generation. The SDK enforces policy at the software layer, ensuring that applications cannot inadvertently violate FIPS operational requirements.

FIPS 140-3 Mode #

The QUAC 100 supports two operational modes: FIPS mode and permissive mode. FIPS mode enforces the cryptographic boundary defined in the FIPS 140-3 Security Policy, restricting operations to approved algorithms, validated key sizes, and compliant random number generation. Permissive mode allows all supported algorithms including experimental and non-FIPS variants.

Enabling FIPS Mode

// Check current mode
quac_fips_status_t fips_status;
quac_get_fips_status(dev, &fips_status);

if (fips_status.mode == QUAC_FIPS_PERMISSIVE) {
    // Switch to FIPS mode (requires reboot of the module)
    quac_status_t rc = quac_set_fips_mode(dev, QUAC_FIPS_ENFORCED);
    if (rc == QUAC_OK) {
        printf("FIPS mode enabled. Module reset required.\n");
        quac_reset_module(dev);
    }
}

// Verify FIPS mode after reset
quac_get_fips_status(dev, &fips_status);
assert(fips_status.mode == QUAC_FIPS_ENFORCED);
assert(fips_status.self_test_passed == true);
printf("FIPS certificate: %s\n", fips_status.certificate_number);
printf("Firmware version: %s\n", fips_status.firmware_version);
printf("Security policy:  %s\n", fips_status.security_policy_version);

FIPS Mode Restrictions

When FIPS mode is active, the following restrictions are enforced by both hardware and SDK:

Attempting a non-approved operation in FIPS mode returns QUAC_ERR_FIPS_NOT_APPROVED. The operation is not performed, and the attempt is logged in the audit trail.

Runtime FIPS Validation

Applications can programmatically verify FIPS compliance before performing operations:

// Check if a specific algorithm is FIPS-approved in current mode
bool approved = quac_is_fips_approved(dev, QUAC_KEM_ML_KEM_768);

// Get the complete list of approved algorithms
quac_alg_t approved_algs[64];
size_t n_approved;
quac_get_fips_approved_algorithms(dev, approved_algs, 64, &n_approved);

// Verify the cryptographic module integrity
quac_integrity_result_t integrity;
quac_verify_module_integrity(dev, &integrity);
if (!integrity.firmware_valid || !integrity.sdk_valid) {
    // Module integrity check failed — do not use for FIPS operations
    abort();
}

Approved Algorithms #

The following algorithms are approved for use within the FIPS 140-3 cryptographic boundary. All implementations use constant-time execution paths and are hardened against side-channel attacks as required by the security policy.

CNSA 2.0 Compliance

For National Security Systems (NSS), the CNSA 2.0 suite requirements are satisfied by using ML-KEM-1024 for key establishment and ML-DSA-87 for digital signatures. The SDK provides a convenience function to verify CNSA 2.0 compliance:

bool cnsa2 = quac_is_cnsa2_compliant(dev, QUAC_KEM_ML_KEM_1024);
// Returns true for ML-KEM-1024, ML-DSA-87, SLH-DSA-256*

Key Lifecycle Management #

The QUAC 100 enforces a strict key lifecycle state machine for all key material stored within the hardware cryptographic boundary. Keys transition through well-defined states, and operations are only permitted on keys in the appropriate state.

// Generate a key (enters Pre-Active state)
quac_key_handle_t key;
quac_key_attrs_t attrs = {
    .algorithm      = QUAC_SIG_ML_DSA_65,
    .usage          = QUAC_KEY_USAGE_SIGN | QUAC_KEY_USAGE_VERIFY,
    .extractable    = false,
    .persistent     = true,
    .label          = "code-signing-2025",
    .activation     = QUAC_KEY_ACTIVATE_IMMEDIATELY,
    .expiry_days    = 365,
};
quac_key_generate(dev, &attrs, &key);

// Check lifecycle state
quac_key_state_t state;
quac_key_get_state(key, &state);
assert(state == QUAC_KEY_STATE_ACTIVE);

// Deactivate after rotation
quac_key_deactivate(key);
// Key can still verify old signatures but cannot create new ones

// Destroy (zeroize)
quac_key_destroy(key);
// Key material is overwritten with zeros in hardware

Key Storage

The QUAC 100 provides secure non-volatile storage for up to 4,096 persistent keys within the hardware cryptographic boundary. Keys are stored in AES-256-GCM encrypted form using the module's internal Key Encryption Key (KEK), which is derived from the hardware root of trust and never leaves the device.

// Query storage capacity
quac_storage_info_t storage;
quac_get_key_storage_info(dev, &storage);
printf("Keys: %zu / %zu, Storage: %zu / %zu bytes\n",
       storage.keys_used, storage.keys_total,
       storage.bytes_used, storage.bytes_total);

// Enumerate stored keys
quac_key_handle_t keys[128];
size_t n_keys;
quac_key_enumerate(dev, keys, 128, &n_keys);

for (size_t i = 0; i < n_keys; i++) {
    quac_key_info_t info;
    quac_key_get_info(keys[i], &info);
    printf("  [%s] alg=%s state=%s created=%s\n",
           info.label, info.algorithm_name,
           info.state_name, info.creation_time);
}

Key Wrapping and Export

In FIPS mode, key material can only leave the cryptographic boundary in wrapped (encrypted) form using AES Key Wrap with Padding (AES-KWP, SP 800-38F). This ensures keys are protected in transit between QUAC 100 devices or during backup operations.

// Wrap a key for export
uint8_t wrapped_key[4096];
size_t wrapped_len;
quac_key_wrap(key,
    wrapping_key,           // AES-256 wrapping key (must be in hardware)
    QUAC_WRAP_AES_KWP,      // SP 800-38F AES Key Wrap with Padding
    wrapped_key, sizeof(wrapped_key), &wrapped_len
);

// Unwrap on another device
quac_key_handle_t imported;
quac_key_unwrap(dev2,
    wrapping_key_dev2,      // Same wrapping key on destination device
    QUAC_WRAP_AES_KWP,
    wrapped_key, wrapped_len,
    &attrs,                 // Key attributes for imported key
    &imported
);

Zeroization Guarantees #

The QUAC 100 implements multi-layer zeroization to ensure cryptographic material cannot be recovered after destruction. These guarantees are a FIPS 140-3 Level 3 requirement and are enforced by both hardware and software.

Automatic Zeroization

Software-Side Zeroization

The SDK provides a compiler-barrier-protected zeroization function for host-side sensitive data. Unlike memset, quac_zeroize() is guaranteed not to be optimized away by the compiler:

// Zeroize host-side buffers
quac_kem_keypair_t kp;
// ... use kp ...

quac_zeroize(&kp, sizeof(kp));  // Guaranteed not optimized out

// For Rust users: the quac100 crate implements Zeroize trait
// Keys are automatically zeroized on Drop

Emergency Zeroization

// Software-triggered emergency zeroization
// WARNING: Destroys ALL key material — cannot be undone
quac_status_t rc = quac_emergency_zeroize(dev);
if (rc == QUAC_OK) {
    // All keys destroyed. Module enters error state.
    // Requires factory reset to resume operation.
}

Audit Logging #

The QUAC 100 maintains a tamper-evident audit log within the hardware cryptographic boundary. Every security-relevant event — key generation, algorithm usage, authentication, configuration changes, and error conditions — is recorded with a monotonic timestamp and sequence number. The audit log cannot be modified or deleted without detection.

Configuration

// Configure audit logging
quac_audit_config_t audit_cfg = {
    .level          = QUAC_AUDIT_VERBOSE,      // MINIMAL, STANDARD, VERBOSE
    .external_sink  = QUAC_AUDIT_SYSLOG,       // NONE, SYSLOG, FILE, CALLBACK
    .syslog_facility= LOG_AUTH,
    .file_path      = "/var/log/quac100/audit.log",
    .file_max_size  = 100 * 1024 * 1024,       // 100 MB rotation
    .file_max_files = 10,                       // Keep 10 rotated files
    .sign_entries   = true,                    // HMAC-sign each entry
};
quac_audit_configure(dev, &audit_cfg);

Audit Event Categories

Reading the Audit Log

// Read recent audit entries from hardware
quac_audit_entry_t entries[100];
size_t n_entries;
quac_audit_read(dev, entries, 100, &n_entries,
    &(quac_audit_filter_t){
        .category  = QUAC_AUDIT_CAT_KEY_MGMT,
        .since     = time(NULL) - 3600,  // Last hour
    }
);

for (size_t i = 0; i < n_entries; i++) {
    printf("[%s] seq=%lu cat=%s event=%s detail=%s\n",
           entries[i].timestamp_iso,
           entries[i].sequence,
           entries[i].category_name,
           entries[i].event_name,
           entries[i].detail);
}

// Verify audit log integrity (check HMAC chain)
bool valid;
quac_audit_verify_integrity(dev, &valid);
if (!valid) {
    // Audit log tampering detected
    log_critical("AUDIT LOG INTEGRITY FAILURE");
}

Side-Channel Countermeasures #

The QUAC 100 implements comprehensive side-channel countermeasures at both the hardware and algorithmic level. These protections are always active — they cannot be disabled, even in permissive mode.

Timing Attack Resistance

All cryptographic operations execute in constant time regardless of input values. This is enforced at the hardware level through fixed-cycle execution pipelines. The NTT butterfly network processes all coefficient operations in identical cycle counts, eliminating timing leakage from polynomial arithmetic.

Power Analysis Resistance

Fault Injection Protection

The hardware includes active fault detection circuitry that monitors voltage glitching, clock manipulation, laser fault injection, and temperature extremes. Detected fault conditions trigger immediate zeroization of active key material and transition to the error state.

// Query tamper detection status
quac_tamper_status_t tamper;
quac_get_tamper_status(dev, &tamper);

printf("Voltage monitor:     %s\n", tamper.voltage_ok     ? "OK" : "ALERT");
printf("Clock monitor:       %s\n", tamper.clock_ok       ? "OK" : "ALERT");
printf("Temperature:         %.1f°C (%s)\n",
       tamper.temperature_c, tamper.temp_in_range ? "OK" : "ALERT");
printf("Physical enclosure:  %s\n", tamper.enclosure_ok   ? "OK" : "BREACH");
printf("Tamper events:       %lu\n", tamper.total_events);

Power-On Self-Test (POST) #

Every time the QUAC 100 module is powered on or reset, it performs a comprehensive self-test sequence before accepting any cryptographic operations. In FIPS mode, POST is mandatory — the module will not enter the operational state until all tests pass.

// Query POST results
quac_post_results_t post;
quac_get_post_results(dev, &post);

printf("POST status:    %s\n", post.passed ? "PASSED" : "FAILED");
printf("POST duration:  %u ms\n", post.duration_ms);
printf("Tests run:      %u / %u\n", post.tests_passed, post.tests_total);

if (!post.passed) {
    for (int i = 0; i < post.tests_total; i++) {
        if (!post.tests[i].passed) {
            printf("  FAILED: %s — %s\n",
                   post.tests[i].name, post.tests[i].error);
        }
    }
}

// Trigger conditional self-test (non-destructive)
quac_run_self_test(dev, QUAC_SELFTEST_CONDITIONAL);

Common Criteria #

The QUAC 100 Common Criteria evaluation targets EAL4+ (augmented with ALC_FLR.3 and AVA_VAN.5) under the Protection Profile for Cryptographic Modules. The evaluation scope includes the complete product: hardware module, firmware, SDK, and management interfaces.

Key security functional requirements addressed include:

Export Controls #

The QUAC 100 is classified under Export Control Classification Number (ECCN) 5A002.a.1 as a cryptographic hardware accelerator. Export is subject to U.S. Bureau of Industry and Security (BIS) Export Administration Regulations (EAR).

Customers are responsible for ensuring compliance with all applicable export control regulations in their jurisdiction. Dyber provides export classification documentation and end-user certificate templates upon request. Contact export@dyber.com for classification details.

Next Steps #

For the complete function-level reference of all security and compliance APIs, see the API Reference. To download the validated SDK version and associated security documentation, visit the Downloads page. For questions about FIPS certification status or Common Criteria evaluation, contact compliance@dyber.com.