-
Notifications
You must be signed in to change notification settings - Fork 0
Cryptographic Security
- Introduction
- Hybrid Signature Scheme Architecture
- ML-DSA Post-Quantum Implementation
- Secure Key Management
- Algorithm Selection Logic
- Side-Channel Attack Protection
- Cryptographic Primitive Validation
- Testing and Verification Framework
- Security Implications and Best Practices
- Troubleshooting Guide
The Post-Quantum WebAuthn Platform implements a sophisticated cryptographic security framework that combines classical and post-quantum cryptographic algorithms to ensure long-term security against both classical and quantum computing threats. The platform employs a hybrid signature scheme architecture that seamlessly integrates ML-DSA (Module-Lattice-Based Digital Signature Algorithm) post-quantum signatures with traditional ECDSA (Elliptic Curve Digital Signature Algorithm) for robust authentication.
This implementation prioritizes security through multiple layers of protection, including secure key generation, storage, and handling procedures for both classical and post-quantum algorithms. The platform leverages the liboqs library for ML-DSA operations and implements comprehensive algorithm selection logic based on authenticator capabilities and security requirements.
The platform implements a hybrid signature scheme that combines classical ECDSA with ML-DSA post-quantum signatures, providing defense-in-depth security against both classical and quantum adversaries.
graph TB
subgraph "Client Authentication Flow"
A[User Authentication Request] --> B[Algorithm Selection]
B --> C{PQC Available?}
C --> |Yes| D[ML-DSA Signature]
C --> |No| E[ECDSA Signature]
D --> F[ML-DSA Verification]
E --> G[ECDSA Verification]
F --> H[Authentication Success]
G --> H
end
subgraph "Registration Flow"
I[Credential Registration] --> J[Key Generation]
J --> K{Algorithm Type}
K --> |PQC| L[ML-DSA Key Pair]
K --> |Classical| M[ECDSA Key Pair]
L --> N[ML-DSA Attestation]
M --> O[ECDSA Attestation]
N --> P[Stored Credential]
O --> P
end
Diagram sources
- fido2/cose.py
- server/server/pqc.py
The hybrid architecture ensures backward compatibility while enabling forward security against quantum attacks. The system automatically selects the most appropriate algorithm based on available authenticator capabilities and security requirements.
Section sources
- fido2/cose.py
- server/server/pqc.py
The platform supports three ML-DSA parameter sets, each offering different security levels and performance characteristics:
| Parameter Set | Public Key Size | Secret Key Size | Signature Size | Security Level |
|---|---|---|---|---|
| ML-DSA-44 | 1,312 bytes | 2,560 bytes | 2,420 bytes | ~128-bit |
| ML-DSA-65 | 1,952 bytes | 4,032 bytes | 3,309 bytes | ~192-bit |
| ML-DSA-87 | 2,592 bytes | 4,896 bytes | 4,627 bytes | ~256-bit |
classDiagram
class MLDSA44 {
+int ALGORITHM = -48
+hashes.SHA256 _HASH_ALG
+verify(message, signature) void
+from_cryptography_key(public_key) MLDSA44
}
class MLDSA65 {
+int ALGORITHM = -49
+hashes.SHA256 _HASH_ALG
+verify(message, signature) void
+from_cryptography_key(public_key) MLDSA65
}
class MLDSA87 {
+int ALGORITHM = -50
+hashes.SHA256 _HASH_ALG
+verify(message, signature) void
+from_cryptography_key(public_key) MLDSA87
}
class CoseKey {
+verify(message, signature) void
+set_assertion_debug_data() void
+_log_signature_debug() void
}
MLDSA44 --|> CoseKey
MLDSA65 --|> CoseKey
MLDSA87 --|> CoseKey
Diagram sources
- fido2/cose.py
- fido2/cose.py
- fido2/cose.py
The platform implements comprehensive COSE (CBOR Object Signing and Encryption) key encoding that supports both classical and post-quantum algorithms. The encoding process handles various key formats and ensures proper DER wrapping removal for ML-DSA public keys.
Section sources
- fido2/cose.py
- fido2/cose.py
The system implements sophisticated algorithm detection mechanisms that identify and validate ML-DSA algorithms based on OID (Object Identifier) mappings and parameter set specifications.
Section sources
- fido2/cose.py
- fido2/cose.py
The platform implements secure key generation procedures that ensure cryptographic strength and prevent weak key generation scenarios. Key generation follows NIST guidelines and uses cryptographically secure random number generators.
sequenceDiagram
participant Client as Client Device
participant Server as Authentication Server
participant LibOQS as liboqs Library
participant Storage as Secure Storage
Client->>Server : Registration Request
Server->>LibOQS : Generate ML-DSA Key Pair
LibOQS->>LibOQS : Secure Random Generation
LibOQS-->>Server : Public Key + Secret Key
Server->>Storage : Encrypt and Store Secret Key
Storage-->>Server : Confirmation
Server-->>Client : Registration Response
Diagram sources
- prebuilt_liboqs/linux-x86_64/include/oqs/sig_ml_dsa.h
Sensitive key material is protected through multiple layers of security:
- Memory Protection: Key material is cleared from memory immediately after use
- Encrypted Storage: Secret keys are encrypted before persistent storage
- Access Control: Strict access controls prevent unauthorized key access
- Secure Deletion: Proper key disposal procedures ensure complete erasure
The platform implements proper disposal procedures for sensitive key material:
- Immediate Clearing: Keys are zeroed from memory after cryptographic operations
- Secure Deletion: Memory regions containing key material are securely erased
- Garbage Collection: Automatic cleanup prevents accidental key exposure
- Process Isolation: Separate processes handle different key operations
Section sources
- prebuilt_liboqs/linux-x86_64/include/oqs/sig_stfl.h
The platform implements comprehensive algorithm selection logic that considers authenticator capabilities, security requirements, and operational constraints.
flowchart TD
A[Algorithm Selection Request] --> B{PQC Available?}
B --> |No| C[Use Classical Algorithms]
B --> |Yes| D{Authenticator Supports PQC?}
D --> |No| E[Fallback to Classical]
D --> |Yes| F{Security Requirements Met?}
F --> |No| G[Use Minimum Security Level]
F --> |Yes| H[Select Optimal PQC Algorithm]
H --> I[Configure Algorithm Parameters]
G --> I
E --> I
C --> I
I --> J[Return Selected Algorithm]
Diagram sources
- server/server/pqc.py
- server/server/routes/advanced.py
The system dynamically discovers available algorithms through liboqs integration:
Section sources
- server/server/pqc.py
- server/server/pqc.py
The platform maintains algorithm preferences based on security level, performance, and compatibility:
| Priority | Algorithm Family | Security Level | Use Case |
|---|---|---|---|
| 1 | ML-DSA-87 | 256-bit | High-security applications |
| 2 | ML-DSA-65 | 192-bit | Standard security applications |
| 3 | ML-DSA-44 | 128-bit | Resource-constrained environments |
| 4 | ECDSA P-256 | 128-bit | Legacy compatibility |
Section sources
- server/server/pqc.py
The platform implements constant-time cryptographic operations to prevent timing attacks:
- Constant-Time Comparisons: All cryptographic comparisons use constant-time operations
- Masked Operations: Arithmetic operations are masked to prevent power analysis
- Cache-Aware Design: Memory access patterns are made cache-independent
- Branch Prediction Resistance: Branching is minimized in critical paths
The implementation leverages hardware security features when available:
- Hardware Random Number Generators: TRNG-based entropy sources
- Secure Enclaves: Platform-specific secure execution environments
- Memory Encryption: Hardware-managed memory encryption
- Isolated Execution: Protected execution contexts
Multiple layers of protection address potential side-channel vulnerabilities:
- Timing Attacks: Constant-time implementations prevent timing analysis
- Power Analysis: Masking and blinding techniques thwart power analysis
- Cache Attacks: Memory access patterns are made unpredictable
- Electromagnetic Analysis: Shielding and noise injection mitigate EMI attacks
Section sources
- prebuilt_liboqs/linux-x86_64/include/oqs/sig_stfl.h
The platform implements comprehensive validation of cryptographic parameters:
flowchart TD
A[Algorithm Parameters] --> B{Valid OID?}
B --> |No| C[Reject Algorithm]
B --> |Yes| D{Parameter Set Supported?}
D --> |No| C
D --> |Yes| E{Key Sizes Valid?}
E --> |No| C
E --> |Yes| F{Signature Lengths Valid?}
F --> |No| C
F --> |Yes| G[Accept Algorithm]
G --> H[Initialize Algorithm Context]
Diagram sources
- fido2/cose.py
Each cryptographic primitive undergoes security level verification:
- NIST Compliance: Algorithms meet NIST security standards
- Quantum Resistance: Post-quantum algorithms resist quantum attacks
- Implementation Correctness: Code reviews ensure proper implementation
- Side-Channel Resistance: Testing confirms resistance to side-channel attacks
The system validates algorithm metadata and ensures proper configuration:
Section sources
- fido2/cose.py
- server/server/attestation.py
The platform includes extensive testing for cryptographic operations:
graph TB
subgraph "Test Categories"
A[Unit Tests] --> A1[Algorithm Validation]
A --> A2[Key Generation Tests]
A --> A3[Signature Verification]
B[Integration Tests] --> B1[End-to-End Flows]
B --> B2[Cross-Platform Compatibility]
B --> B3[Performance Benchmarks]
C[Security Tests] --> C1[Side-Channel Analysis]
C --> C2[Attack Simulation]
C --> C3[Compliance Verification]
end
subgraph "Test Execution"
D[Test Runner] --> E[Parallel Execution]
E --> F[Result Aggregation]
F --> G[Report Generation]
end
Diagram sources
- tests/test_mldsa_registration_authentication.py
The platform includes specialized testing for ML-DSA operations:
Section sources
- tests/test_mldsa_registration_authentication.py
Automated testing ensures ongoing security validation:
- Build Verification: Tests run on every code change
- Regression Testing: Prevents security regression
- Performance Monitoring: Tracks cryptographic performance
- Security Scanning: Automated vulnerability detection
Section sources
- requirements.txt
The selection of ML-DSA parameters involves several critical trade-offs:
- Security Level: Higher parameter sets provide greater security but increased computational cost
- Performance: Smaller parameter sets offer better performance but reduced security margin
- Resource Constraints: Embedded devices may require smaller parameter sets
- Future Threats: Consider future advances in quantum computing capabilities
The platform supports gradual migration from classical to post-quantum algorithms:
- Dual Signature: Sign with both classical and post-quantum algorithms
- Gradual Phasing: Phase out classical algorithms as confidence grows
- Fallback Mechanisms: Maintain classical algorithms as fallback options
- Monitoring: Track algorithm performance and security metrics
Recommended operational practices for cryptographic systems:
- Regular Updates: Keep cryptographic libraries updated
- Key Rotation: Implement regular key rotation policies
- Audit Logging: Maintain comprehensive audit trails
- Incident Response: Prepare for cryptographic incidents
- Training: Ensure personnel understand cryptographic security
Symptoms: ML-DSA algorithms not appearing in available options Causes: Missing liboqs installation or disabled algorithms Solutions:
- Verify liboqs installation with PQC extras
- Check algorithm availability using detection functions
- Ensure proper build configuration
Symptoms: Incorrect algorithm selection or fallback behavior Causes: Incompatible authenticator capabilities Solutions:
- Verify authenticator metadata
- Check algorithm compatibility matrix
- Review fallback configurations
Symptoms: Slow cryptographic operations Causes: Suboptimal parameter choices or hardware limitations Solutions:
- Profile cryptographic operations
- Consider parameter set optimization
- Evaluate hardware acceleration options
The platform provides diagnostic capabilities for troubleshooting:
- Algorithm Detection: Verify available algorithms
- Parameter Validation: Check algorithm parameters
- Performance Monitoring: Track cryptographic performance
- Debug Logging: Enable detailed cryptographic logging
Section sources
- server/server/pqc.py
- server/server/pqc.py