Add key hierarchy analysis, update all docs with WASM/auth/native messaging findingsHEADmain

New document:
- key-hierarchy.md: Full key derivation model, MUK lifecycle, SRP auth,
  biometric unlock, Duo MFA, dSecret bypass, delegated sessions, password
  timebox mechanism, crypto algorithm inventory

Major updates:
- architecture.md: Expanded WASM section with confirmed 80+ rA.* methods,
  clarified WASM is portability layer not security boundary
- trust-boundaries.md: Corrected Zone A (keys in JS heap not just WASM),
  Zone D (confirmed native messaging protocol with biometry messages),
  Zone F (WASM is NOT a privilege boundary), detailed sensitive data table
  with confirmed storage locations, new Critical attack surface category
- message-catalog.md: Added native messaging protocol (biometry save/unlock/
  remove, availability check), desktop connection messages, server notification
  events
- TODO.md: Marked completed items, added key material exposure assessment
  section, authentication & session security section

1 files changed, 36 insertions, 10 deletions

diff --git a/TODO.md b/TODO.md
index 751f9ad..7d4eec6 100644
--- a/TODO.md
+++ b/TODO.md
@@ -2,6 +2,18 @@
 
 ## High Priority
 
+### Key Material Exposure Assessment
+- [x] Map where MUK lives — **JS heap as exportable JWK, entire unlocked session. Documented in key-hierarchy.md.**
+- [x] Map where SRP-X lives — **JS heap on CTX.session.auth.srpX. Documented in key-hierarchy.md.**
+- [x] Trace biometry save flow — **MUK + SRP-X serialized as JSON, sent via native messaging. Documented in key-hierarchy.md.**
+- [x] Trace re-auth flow — **MUK + Secret Key + SRP-X used for silent re-auth on 401. No user interaction. Documented in key-hierarchy.md.**
+- [x] Trace master password lifecycle — **5-min timebox in closure, set on CTX.user.password temporarily during sign-in then cleared. Documented in key-hierarchy.md.**
+- [ ] Determine if the `Rv` (client) class ever explicitly clears the MUK reference on lock (beyond `_dangerousInnerCTX = undefined`)
+- [ ] Check if `rA.onLock` triggers WASM-side key zeroing
+- [ ] Trace what happens to content-script-side decrypted values after fill completes — are they GC'd promptly?
+- [ ] Check if the 5-minute password timebox can be extended by repeated Duo attempts
+- [ ] Determine if `lessSafeOpenNaCl` has any key exposure implications
+
 ### Deep Reverse Engineering of background.js
 - [ ] Beautify/pretty-print the 2.9MB background.js for readable analysis
 - [ ] Map all `m5({...})` handler implementations — trace what each handler does after receiving a message
@@ -10,11 +22,12 @@
 - [ ] Trace the `VA()` function used for broadcasting events to tabs
 
 ### Native Messaging Protocol
-- [ ] Identify the native app ID used with `chrome.runtime.sendNativeMessage`
-- [ ] Map the command/response schema for native messaging
-- [ ] Determine what operations are delegated to the native app vs handled in-extension
-- [ ] Analyze the 6 localhost ports (12519, 40978, 52115, 22287, 60685, 22322) — what protocol, what data
+- [x] Identify the native app ID used with `chrome.runtime.sendNativeMessage` — **empty string `""`**, Firefox routes via `applications.gecko.id`
+- [x] Map the command/response schema for native messaging — **JSON envelope `{name: "core", data: JSON.stringify({type, data})}`, Biometry messages documented in message-catalog.md**
+- [x] Determine what operations are delegated to the native app vs handled in-extension — **Biometry (save/unlock/remove MUK+SRP-X), biometry availability, dSecret proxy, device trust signing, desktop connection state**
+- [ ] Analyze the 6 localhost ports (12519, 40978, 52115, 22287, 60685, 22322) — what protocol, what data. Are these the same native bridge or separate services?
 - [ ] Check if localhost connections use any authentication/signing
+- [ ] Determine if the native messaging JSON carries any MAC/signature on the MUK payload
 
 ### Frame Relay Security
 - [ ] Trace `relay-message-to-frames` handler (`eij`) — does it validate sender frame? Does it restrict what messages can be relayed?
