Architecture
The system model, boundary by boundary.
Data is held by infrastructure the organization already owns. Protection, authority, operations and evidence are maintained by Rhea around that data. This page describes how, without selling anything.
System model
Where each responsibility sits.
Consumers
People · Applications · AI systems
Rhea
Protection · Authority · Operations · Evidence
Client-side cryptography, authorization evaluation, operational metadata, storage orchestration and the audit record.
Infrastructure holding the data
Object storage · Clouds · Databases · Private infrastructure
AWS S3 is available today. Other environments each carry their own status.
Trust boundaries
What sits inside the organization's control, and what does not.
Inside the organization
- Per-document data keys
- The wallet-derived key that wraps them
- Guardian recovery keys and Recovery Kits
- Plaintext, on authorized devices only
Rhea's side
- Operational metadata, including filenames today
- Wrapped key material, as ciphertext
- Authorization policy and decisions
- Storage credentials, decryptable by Rhea
- The delivered web application
Storage provider's side
- Encrypted objects and chunk layout
- Bucket, region and access logs
- No key material
- No ability to read protected content
Rhea holds a server-side key that decrypts the storage-provider credentials you supply, so RED can perform storage operations on your behalf. That key does not decrypt file contents, recovery shares, or any document key.
Protection flow
What happens before storage receives anything.
- 01Select
A file is chosen in RED on an authorized device.
- 02Key
A per-document data key is generated in the browser.
- 03Encrypt
Content is encrypted in 5 MB chunks with AES-256-GCM, each with a fresh IV.
- 04Bind
Each chunk is bound to its document, generation and position; the manifest is authenticated.
- 05Store
Ciphertext is written to the organization's own storage. The data key is wrapped and stored separately.
Every encrypted chunk is cryptographically bound to its document, its encryption generation and its exact position in the file. Reordering, duplicating, deleting or substituting chunks inside the bucket is detected and the file refuses to open.
The chunk manifest is authenticated with HMAC-SHA-256 under a key derived from the file's own encryption key. Only a party who can already decrypt the file can produce a valid manifest.
Authorized read
How protected data becomes readable again.
- 01Request
An authenticated member asks to open a document.
- 02Evaluate
Organization and resource policy are evaluated. A lookup failure denies.
- 03Authorize
A short-lived, limited-use, revocable authorization is issued and consumed atomically.
- 04Unwrap
The wrapped data key is unwrapped in the browser with the member's own key.
- 05Open
Chunks are verified and decrypted locally. The event is recorded.
Each decryption is gated by a short-lived, limited-use, revocable authorization evaluated against organization and resource policy. Use is consumed atomically in the database, so a token cannot be replayed beyond its limit. If policy cannot be read from the database, access is denied. A lookup failure is treated as a denial, never as an absence of policy.
There is no server-side decryption path. The API endpoint that would perform it returns 501 by design and no implementation exists behind it.
Key hierarchy
Which key opens what.
Data key (per document)
Generated in the browser. Encrypts the document's chunks. Never transmitted in the clear.
Wrapping key (per member)
Derived in the browser from a wallet signature. Wraps the data key. Never held by Rhea.
Recovery envelopes (per guardian)
Shares encrypted to each guardian's own P-256 key. Reconstruction happens only in the initiating administrator's browser.
The keys that make file contents readable — the per-document data key and the key that wraps it — are generated on your device and are never generated, held or derivable on Rhea's servers.
Rhea's backend and its entire database, taken together, cannot reconstruct a recovered key. The only keys that open recovery shares are guardian keys held outside Rhea and a session key that never leaves the initiator's browser.
Authorization
Rhea Key carries the authority to approve.
Rhea Key authenticates with wallet signatures over a canonical message using server-issued single-use nonces and short, revocable sessions. Biometrics gate the local vault on the device only — they never leave it and never replace the signature.
Administrative role and decryption authority are separate. An organization Owner or Admin cannot decrypt another member's document — administration does not grant readability.
Supported Trezor hardware can be used as an authentication and approval device in RED. Trezor is a separate third-party device and is not part of the Rhea Key application.
Storage model
Bring Your Own Storage.
RED uses a Bring Your Own Storage model. Your organization connects storage it already owns and controls. Rhea does not provide, host or operate customer storage.
Data movement
Moving protected data between locations.
- 01Check
Source, destination and credentials are validated.
- 02Transfer
Encrypted objects are copied to the destination.
- 03Verify
Integrity is checked against the authenticated manifest.
- 04Cut over
RED points to the new location; keys and policy are unchanged.
- 05Record
The operation is written to the audit record.
Moving documents between storage locations copies them; the source object is not deleted by the move itself.
Integration boundary
What is connected today, and what is not yet.
Connected today
Object storage through the S3 protocol, with AWS S3 as the approved public path (Available).
Not connected yet
Database connectivity (Controlled pilot), application and AI-agent authority (Planned), and public API and SDK documentation (Planned).
Rhea serves the web application that performs encryption in your browser. That is the standard trust boundary of any web-delivered cryptography, and it applies to RED as it does to every browser-based system.