How Gopniya implements zero trust

The short version

Your data is encrypted on your device. Outside a handover, we cannot see your passwords, files, notes or even their names.
The only things we can ever open are the items you set for handover, and only after your inactivity period has passed. That takes our hardware security module plus two of three staff hardware keys, approved by two people and logged.
Every person, service and machine gets the least access it needs, for the least time, and has to prove who it is every time.

Encryption happens on your device

All encryption and decryption happens in your browser. Our servers receive only encrypted data.

Your master password is stretched with Argon2id, a deliberately slow function that makes guessing expensive.
A 128-bit Secret Key is created on your device and never sent to us. It is combined with your password, so even a stolen copy of our database can’t be used to guess your password.
Every folder has its own key, and every file gets a new key each time it is encrypted. Data is sealed with XChaCha20-Poly1305, which also detects any tampering.
Names are encrypted too. Folder names, file names and password sites never reach us in readable form. Your search index is encrypted as well, which is why search still works on a new device.

What we can see: that you have an account, how many items you store and how big they are, and when you use the app. We need that to run the service.

Only you hold your keys

Your Emergency Kit holds your Secret Key and a Recovery Key. You save it before sign-up finishes.
Two-factor login uses passkeys first and authenticator apps as a fallback. We don’t use SMS codes for two-factor.
A new device gets your Secret Key by scanning a QR code from one you already use, or from your kit.
Keys are held in memory while you use the app, and the app locks itself when idle.

What we can open, and why

Three kinds of data are sealed so that we can open them, because the service can’t work otherwise:

Handover packets: exactly what you set for each person, and nothing more.
Your nominees’ contact details, so we can find them. Only the short name you give each person, like “Mom”, is readable, for reminders.
Your account key, only if you turn on account recovery. It is off unless you choose it.

Each one is locked in three layers:

Your own key, so your browser can keep a packet up to date as you edit.
Two of three staff hardware keys. Each staff key decrypts its layer inside the device. The private keys never leave the hardware.
Our hardware security module (HSM), as the outer layer. It opens only for our isolated handover service, only during a time-limited window approved by two people, and only for an account that has passed its inactivity period and been frozen.

Every unlock is logged and checked against that one account. Logs never contain secrets or ID numbers. The isolated service decrypts, prepares each nominee’s copy (encrypted for an online nominee, or printed and written to a USB drive for an in-person one) and wipes all plaintext when it’s done.

Zero trust inside the company

No permanent keys. Our services and build pipeline prove their identity to the cloud on every request. There are no long-lived cloud passwords to steal.
Private by default. Our database, storage and key vault can’t be reached from the internet at all.
Least privilege. Each service gets its own identity, limited to its own resources. The app can’t touch backups, and the backup system can’t read the database.
Hardware keys for every staff login. Production access is granted just in time, with approval, and expires.
Two approvers for every deployment. Code can’t reach production without review and a second approval.
Everything is watched. Logins, key use, permission changes and deployments feed a security monitoring system that alerts on anything unusual. Emergency accounts are kept offline, and any use of one raises an alarm.

Verifying the code in your browser

When encryption happens in the browser, the weak point is the code itself. If someone tampered with the app we send you, they could take your keys. So it must be possible to verify the code.

Builds are reproducible, and each release is signed in our pipeline and checked before it is deployed.
Every script and stylesheet carries an integrity hash, and we publish the hashes of each release so anyone can check what was served.
A strict security policy, and no third-party scripts on app pages. This website already follows that rule: no trackers, no ad scripts, and even our fonts are served by us. It records only the page, the referring site, campaign tags, and your country and city. See privacy.

Backups

Your encrypted data lives on Microsoft Azure and is copied to Amazon Web Services as it is written. Backups are locked so they can’t be altered. Backup keys are kept with Azure, AWS and offline, so a restore works even if one cloud is gone.

Deletion still works with backups. When you revoke a share or cancel a handover, its key is destroyed, and backup copies become unreadable within 30 days.

The handover online

The notice we send by email and SMS says only that something was left for the nominee and how to receive it. It never contains your secrets.
The nominee verifies their identity through DigiLocker and a live face match, against the ID you gave us. If the check fails, nothing is handed over, and we contact them to arrange another check.
Only after the check can they download their copy, which is encrypted for them alone.

The handover in person

Each nominee’s pages are printed and their USB drive is written in-house, on an isolated machine. Both are sealed in a tamper-evident, serial-numbered envelope and tracked by hand to the handover.
The pages and the drive are not encrypted, so the nominee can read them without any key. Until the handover, the sealed envelope and the custody log protect them. After the handover, the nominee does.
Two staff go together. They check your nominee’s original ID with DigiLocker and a face match, against the ID you gave us.
Each visit is recorded without a break, and the recording is encrypted on the device as it is captured. Watching one takes our HSM plus two staff keys, a dispute or legal reason, and two approvers. A lost device holds nothing readable.

What we cannot protect against

Gopniya cannot protect your secrets in these cases.

A compromised device. If someone controls your phone or computer while your vault is open, they can see what you see.
Lost keys, without recovery. If you lose your master password and your Emergency Kit and haven’t turned on account recovery, no one can restore your data. If we could restore it, we could also read it. So we cannot.
Someone using your account as you. Anyone who can log in as you also resets your handover clock. Keep your master password and two-factor to yourself.
Gopniya as a whole acting dishonestly. All three staff keys are held by Gopniya staff. No one person can open a handover, but the company together could. The two-person rules, the logs and the custody agreement stand against this. They make it detectable and a breach of contract. They do not make it impossible.
A printed handover, before it is received. From the moment a handover is printed until your nominee receives it, the pages and the drive are not encrypted. They are protected by a sealed, serial-numbered envelope, a custody log and a recorded visit, and by the honesty of the staff who carry them. After the handover, your nominee is responsible for keeping them safe.

Before launch

This page describes the system we’re building. Before we hold anyone’s real data, an independent firm will run a penetration test, and we’ll fix every high and critical finding first.