Joripo- Home
- Documentation
- Security and privacy
- Encryption at rest
Security and privacy
Encryption at rest
What Joripo seals on the server's disk and in its database, what it leaves plain and why, how it is switched on, and what it does not protect.
Joripo documentation · https://joripo.com/docs/security-and-privacy/encryption-at-rest
On this page
Encryption at rest seals collected data on the server's disk and in its database with AES-256-GCM, so that a copy of the disk or of the database, or a stolen backup, is unreadable without the server's data key. It is built into Joripo, and off until whoever runs the server sets a data key. Server administration › Server health says whether it is on and whether everything stored has been sealed.
Ask whoever runs your server whether it is on. A server without a data key stores collected data unencrypted on its disk, and its Server health warns about it. Encryption at rest protects the disk and the backups; it does not change who can see data in the console, which roles and identity access decide.
What is sealed
| Data | Sealed |
|---|---|
| Submissions: the XML, photos, audio, video, signatures, text audits | Yes |
| Differing copies of a re-sent submission | Yes |
| A submission's review and corrections | Yes |
| Every submission's answers in the database | Yes |
| Server datasets (preload data, case lists) | Yes |
| Beneficiary lists waiting in the case set-up wizard | Yes |
| Case notes | Yes |
| The tester's saved sessions (the answers typed so far) | Yes |
| Purge backups and storage-migration backups | Yes, sealed whole |
| The server's own backups | Each file goes in as stored, so sealed data stays sealed |
What is not sealed, and why
| Data | Why it stays plain |
|---|---|
| Form media: a form's attachments, including preload CSV files copied from a dataset | They are sent to every phone that downloads the form, and the phones' manifest depends on them as stored. A preload file holding names or phone numbers is therefore readable on the server's disk by anyone with the disk. Keep preloads to the columns the form needs; the server dataset they come from is sealed, and can be marked identifying. |
| Form definitions (workbooks and XForms) | They hold questions, not answers. |
| Each submission's bookkeeping (when and how it arrived, who sent it, file checksums) | It holds no answers, and the index is rebuilt from it. |
| People, passwords (already hashed), phones, plans, settings | They are not collected data; passwords are stored only as hashes. |
| Backups made before the key was set | They hold plaintext. Server health names them, and they are removed automatically once a backup sealed with the key has been verified. Copies you downloaded before then stay plaintext: delete them. |
Keys
- The data key is given to the server in its environment or a key file, never in the data folder or the code. A key stored with the backups would protect nothing.
- At every start the server checks that its keys open what it sealed before, and refuses to start if they do not, so a mistyped key never produces data under two keys.
- Keep a copy of the key offline, apart from the backups. Without it, sealed data and sealed backups cannot be read by anyone, Joripo's team included.
- Keys can be rotated: the new key seals from then on, a background pass re-seals what is stored, and the old key is kept until no backup needs it.
Switching it on for data already stored
When a key is set on a server that already holds data, new data is sealed at once, and a sealing pass runs in the background over everything stored. Each file is sealed into a temporary copy, the copy is opened and compared with the original, and only then put in its place; the pass can be stopped at any point and resumes at the next start. Server health says "everything stored was sealed" only when the last pass found nothing plain, and otherwise counts what is left. See Keys and secrets.
What it does not protect
- What people can see in the console. Anyone who may open data in the console sees it as before; downloads are opened for them as they are sent.
- The phone. Joripo Collect keeps unsent interviews in the app's private storage, protected by Android's own file encryption rather than by a key of the app's own (the device keys themselves are sealed with Android's Keystore). A rooted phone could expose unsent interviews.
- Joripo Desktop's copy. A study folder on a computer is ordinary files; keep it on an encrypted disk.
- Exports you download. Once a file leaves the server it is yours to protect.
- Form encryption with a public key (end-to-end encryption of a form's submissions) is a different thing, and is not built: such forms are refused rather than stored in the clear.
What has and has not been verified
Sealing, opening, rotation, the sealing pass, the index rebuild from a sealed tree and the backup-and-restore runbook are covered by automated tests, and the release was run end to end with encryption on (sign-in, sync, export). These were verified on the test database (SQLite); the newest database paths have not yet been run on a production Postgres. Whether a particular hosted server has its key set is a fact about that server, not about the software: check its Server health.