@@ -36,11 +49,13 @@
 ## Medium Priority
 
 ### WASM Module Analysis
-- [ ] Analyze exported functions from `op_wasm_b5x_bg` — what crypto primitives are exposed to JS?
-- [ ] Determine if key material ever crosses the WASM→JS boundary in plaintext
+- [x] Analyze exported functions from `op_wasm_b5x_bg` — **80+ methods documented in architecture.md `rA.*` interface table**
+- [x] Determine if key material ever crosses the WASM→JS boundary in plaintext — **YES. MUK exported as JWK, SRP-X cached in JS, decrypted passwords returned to JS for fill. Documented in key-hierarchy.md.**
 - [ ] Check `confidential_computing_bg` — what confidential computing features are used and where?
-- [ ] Analyze `b5_mycelium_bg` — is this the Mycelium relay for remote autofill? What's the protocol?
-- [ ] Map HPKE usage — what is encrypted with HPKE vs AES-GCM vs RSA-OAEP?
+- [x] Analyze `b5_mycelium_bg` — **confirmed as P2P relay for remote autofill. Noise-protocol-like handshake with `wasmpairingsession*` and `wasmsetuptransportsession*` exports.**
+- [ ] Map HPKE usage — what is encrypted with HPKE vs AES-GCM vs RSA-OAEP? (`wasmsealed_*` exports use HPKE)
+- [ ] Analyze the `b5_trustlog_bg` trust log entries — what operations are logged? (`wasmtrustlogclient_create_add_users_entry`, `_remove_users_entry`, `_add_groups_entry`, etc.)
+- [ ] Determine how vault keys are managed inside WASM — are they ever exposed to JS or only used internally?
 
 ### External Extension Messaging
 - [ ] Trace all 3 `onMessageExternal` handler registrations
@@ -55,10 +70,11 @@
 - [ ] Analyze `chunk-PQH6ALAA.js` (156KB)
 
 ### Credential Fill Path
-- [ ] Trace the fill flow: background resolves item → decrypts → sends to content script → injects into DOM
-- [ ] Identify where decrypted password/OTP/card values exist in JS memory and for how long
+- [x] Trace the fill flow: **background calls `rA.fillItem`/`rA.startFillSession` → WASM decrypts → plaintext returned to JS → `chrome.tabs.sendMessage` → content script → DOM injection**
+- [x] Identify where decrypted password/OTP/card values exist in JS memory — **JS heap in background (from WASM return), JS heap in content script (from sendMessage), DOM (after fill). No explicit zeroing.**
 - [ ] Check if clipboard operations (`clipboardWrite`) properly clear after timeout
 - [ ] Analyze `fill-generated-password` flow — is the generated password ever in plaintext outside WASM?
+- [ ] Determine how long decrypted values remain reachable in JS (fill session lifecycle)
 
 ### Partner Integration Data Minimization
 - [ ] Privacy.com: what data is sent to `api.privacy.com`? Card params, user identity?
@@ -67,6 +83,16 @@
 - [ ] Kolide: what health/device data is shared? Analyze `kolide.js` (60KB)
 - [ ] Trelica: what app catalog data is exchanged?
 
+### Authentication & Session Security
+- [ ] Trace the full SRP exchange — what SRP method/group is used? (SrpMethod, SrpMethodPrefix constants)
+- [ ] Determine if transport tokens provide replay protection
+- [ ] Analyze the delegated session mechanism — can a compromised context delegate to others?
+- [ ] Check if `safeSignOutClient` properly clears all key material (it sets `_srpX = undefined`, `_dangerousInnerCTX = undefined`)
+- [ ] Trace the `invalidate` flow — does invalidation zero keys or just remove references?
+- [ ] Analyze the offline MFA account tracking (`offline-mfa-accounts` in localStorage) — security of this state
+- [ ] Check if the Duo code extraction from URL (`duo_code` parameter) is vulnerable to URL injection
+- [ ] Determine if `CTX.getTransportToken()` exposes session-equivalent tokens
+
 ### Secure Remote Autofill (director.ai)
 - [ ] Analyze `secure-remote-autofill-start-pairing.js` (57KB) — pairing protocol
 - [ ] Analyze `secure-remote-autofill-complete-pairing.js` (59KB) — completion flow