Security Architecture & Smart Split White Paper

1. Problem Statement

Managing sensitive information presents fundamental challenges.

Single point of failure

Loss or compromise of a single device, cloud account, or backup often results in irreversible data loss.

Opaque security tooling

Many consumer and professional security tools present themselves as secure without clearly exposing their operational assumptions, trust model, or failure conditions. This includes undisclosed cloud dependencies, centralised recovery mechanisms, unverifiable key handling, and closed recovery paths that require the original vendor to reconstruct data.

Usability vs security trade-offs

Highly secure systems often exclude non-technical users, while usable systems frequently weaken security guarantees. In cryptocurrency and OPSEC contexts these issues are escalated — mnemonic phrases and credentials cannot be rotated easily, and compromise or loss is often permanent.

2. Design Goals

One Step Ahead is designed to:

• Eliminate single points of failure with a 2 out of 3 fragment reconstruction threshold
• Protect high-value confidential information using encryption by default
• Ensure integrity with hash-based verification
• Provide human-readable recovery in text form for non-technical users
• Operate entirely offline on user-controlled devices
• Avoid third-party dependencies and cloud services
• Enable deterministic recovery with explicit thresholds
• Allow independent reconstruction without vendor lock-in
• Make security properties explicit and auditable
• Enable independent reconstruction using open-source tooling, ensuring OSA itself is never a single point of failure for data recovery

3. Threat Model

Mitigated

• Loss or destruction of a single device or fragment
• Accidental deletion of one fragment
• Unauthorised access to a single fragment
• Data corruption — detected via integrity verification

Not mitigated

• Malware present at the moment of encryption on the device
• Coercion or forced disclosure of two or more fragments
• Loss of all three fragments
• Weak or guessable secrets — OSA protects how your secret is stored and distributed, not the strength of the secret itself

4. Privacy & Data Handling

One Step Ahead operates entirely offline and does not require or establish any internet connection at any point during operation. No data is transmitted to external servers, and no third-party frameworks, SDKs, or analytics tools are used within the application.

Sensitive data entered by the user is never cached, logged, or persisted by the application. All cryptographic operations are performed in memory and discarded upon completion. Fragments and reconstructed content are only written to storage when explicitly initiated by the user.

The only data retained by the application is non-sensitive user preferences — selected output type, Smart Split method, and terms of use acceptance. This data contains no information about the protected content.

5. System Architecture & Cryptographic Design

Seed Generation

For each encryption operation, a cryptographically random 66-character seed is generated using an alphanumeric character set (a–z, A–Z, 0–9). This produces approximately 392 bits of entropy, substantially exceeding the 256-bit security level of AES-256-GCM. The seed is ephemeral — it is never stored in full in any single output and exists in memory only for the duration of the operation.

Key Derivation

The AES encryption key is derived by applying SHA-256 to the full 66-character seed. This produces a fixed-size 256-bit key suitable for AES-256-GCM. SHA-256 is appropriate here because the seed is a high-entropy randomly generated value — not a user-supplied password. Password-based key derivation functions such as PBKDF2 or Argon2 are designed to compensate for low-entropy inputs and are unnecessary in this context. All 66 seed characters influence the derived key — any single character change produces a completely different key with no truncation or entropy loss.

Encryption

Data is encrypted using AES-256-GCM. A unique random nonce is generated for every encryption operation. The resulting output is a combined blob containing the nonce, ciphertext, and GCM authentication tag. AES-256-GCM provides both confidentiality and authenticated integrity — any tampering with the ciphertext will cause decryption to fail explicitly.

Input Normalisation

Before encryption, input data is normalised to a canonical form to ensure deterministic behaviour across platforms and sessions. For digital wallets, BIP-39 validation is performed prior to encryption — each word is validated against the BIP-39 word list and stored as its corresponding index number rather than the word itself. This ensures the canonical input is language-agnostic and unambiguous. If any word fails BIP-39 validation, the operation is rejected before encryption is attempted.

Seed Splitting

The 66-character seed is divided into three equal non-overlapping portions of 22 characters each — Leading (characters 1–22), Middle (23–44), and Trailing (45–66). Each fragment receives exactly two of the three portions, identified by label. Any two fragments are sufficient to reconstruct the full seed, from which the AES key can be re-derived and the ciphertext decrypted. The splitting process is fully deterministic and introduces no additional randomness beyond the initial seed generation.

What Smart Split Is Not

Smart Split is not a cryptographic secret-sharing scheme such as Shamir Secret Sharing. The encrypted payload is replicated in full across all fragments — only the encryption seed is segmented. Confidentiality is enforced entirely through encryption, while Smart Split provides availability and fault tolerance.

Unlike Shamir Secret Sharing, which provides information-theoretic security where individual shares reveal nothing about the secret, Smart Split segments the seed into contiguous portions. Confidentiality against a single fragment is enforced computationally through AES-256-GCM encryption and the infeasibility of brute-forcing the missing seed portion.

6. Data Representation

OSA supports three representation modes depending on data type, use case, and Smart Split version.

Note: QR is a transport and representation layer. It does not alter security properties.

Binary Fragment Format (.s32)

Binary data types such as images and PDFs are stored as .s32 files — a proprietary binary container format used by One Step Ahead to store encrypted, split binary fragments. Each .s32 file contains the full encrypted payload and two of three seed portions required for reconstruction. The file structure and internal content are intentionally opaque — no information about the protected data is exposed within the file itself.

Filenames follow a human-readable convention that includes a short random identifier and a creation timestamp. This is a deliberate usability compromise — the filename exposes non-sensitive operational metadata only and reveals nothing about the protected content. Users operating under stricter OPSEC requirements should be aware that a shared timestamp across fragments could assist an attacker in physically correlating fragments across locations. Renaming the files is fully supported — there is no filename-based correlation between fragments.

7. Reconstruction

Reconstruction requires any two matching fragments and is performed entirely offline within the application. The process is order-independent — the application determines which fragments are present from the embedded seed portion labels and derives the missing portion automatically.

macOS

On macOS, QR-based fragments are reconstructed by scanning any two matching QR codes using the device camera. Binary .s32 fragments are reconstructed by dragging and dropping or manually selecting any two matching files. Upon successful reconstruction, the original file is restored in its original format. The user is presented with an option to download the reconstructed file.

If two fragments from different splits are provided, the application detects the identifier mismatch and fails explicitly. For binary .s32 files, the application additionally detects and reports file corruption.

iOS

On iOS, reconstruction is supported for QR-based fragments only. The user scans any two matching QR codes using the device camera to reconstruct the original content. Binary file reconstruction is not currently supported on iOS.

8. Version History