Technical Whitepaper

1 Abstract

In the age of digital existence, personal core digital information faces two categories of existential risk simultaneously: privacy breaches and irreversible loss. Built upon a zero-knowledge architecture (ZKA) and end-to-end encryption (E2EE), SoloBox presents a comprehensive solution for digital information preservation and cross-generational inheritance.

This whitepaper details how SoloBox employs a client-side encryption engine, an IPFS-based distributed storage architecture, and a key-sharding algorithm to construct a digital information vault that is structurally incapable of being compromised or abused by its own operator. Its security guarantees do not rely on organizational trust; they are rooted in the mathematical properties of the underlying cryptographic primitives and in verifiable code logic. The ultimate result is absolute user sovereignty over digital information, provable privacy, and automated cross-generational transfer under extreme scenarios.

2 Introduction

2.1 Background and Problem Statement

Conventional cloud-storage services — including iCloud, Google Drive, and Dropbox — universally employ a custodial model in which the platform operator retains the technical capability to decrypt user data at rest. This creates an implicit single-point-of-trust dependency and introduces two classes of risk:

• Privacy risk. Server-side data breaches, insider threats, or compelled judicial disclosure may expose a user's plaintext data without their knowledge or consent.
• Continuity risk. When a user unexpectedly passes away or permanently loses capacity, digital information stored on custodial platforms enters a protracted legal-adjudication process. Critical assets — cryptocurrency seed phrases, trade secrets, irreplaceable personal records — are often locked indefinitely or destroyed entirely.

2.2 SoloBox Defined: A Non-Custodial Digital Information Safe Harbor

SoloBox is defined as a non-custodial digital information security protocol that locks privacy with hardcore local encryption and underpins storage with the IPFS distributed network. This definition carries a precise technical meaning: the SoloBox service infrastructure will never hold — and is architecturally prohibited from holding — the cryptographic material required to decrypt any user data.

Every file — whether a commercial contract, a private photograph, or a cryptocurrency seed phrase — is encrypted on the user's local device before it crosses the process boundary. The SoloBox back-end processes only opaque ciphertext binary blobs. Even the founding team and core engineers, given full database access, would observe nothing but mathematically irreducible random noise.

SoloBox reconciles three properties traditionally considered mutually exclusive:

