Metadata and credentials
What Rhea can access, and what stays outside its backend.
This page separates protected document contents and keys from the metadata, provider credentials and client-delivery responsibilities involved in operating Rhea Data.
Visible to Rhea
What Rhea can see.
- Filenames, folder names and file types, stored today as plaintext metadata
- Document identifiers, file sizes, chunk counts and encryption generation
- Organization identifiers, membership and roles
- Wallet addresses used for authentication and key wrapping
- Timestamps and access, administrative and security audit events
- Storage configuration: provider, bucket, region and endpoint
- Usage and metering records used for billing
- Wrapped key material — as ciphertext that Rhea cannot unwrap
LimitationFilenames, folder names and MIME types are stored as plaintext metadata today. Encrypted metadata is planned, not shipped. Do not put sensitive information in a filename.
Not visible to Rhea
What Rhea cannot see.
- The plaintext contents of any protected file
- Per-document data encryption keys
- The wallet-derived key that unwraps them
- Recovery shares in plaintext, or any guardian private key
- Anything that would let Rhea reconstruct a document on its own
Access matrix
Who can reach what, by mode.
Plaintext file contents
- Standard mode
- Never — encrypted on your device before upload
- Hardened mode
- Never — encrypted on your device before upload
Document encryption keys
- Standard mode
- Never — wrapped to holders, unwrapped only on an authorized device
- Hardened mode
- Never — wrapped to holders, unwrapped only on an authorized device
Storage provider credentials
- Standard mode
- Encrypted at rest; Rhea's backend can open them to operate the connection
- Hardened mode
- Sealed on your device; Rhea holds no key that opens them
Payload network path
- Standard mode
- Through Rhea's backend as ciphertext
- Hardened mode
- Browser directly to your storage account
Filenames, sizes and audit records
- Standard mode
- Visible to Rhea as operational metadata
- Hardened mode
- Visible to Rhea as operational metadata
| Material | Standard mode | Hardened mode |
|---|---|---|
| Plaintext file contents | Never — encrypted on your device before upload | Never — encrypted on your device before upload |
| Document encryption keys | Never — wrapped to holders, unwrapped only on an authorized device | Never — wrapped to holders, unwrapped only on an authorized device |
| Storage provider credentials | Encrypted at rest; Rhea's backend can open them to operate the connection | Sealed on your device; Rhea holds no key that opens them |
| Payload network path | Through Rhea's backend as ciphertext | Browser directly to your storage account |
| Filenames, sizes and audit records | Visible to Rhea as operational metadata | Visible to Rhea as operational metadata |
Document contents and document keys are outside Rhea's reach in both modes. The modes differ only in who can open the storage credentials and where the payload travels.
Credential modes
Two ways to connect your storage.
Hardened — client-encrypted direct storage
- Can Rhea open the credentials?
- No. Rhea holds no key that opens the envelope.
- Payload path
- Your browser signs each request and transfers directly to your own bucket.
- Setup required
- A CORS rule on your bucket allowing requests from the Rhea Data application.
Standard — Rhea-operated connection
- Can Rhea open the credentials?
- Yes — storage credentials only, never document keys or contents.
- Payload path
- Rhea's backend issues presigned URLs and performs server-side storage operations.
- Setup required
- A scoped storage user. No bucket CORS configuration needed.
| Mode | Can Rhea open the credentials? | Payload path | Setup required |
|---|---|---|---|
| Hardened — client-encrypted direct storage | No. Rhea holds no key that opens the envelope. | Your browser signs each request and transfers directly to your own bucket. | A CORS rule on your bucket allowing requests from the Rhea Data application. |
| Standard — Rhea-operated connection | Yes — storage credentials only, never document keys or contents. | Rhea's backend issues presigned URLs and performs server-side storage operations. | A scoped storage user. No bucket CORS configuration needed. |
Hardened mode is the recommended standard. Standard mode remains available where server-side background operation matters more than removing Rhea from the credential path.
Defence in depth
Four independent boundaries.
- Zero-knowledge credential envelope: Cloud keys, Azure connection strings and service-account private keys are sealed with AES-256-GCM in browser memory. The key is derived from your Rhea Key signature and bound to the organization identifier and provider type. Rhea's database receives ciphertext and an initialisation vector; the server-side decryption path returns CREDENTIALS_CUSTOMER_HELD.
- Ephemeral in-memory boundary: Opened credentials exist only in the memory of an authorized browser session and are discarded on disconnect, lock or sign-out. They are never written to local storage, session storage or cookies.
- Direct-to-storage wire: Requests are signed in the browser through WebCrypto and sent straight to your storage account. Payloads do not pass through Rhea's infrastructure, so there is no point at which Rhea could observe them.
- Double-blind payload encryption: File contents are already encrypted on the device before upload. A full compromise of your own storage account yields authenticated ciphertext that cannot be opened without key material held on authorized devices.
Credentials
The credential boundary, stated plainly.
In Hardened mode, storage credentials are sealed on your device under a key derived from your Rhea Key signature. Rhea's database holds ciphertext and an initialisation vector, and the server-side decryption path refuses with CREDENTIALS_CUSTOMER_HELD. Compulsion, insider access or a full server compromise does not produce a usable credential, because the key to open it was never sent.
In Standard mode, Rhea holds a server-side key that decrypts your storage provider credentials. That is what makes a Rhea-operated connection possible, and it means Rhea's backend can reach your bucket.
Neither mode lets Rhea read your files. Document keys are wrapped by key material derived on your device and are not recoverable server-side. Reaching the bucket yields ciphertext.
Hardened mode
Your storage keys never arrive in a form Rhea can read.
The connection is still set up by typing credentials into a form. What changes is where they are sealed and where they are used: both happen on your own device, so a complete compromise of Rhea’s servers yields an envelope with no key beside it.
Seal on entry
You type the storage keys into the connection form. The page derives a key from your Rhea Key signature and seals them before anything is sent.
Holds: The only key that opens the envelope
Holds the envelope
Rhea stores the sealed block and the policy, and records the operation. There is no server-side path that opens it.
Holds: Ciphertext and initialisation vector
Open and sign in memory
An authorized session opens the envelope in browser memory and signs the storage request there. The opened value is discarded on lock or sign-out.
Holds: Opened credentials, in memory only
Direct to your bucket
The signed request goes straight from the browser to your own storage account. Payloads do not pass through Rhea's infrastructure.
Holds: Your encrypted objects
Signing in the browser
Every supported provider is signed on your side.
- S3-compatible
- AWS Signature Version 4, HMAC-SHA256 via WebCryptoAWS S3, Cloudflare R2, MinIO, Oracle Object Storage, Wasabi, Backblaze B2, Ceph
- Azure
- Shared access signature, service version 2023-11-03Azure Blob Storage
- Google Cloud
- V4 canonical request, RSA-SHA256 over a PKCS#8 service-account keyGoogle Cloud Storage
Check it against your own bucket.
Objects written by Rhea Data into storage you own can be read directly out of your storage account.