Skip to content

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:

  1. FIPS 140-2 compatible algorithms (AES-256, SHA-256)
  2. NIST recommendations for key sizes and cryptographic parameters
  3. Package integrity checking via SHA-256 hashes

Enhanced Integrity Protection

The integrity protection system includes:

  1. File-level integrity: SHA-256 hash of original file content
  2. Share-level integrity: Individual hash checking for each share
  3. Cryptographic integrity: GCM authentication tags for tamper detection
  4. Original data hashing for end-to-end verification
  5. Metadata consistency: Cross-share validation of parameters

Operational Security Recommendations

Deployment Security

  1. Environment Isolation: Use air-gapped systems for sensitive operations
  2. Software Integrity: Always check tool and package checksums before use
  3. Integrity Checking: Always check tool and package checksums
  4. Memory Security: Reboot systems after processing highly sensitive data
  5. Physical Security: Implement appropriate physical access controls

Usage Security

  1. Share Distribution: Distribute shares immediately to separate secure locations
  2. Tool integrity: Check tool integrity before use
  3. Storage Security: Use appropriate storage security for share custody
  4. Share Handling: Check share integrity before use during reconstruction
  5. 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.