Architecture
The system model, boundary by boundary.
RED brings protection, permissions, data operations and evidence together around customer-owned infrastructure. This page explains the current deployment model, its trust boundaries and the architecture Rhea is developing next.
System model
Where each responsibility sits.
Who uses the layer
People today · Applications, AI agents and workloads planned
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 the current public storage path. Database and other environment availability is listed in Product 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 plaintext RED document decryption keys
- Stored RED ciphertext alone does not reveal the file contents
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.
Rhea Key provides authentication and approval for supported RED workflows. Proving control of a key does not by itself grant access to every organization or resource; the applicable authorization still determines permitted use.
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.
Architectural direction
The same operations. Customer-controlled execution.
Current RED model
RED already brings supported document operations, protection, permissions and recorded activity together. Current connection modes can use reusable provider credentials processed by Rhea's backend. A customer-owned storage account is not, by itself, independent customer-side enforcement.
Customer-controlled architecture — in development
Your organization owns the cryptographic authority. Rhea coordinates supported operations. A connector in your environment independently verifies the signed action, resource, scope, expiry and policy before it runs, with customer-side replay protection and signed execution evidence. Reusable provider credentials remain outside Rhea in this target mode.
A shared actor model will let people, approved applications, AI agents and workloads use supported operations under separate, bounded authority. Provider adapters will extend that model across AWS, Azure, GCP, S3-compatible storage and additional environments. Databases are planned, starting with PostgreSQL; later targets include MySQL, SQL Server and selected data platforms.
The defining requirement is that compromising Rhea must not let an attacker manufacture customer authority. Achieving it includes customer-controlled enrollment, recovery and executable-update approval, not just request signatures. Protected execution must refuse invalid authority rather than silently switch to a weaker path. RED Relay remains an explicit compatibility option where the trust model differs. These are target requirements, not a completed production guarantee.
Rhea delivers the web application that performs browser-side cryptography. That delivery path and authorized endpoints remain trusted components. A malicious client update can affect future uploads and authorized opens; separating stored keys from the backend does not remove this risk.