Implements the 3-tier key model from the multi-person sharing ADR:
each account owns multiple profiles (a person or pet — a 'subject of
care'), and each profile has its own random AES-256-GCM DEK. All
health data is now encrypted under the active profile's DEK, not the
account-wide DEK. The account DEK wraps each profile DEK; the server
stores only opaque wrapped blobs.
Per the ADR: DB wipe, no migration (no real user data). This unblocks
Phase B (sharing) — there is now a per-profile key to wrap to a
recipient's X25519 public key.
Backend:
- Profile model: owner_account_id, kind (human/pet), relationship,
wrapped_profile_dek + iv. ProfileRepository gains find_all_by_owner,
find_by_profile_id_owned, update_profile, delete_profile — all
ownership-scoped.
- Profile handlers: GET/POST /api/profiles, GET/PUT/DELETE
/api/profiles/:id. Removed /api/profiles/me. Renamed users.rs
get_profile/update_profile (the /api/users/me handlers) to
get_account/update_account to resolve a name collision.
- Register accepts default_profile_* fields and auto-creates the self
profile when the client provides a wrapped profile DEK.
- HealthStatistic + Appointment gain profile_id and ?profile_id=
filtering (health stats previously had no profile binding).
- New profile_tests.rs: multi-profile CRUD + ownership isolation +
register-with-default-profile. Fixed the zk health-stat test to
send the now-required profile_id.
Frontend:
- crypto/keys.ts: generateProfileDek, wrapProfileDek, unwrapProfileDek
+ in-memory per-profile DEK store with an active-profile concept.
- useProfileStore rewritten: holds profiles[], activeProfileId;
loadProfiles unwraps each profile DEK; create/update/delete. All 11
encrypt/decrypt sites switched from getEncKey() to
getActiveProfileDek(). load actions pass ?profile_id= so only the
active profile's rows come back.
- ProfileEditor rewritten for the new store (edit active profile,
create/delete). New ProfileSwitcher in the Dashboard AppBar.
- MedicationManager / AppointmentsManager use the active profile id
instead of the hardcoded profile_<user_id>.
- 2 new crypto tests for per-profile DEK isolation; updated store +
component tests for the active-profile-DEK model.
Verification: backend cargo build/clippy/fmt green, tests compile
(integration tests run in CI — Mongo is fixed there). Frontend
tsc clean, 30/30 tests pass.
Closes nothing yet (Phase B/C/D remain). Refs #3.
Phase A1 of the multi-person sharing ADR
(docs/adr/multi-person-sharing.md). Each account now gets an X25519
keypair at registration: the public half stored plaintext, the private
half wrapped under the account DEK and stored as opaque ciphertext. The
keypair is generated client-side; the backend adds no crypto deps and
stores everything verbatim, preserving the zero-knowledge contract.
This change only introduces the keypair and threads it through the auth
flows — it is not consumed yet. It unblocks Phase B (profile sharing)
without touching the data model or the ~11 frontend encrypt call sites,
which is Phase A2 (per-profile DEKs).
Backend:
- User model: identity_public_key, identity_private_key_wrapped{,_iv}
(all Option<String>, backward compatible).
- RegisterRequest/AuthResponse carry the 3 fields; register + login
echo them. No changes to change_password/recover (DEK value is
unchanged across both, so the wrapped private key is too).
- 2 new integration tests: round-trip through register/login, and
optional-fields backward compat.
Frontend:
- crypto/keys.ts: generateIdentityKeyPair, wrapIdentityPrivateKey,
unwrapIdentityPrivateKey + in-memory identity store mirroring the DEK.
- types/api.ts: AuthTokens + RegisterRequest extended (removes an
existing `as any` cast).
- useStore register/login/logout + UnlockPage unwrap the private key
alongside the DEK.
- 3 new crypto tests (X25519 lifecycle, wrong-DEK rejection, distinct
shared secrets); skip gracefully where the runtime lacks X25519.
Backend: cargo test + clippy green. Frontend: npm test + tsc green.
Also gitignore .zcode/ (local tooling artifact).
Rate limiting (closes the last security gap #3):
- New RateLimiter: in-memory fixed-window IP-based limiter (std::sync::Mutex
HashMap, no new deps). Configurable via RATE_LIMIT_MAX (default 100) +
RATE_LIMIT_WINDOW_SECS (default 60) env vars.
- general_rate_limit_middleware now reads ClientIp from request extensions and
rejects with 429 + Retry-After header when over the limit. Wired via
from_fn_with_state in app.rs. Lived on AppState as Arc<RateLimiter>.
- Deleted the dead auth_rate_limit_middleware (never wired).
- 3 unit tests (allows up to N, independent IPs, window reset).
E2E crypto lifecycle test:
- Full zero-knowledge round-trip against jsdom's real Web Crypto: setup →
encrypt → verify ciphertext → unlock with password → decrypt → recover via
phrase → rewrap under new password → decrypt. Plus wrong-password/wrong-phrase
failures and cross-user key isolation.
- Fixed wrapDek/unwrapDek: base64-encode raw DEK bytes (was using TextDecoder
which produced non-base64), and make unwrapped DEK extractable (needed for
rewrapDek to export).
Verified: backend 24 tests 0 warnings; frontend 24 tests, build clean.