• Military-grade confidentiality coexisting with consumer-grade UX. Users need only set a Master Password and authenticate via FaceID; the underlying AES-256-GCM encryption and Argon2id key derivation execute transparently.
• Decentralized durability. Encrypted data is replicated across global IPFS nodes with multi-copy redundancy, eliminating all single-point-of-storage dependencies.
• Automated inheritance. The built-in Sentinel Protocol (Dead Man's Switch) automatically and irreversibly delivers decryption key shards to a pre-designated beneficiary upon confirming prolonged user absence (default: 180 days).

3 Core Security Design Principles

3.1 Zero-Knowledge Architecture

The system's supreme architectural constraint is that the server must never come into contact with user-data plaintext on any code path, at any point in time. All encryption and decryption operations execute exclusively within the memory of the user's mobile device. SoloBox servers are responsible solely for relaying and indexing encrypted binary ciphertext blobs.

3.2 Data Sovereignty

The sole credential capable of decrypting data remains under the user's control at all times. SoloBox acts exclusively as an infrastructure provider and ciphertext courier; it holds no ownership of, viewing rights to, or ability to tamper with the data.

3.3 Segregated Architecture

Identity-addressing metadata (e.g., user identifiers) and encrypted payload data (file ciphertext) are forcibly isolated at both the physical-storage layer and the network-routing layer. A breach of any single database cannot be leveraged to correlate a user's real identity with their file contents.

4 System Architecture

SoloBox adopts a layered, distributed architecture engineered for high censorship resistance and availability. The system decomposes into three layers with clearly delineated trust boundaries.

4.1 Client Layer — Trust Anchor

The client is the sole trust anchor and the origin of the security boundary for the entire system. No secret material ever leaves this layer in plaintext.

• Mobile: React Native with native bindings to libsodium (a widely audited cryptographic library).
• Web: WebAssembly (WASM) sandbox delivering near-native in-browser cryptographic performance.
• Core responsibilities: Argon2id key derivation, AES-256 master-key generation, large-file chunked encryption, Secure Enclave hardware-level key custody.

4.2 Logic Control Layer — Sentinel

A stateless edge serverless computing layer hosting two core services:

• Sentinel Service: Runs scheduled tasks within a trusted execution environment, statelessly monitoring user heartbeat signals.
• API and Relay Gateway: Handles authentication, rate limiting, and IPFS upload acceleration, shielding the client from network fluctuations.

4.3 Distributed Storage Layer — Vault

SoloBox deliberately forgoes centralized object storage (e.g., AWS S3) in favor of Web3-native infrastructure. Encrypted ciphertext chunks are injected into the global distributed network via the IPFS (InterPlanetary File System) protocol. Data is redundantly replicated across global IPFS nodes, achieving tamper-proof persistent storage that depends on no single cloud vendor.

In the current phase, the system uses Pinata as the primary IPFS pinning-service gateway, with multi-provider redundancy interfaces architecturally reserved. Subsequent releases will introduce parallel multi-provider pinning and self-hosted node mechanisms, further eliminating reliance on any single pinning service.

5 Cryptographic Implementation Standards

SoloBox exclusively employs internationally recognized, peer-reviewed cryptographic standards. No proprietary or experimental algorithms are used anywhere in the system.

5.1 Key Derivation: Argon2id

The user's password is never used directly as an encryption key. The processing flow is as follows: the user's strong password is combined with a 16-byte cryptographically random salt generated locally on the device, then fed into the Argon2id memory-hard key derivation function. This function is calibrated to consume at least 1.5 seconds of device computation, ultimately producing a 256-bit master key.

The memory-hard property of Argon2id means that the cost of brute-force attacks scales linearly with memory requirements. Even with GPU-cluster resources, offline dictionary attacks are rendered economically infeasible.

5.2 Data-at-Rest Encryption: AES-256-GCM

All user data at rest is encrypted using AES-256 Galois/Counter Mode (GCM). The GCM mode simultaneously provides two guarantees: confidentiality (data is unreadable without the key) and integrity (any modification to the ciphertext — even a single bit-flip — triggers an authentication error during decryption, causing the operation to be categorically rejected). There is no silent-corruption pathway.

5.3 Inheritance Key Sharding

The inheritance mechanism must satisfy an ostensibly contradictory constraint: the platform does not hold decryption keys, yet the designated beneficiary must be able to complete decryption after the owner's death. SoloBox resolves this through a dual-shard scheme:

• Shard A (cloud-custodied shard): Stored in encrypted form in the SoloBox database. Released to the beneficiary only when the Sentinel Protocol triggers an inheritance event.
• Shard B (beneficiary-held shard): An external credential held by the beneficiary, such as a pre-shared passphrase or identity hash. The system never stores this shard.

Neither shard alone is sufficient to reconstruct the master key. Shard recombination is performed entirely within the beneficiary's browser-side WASM sandbox; at no point during this process does any plaintext key material touch the server.

5.4 Threat Model and Defense Mechanisms

SoloBox's architecture is designed under a zero-trust assumption: the server is assumed to be fully compromised from day one. All defenses remain effective under this assumption.

6 Core Operational Protocols

6.1 Sentinel Protocol

6.1.1 Heartbeat Maintenance

The client application periodically sends encrypted heartbeat packets to the edge-node cluster, updating the user's last-active timestamp.

6.1.2 Silence Determination and Grace Period

When the silence duration exceeds a configurable threshold (default: 180 days), the system enters a grace period. During this window, high-frequency alerts are dispatched to the account owner via multiple channels (email, SMS). If the owner logs in and completes biometric verification at any point within the grace period, the alert sequence is immediately halted and the inactivity timer resets to zero.

6.1.3 Irreversible Trigger

Upon expiration of the grace period, the system irreversibly releases access rights to Shard A and dispatches an activation notification to the designated beneficiary. Once executed, this operation cannot be reversed.

6.2 Time-Capsule Protocol

This protocol implements an absolute-time-based trigger mechanism. A user-configured capsule key is held under a cryptographic time lock. When the server reference clock reaches the preset future timestamp, the system automatically releases the lock and executes the designated delivery operation — whether digital or physical.

6.3 Cross-Device Seamless Migration Protocol

Device migration must strictly observe one invariant: plaintext key material must never traverse the network. The procedure is as follows:

• The user enters their account identifier and 10-character Master Password on the new device.
• The new device fetches the user's dedicated encrypted salt from the cloud.
• Argon2id key derivation re-executes locally on the new device, deterministically reconstructing the same AES master key.
• The cloud back-end participates solely as a salt courier and never observes any key material.

6.4 Beneficiary Verification and Anti-Brute-Force Security Fuse

To prevent an attacker who intercepts the beneficiary's email link from brute-forcing the verification credential, the system enforces the following safeguards:

• Local hash verification: The verification credential entered by the beneficiary is hashed locally on the device and compared against the token embedded in the link. No plaintext credential is transmitted.
• Rate limiting: Each link permits a maximum of 5 attempts per minute.
• Security fuse: After 10 cumulative failures, the link is automatically invalidated for 24 hours, and a security alert is dispatched to the security center.

7 Compliance and Privacy

7.1 Export-Control Exemption and Data Minimization

SoloBox employs non-downgradable, military-grade encryption that qualifies for the encryption export exemption (ERN) under the U.S. Department of Commerce Bureau of Industry and Security (BIS). The system strictly adheres to the GDPR data-minimization principle, collecting only the minimum amount of non-sensitive metadata necessary to sustain protocol operations.

7.2 Right to Be Forgotten and Crypto-Shredding

Because the system stores only ciphertext, the right to be forgotten can be exercised via crypto-shredding: the user destroys the master key locally, and the corresponding data on the cloud and all IPFS replicas instantly becomes cryptographically irrecoverable garbage.

It should be noted that the content-addressed nature of IPFS means ciphertext blocks may continue to exist on the network. However, under the zero-knowledge architecture, this ciphertext is indistinguishable from random noise — it contains no identity information, cannot be decrypted, and cannot be correlated. Key destruction is tantamount to the irreversible annihilation of the information, constituting a sufficient privacy guarantee.

Additionally, SoloBox provides an offline decryption toolkit. Even if the SoloBox service goes permanently offline, users can still recover their data locally using only the Master Password and the offline toolkit.

7.3 Perpetual Storage Economics

The time horizon for digital-estate inheritance often spans decades. The traditional subscription-based SaaS model cannot guarantee data survival once a user stops paying. SoloBox introduces the "Digital Perpetuity Fund" model: for higher-tier vault plans, a portion of the user's fees is allocated to a smart contract or a conservatively managed trust fund. Interest yields are used to cover the ongoing cost of IPFS pinning services, ensuring at the economic foundation that even if SoloBox the company ceases operations, the user's encrypted data will persist on the decentralized network in perpetuity.

8 Technical Roadmap

8.1 Engineering Milestones

8.2 Strategic Evolution

Phase 1: GENESIS (2026 H1) — Digital Sovereignty Awakening

Core protocol cold start. The Sentinel Protocol and Time-Capsule Protocol go live concurrently. Establishes the system's foundational privacy guarantee: data is ciphertext from the moment it leaves the device.

Phase 2: OMNISCIENCE (2026 H2 – 2027 H1) — Edge Intelligent Perception

Release of the Edge AI engine, running on-device via NPU. Integrates multi-dimensional biometric and behavioral signals for liveness detection. Federated-learning-based intelligent false-positive filtering, requiring no export of raw data.

Phase 3: ECHOES (2027 H2) — Emotional and Legal Symbiosis

Built-in on-device AI legal-advisor agent to assist in will-compliance checks. R&D on an on-device Small Language Model (SLM) for digital-testament generation. Biometric verification upgraded to v2.0 with deepfake resistance.

Phase 4: SYMBIOSIS (2028 and Beyond) — Physical–Digital Convergence

Release of the HPR (Humanoid Robot Platform Relay) standardized interface. Authorized household robots can, upon protocol trigger, physically open a safe and deliver tangible keepsakes. Support for digital-twin models with physical-world interaction, bridging the virtual and real worlds.

9 Open Source and Independent Audits

9.1 Client-Side Core Code Open Source

The client-side core modules responsible for key generation, encryption, and decryption will be progressively open-sourced in full on GitHub. Every line of security-critical code will be subject to public scrutiny by the global cryptography community.

9.2 Third-Party Independent Audits

SoloBox will engage internationally recognized blockchain and cryptographic-security firms to conduct white-box penetration testing and independent code audits. Complete audit reports will be disclosed to the public in their entirety.

10 Conclusion

SoloBox represents a return to the original promise of the internet: building infrastructure that serves the individual, rather than the other way around. By anchoring every design decision to verifiable cryptographic guarantees — rather than organizational trust — SoloBox constructs a transparent, neutral, structurally inviolable digital information vault.

In this system, technology is no longer a black box that monopolizes data. It is an enduring shield — one that defends individual digital dignity, enforces data sovereignty, and ensures that the things that matter most can be passed on intact and privately across generations.