Security Architecture¶
Fractum's security architecture combines modern cryptographic standards with careful implementation choices to provide a robust security posture. This document details the technical security aspects of Fractum based on its actual implementation.
Cryptographic Foundations¶
AES-256-GCM for File Encryption¶
Fractum uses the Advanced Encryption Standard (AES) implemented via PyCryptodome with:
- 256-bit key length for maximum security strength
- Galois/Counter Mode (GCM) for authenticated encryption
- Unique 16-byte nonce generation for each encryption operation using cryptographically secure random sources
- 16-byte authentication tag for integrity detection
- Automatic padding handled by GCM mode
GCM provides both confidentiality and integrity detection, protecting against both unauthorized access and data tampering. The implementation includes automatic authentication tag checking during decryption.
Enhanced Random Key Generation¶
Fractum implements a multi-source entropy system for cryptographic key generation:
# Enhanced entropy collection from multiple sources:
- Func get_random_bytes() from PyCryptodome
- OS entropy pool via os.urandom()
- High-precision timing (time.time_ns())
- Process ID and memory addresses
- System load information (when available)
All entropy sources are combined using SHA-256 hashing and SHAKE256 for extended output when needed, ensuring cryptographically secure 256-bit AES keys.
Shamir's Secret Sharing Implementation¶
The secret sharing implementation uses finite field arithmetic in GF(2^8):
- Threshold scheme: Any K of N shares can reconstruct the secret
- Information-theoretic security: Having fewer than K shares provides zero information about the secret
- Polynomial interpolation: Uses Lagrange interpolation for secret reconstruction
- Field operations: All arithmetic performed in Galois Field GF(256) for efficient byte operations
- Share generation: Each share contains an (x,y) coordinate pair from the secret polynomial
Key Management and Derivation¶
Symmetric Key Generation¶
Each encryption operation generates a unique 256-bit AES key:
- Cryptographically secure random generation using the operating system's secure random number generator
- One-time use: Every encryption operation uses a fresh, randomly generated key
- No key reuse: Keys are never stored or reused across different files
- Immediate secret sharing: The AES key is immediately split using Shamir's Secret Sharing
Memory Security Implementation¶
Fractum implements several memory protection mechanisms via the SecureString
class:
# Memory protection features implemented:
- Automatic memory clearing using ctypes.memset()
- Prevention of memory swapping with mlock() on supported systems
- Overwriting sensitive data with random bytes before deallocation
- Context manager support for automatic cleanup
- Platform-specific implementations for Windows/Unix systems
Memory Security Features: - Automatic zeroing: Sensitive data is automatically overwritten in memory after use - Swap prevention: Memory containing secrets is locked to prevent swapping to disk - Secure deletion: Multiple overwrite passes with random data before memory release - Context management: Automatic cleanup using Python context managers
File Structure and Metadata Security¶
Share File Format¶
Each share file contains:
- Share metadata: Threshold, total shares, version information, and cryptographic parameters
- Share data: The actual (x,y) coordinate pair for secret reconstruction
- Nonce: The 16-byte nonce used for AES-GCM encryption
- Authentication tag: The 16-byte GCM authentication tag for integrity detection
- File hash: SHA-256 hash of original data for integrity checking
- Encrypted filename: The original filename encrypted for privacy protection
Data Integrity Protection¶
Fractum implements multiple layers of integrity protection:
- GCM authentication tags detect any tampering with encrypted data
- SHA-256 hashing of original file content provides additional integrity checking
- Share metadata validation ensures consistency across shares
- Cryptographic binding between shares prevents mix-and-match attacks
Label and Metadata Protection¶
- Label consistency checking across all shares
- Version compatibility verification prevents mixing incompatible share formats
- Threshold validation ensures sufficient shares for reconstruction
- Encrypted metadata protects sensitive information about the original file
Network and Storage Security¶
Air-Gapped Operation Design¶
Fractum is designed for air-gapped operation:
- No network dependencies during encryption/decryption operations
- Offline cryptographic operations prevent network-based attacks
- Self-contained shares include all necessary components for decryption
- No external service dependencies for core cryptographic functions
Storage Security Considerations¶
Temporary File Handling: - No temporary unencrypted files are created during any operation - In-memory processing for all sensitive data operations - Secure deletion of any temporary artifacts - No swap file exposure through memory locking
Output Security: - Secure file permissions set on output directories and files - Atomic write operations prevent partial file creation - Checksum generation for all output files to verify integrity
Threat Model and Mitigations¶
Addressed Threat Vectors¶
Threat Category | Mitigation Strategy | Implementation |
---|---|---|
Unauthorized Access | AES-256-GCM + Shamir sharing | Cryptographic protection requiring K shares |
Data Tampering | GCM authentication + SHA-256 | Cryptographic integrity detection |
Share Compromise | Threshold cryptography | Up to K-1 shares can be compromised safely |
Code Injection | Integrity checking | SHA-256 checksums of tool and packages |
Memory Attacks | Secure memory handling | Automatic clearing and swap prevention |
Storage Attacks | Distributed storage | No single point of failure |
Security Properties¶
Confidentiality: - Data integrity detection (cryptographic authentication) - Share independence (information-theoretic security) - Memory protection (automatic clearing)
Availability: - Redundant shares (N > K design) - Self-contained operation (no external dependencies) - Cross-platform compatibility
Known Limitations and Considerations¶
Current Limitations: - Implementation vulnerabilities (no formal mathematical verification) - Side-channel attacks (timing, power analysis not explicitly mitigated) - Social engineering (human factor vulnerabilities) - Physical security (depends on user implementation)
Security Standards and Compliance¶
Cryptographic Standards Compliance¶
Fractum adheres to established cryptographic standards:
- FIPS 140-2 compatible algorithms (AES-256, SHA-256)
- NIST recommendations for key sizes and cryptographic parameters
- Package integrity checking via SHA-256 hashes
Enhanced Integrity Protection¶
The integrity protection system includes:
- File-level integrity: SHA-256 hash of original file content
- Share-level integrity: Individual hash checking for each share
- Cryptographic integrity: GCM authentication tags for tamper detection
- Original data hashing for end-to-end verification
- Metadata consistency: Cross-share validation of parameters
Operational Security Recommendations¶
Deployment Security¶
- Environment Isolation: Use air-gapped systems for sensitive operations
- Software Integrity: Always check tool and package checksums before use
- Integrity Checking: Always check tool and package checksums
- Memory Security: Reboot systems after processing highly sensitive data
- Physical Security: Implement appropriate physical access controls
Usage Security¶
- Share Distribution: Distribute shares immediately to separate secure locations
- Tool integrity: Check tool integrity before use
- Storage Security: Use appropriate storage security for share custody
- Share Handling: Check share integrity before use during reconstruction
- Access Control: Implement appropriate access controls for shares and systems
Limitations and Future Enhancements¶
Current Security Limitations:
- No forward secrecy: Compromise of all shares compromises historical data
- No authentication: Shares don't cryptographically identify their creators
- Limited protection against sophisticated state-level adversaries
- Formal mathematical verification: Not performed
- Side-channel analysis: Not comprehensively evaluated
Potential Security Enhancements:
- Hardware security module (HSM) integration
- Formal mathematical verification of implementations
- Side-channel attack resistance analysis
- Enhanced authentication mechanisms
- Perfect forward secrecy implementation
This security architecture provides strong protection against most common threat vectors while maintaining usability and operational simplicity. Regular security reviews and updates ensure continued effectiveness against evolving threats.