At a Glance
Encrypted media, destination volumes, and credential storage.
This page covers encryption indicators, encrypted destination preparation, LUKS key operations, BitLocker and LUKS credential storage, and the operational records created by supported encryption actions.
01 / Detection
Encryption indicators.
Shadow and Shield can identify encrypted volumes when recognizable headers or metadata are accessible. Detection records can include type, confidence, unlock state, device/session context, and evidence record association.
- LUKS and BitLocker identification where headers or metadata are accessible
- Optional high-entropy analysis where enabled for unrecognized random-looking volumes
- Hardware-encryption indicators only where exposed by the detected device path
- Encryption indicators can attach to evidence records for later review
02 / LUKS
Encrypted destinations.
Supported LUKS workflows can partition destination media, create a LUKS container, open the encrypted mapper, and format the unlocked volume with a supported filesystem.
- LUKS1 or LUKS2 selection where supported
- Configurable cipher, key size, hash, key-derivation settings, filesystem type, volume label, and partition scheme
- Optional LUKS header backup creation
- Forensic metadata can record LUKS UUIDs, header backup details, operator, case, and execution context
03 / Keys
LUKS key management.
LUKS key workflows can include key-slot listing, adding passphrases, changing passphrases, removing passphrases, rotating keys, verifying headers, and restoring from backups where supported.
- Key-slot listing and passphrase operations
- Header verification and restore workflows where supported
- Unlock attempt tracking
- Operation status, actor, case metadata, and execution history retained where recorded
04 / Vault
Encrypted key vault.
The encrypted key vault is intended to store LUKS and BitLocker credentials, associate keys with device or volume identifiers, mark keys for auto-unlock, and track key usage where supported by the release.
- Credential storage scoped to validated LUKS and BitLocker workflows
- Device or volume identifier association
- Auto-unlock marking where supported
- Stored-key metadata and usage tracking for review
05 / Boundaries
Support boundaries.
Encryption detection and operations depend on what the source, destination, filesystem, device path, and release build expose. Public copy should separate detection, destination provisioning, and credential handling instead of implying universal encrypted-media support.
- A missing indicator is not proof that no encryption exists
- Hardware-encryption status may be hidden by USB bridges
- BitLocker credential workflows should stay scoped to validated support
- Synthetic decrypted-output claims belong with acquisition and conversion pages
Encryption support is conditional. Keep public claims tied to accessible metadata, enabled workflows, and release-validated LUKS or BitLocker behavior.
