TAIA Confidential Screening: protocol specification and threat model

TAIA's own protocol, not a standard, no outside review. This document describes how TAIA Confidential Screening works and what it does and does not protect. It is published under CC BY 4.0; the test-vector script is under the MIT licence, with the Microsoft SEAL and node-seal notices kept.

Version 0.1, 01.11.2026. Legal checked the wording (note 16). Nothing here is an outside review: every security statement below is TAIA's own reading of its own code and of public tables.

Labels: [code] read in the code named above; [live] read in the live parameters; [measured] produced by the test-vector script on 01.11.2026; [repo] stated in a repo README or manifest, not read from the running system; [estimate] reasoning, not a measurement; [open] not settled.

---

1. What the protocol does, in one paragraph

The visitor's browser makes a fresh BFV key for each check, turns the name into one number x and one bin b, encrypts the powers x¹ … x⁹ under that key, and sends the nine ciphertexts to he-svc. he-svc holds the three public sanctions lists as polynomials whose roots are the listed names' numbers. It evaluates every polynomial on the encrypted powers, multiplies each result by a fresh random mask, and returns one ciphertext per polynomial row. Only the browser's key opens them. In the browser, a slot that decrypts to zero at bin b in a list's row means "possible match on that list". The service evaluates every row of every list for every check, the same way whatever the name. [code]

What it does not do [code]: fuzzy matching, transliteration, partial names, dates of birth or other identifiers; the UN list; hiding the list size, the number or time of checks, or the caller's network address; noise flooding (circuit privacy); any check that the answer was computed honestly; an OPRF step. It has had no outside cryptography review.

2. Message flow

Browser (taia.ch/screening/check/)                        he-svc (he.taia.ch, via traefik)
 1. GET /v1/screen/params  ─────────────────────────────▶  public JSON (no name, no key)
 2. GET /v1/screen/quota   ─────────────────────────────▶  {plan, limit, remaining, resets_at}
    [header X-Taia-Access-Key only if the visitor gave one]
 3. normalise(name) → SHA-256 → (bin b, x)                 
 4. fresh key: KeyGenerator → secret key sk
 5. encrypt x^1 … x^9 (same value in all 4096 slots),
    symmetric, seeded; zstd; frame
 6. POST /v1/screen/query  ─────────────────────────────▶  rate bucket → access check → gate slot
    application/octet-stream, ~418 KB                       → read body → size guard → evaluate
                           ◀─────────────────────────────  7 ciphertexts, ~620 KB, + quota headers
 7. decrypt each answer; read slot b;
    list L "possible match" ⇔ some row of L is 0 at b
 8. dispose the key; show the result                       (nothing about the result reaches he-svc)

Step 8 [code]: after decoding, screening-check.js makes no request that depends on the result. Links to the publishers' own search pages are shown for a possible match; following one is the visitor's own request to that publisher.

3. Routes

/v1/screen/query, in order [code]:

1. Free check: one token from the address's bucket (30/min, burst 10; 429 rate_limited + Retry-After).
2. Access check before the body is read: free quota (10 per address per UTC day; 429 free_quota_used), or key (401 unknown_key, 429 key_daily_cap).
3. Keyed check: one token from the key's own bucket (30/min, burst 10; 429 rate_limited).
4. A slot of the pod's gate: 4 running, 8 waiting, free traffic at most 3 + 6 (503 busy, Retry-After: 2).
5. Content type (415), body size (413), framing and ciphertext checks (400 bad_request), evaluation, then the count is taken.

traefik in front [repo, k8s/he-svc/ingressroute.yaml]: 30/min burst 10 per address; free route only: 20 checks per address per 24 h (backstop for he-svc's own 10); at most 4 checks in flight for all clients; 1 MiB body limit. A query string on any route is refused unread (400).

4. Byte layout

4.1 Framing (both directions) [code: pack/unpack]

u32be  count
repeat count times:
  u32be  len      (len ≥ 1)
  len bytes       one SEAL-serialised ciphertext

Nothing may follow the last part. The service accepts count = 9 exactly in a query; the browser accepts up to 256 parts in an answer and requires exactly the number the parameters announce (7).

Request parts are checked against the service's own ciphertext layout before the library reads them (since 2 November 2026).

4.2 One part: a SEAL 4.1 serialisation [code: seal-size.mjs] [measured]

offset size  field
0      2     magic 0xA15E (little-endian bytes 5E A1)
2      1     header size = 16
3      1     SEAL version major = 4
4      1     SEAL version minor = 1
5      1     compression mode = 2 (zstd)
6      2     reserved = 0
8      8     total size of this part, u64 little-endian
16     …     exactly one zstd frame that declares its content size, nothing after it

The service reads the declared inflated size before SEAL sees the part and refuses anything other than this shape, or a declared size above 131,072 bytes (400 with the public body {"error":"bad_request"}; the service's own log records bad_size). SEAL's zstd refuses a frame that inflates past its declared size, so the declared size bounds memory.

The compressed sizes vary by a few hundred bytes from check to check. [estimate] The variation follows the pseudo-random ciphertext coefficients, not the name or the result; an outside reviewer should confirm this.

5. Normalisation cscr-norm-2 [code: normalise()]

Applied identically by the browser and by the list builder, in this order:

1. remove apostrophes ' ’ ‘ ´ ʼ ʻ`;
2. Unicode NFKD;
3. remove combining marks (\p{M});
4. lower case;
5. fold ß→ss æ→ae œ→oe ø→o ł→l đ→d ð→d þ→th ı→i ħ→h ŧ→t;
6. remove apostrophes again (compatibility forms such as ＇);
7. every run of characters that are neither letters (\p{L}) nor digits (\p{N}) becomes one space;
8. split on spaces, drop empty words, sort the words (JavaScript default sort, UTF-16 code-unit order), join with one space.

Consequences: case, accents, punctuation and word order do not change the result; any other difference does (a missing or extra word, another transliteration, a typo). Names in non-Latin scripts are compared as written. An input that is empty after normalisation is refused by the page before any request. Worked examples are in vectors.json → normalisation.

6. Item derivation and binning [code: itemOf()]

D   = UTF-8("taia-confidential-screening-1\n")
h   = SHA-256( D || UTF-8(normalise(name)) )
bin = u32be(h[0..4]) mod B                       B = 4096
x   = ( u32be(h[4..8]) · 2^32 + u32be(h[8..12]) ) mod t      t = 1,032,193
if x = 0 then x = 1

One hash function, no cuckoo hashing. B equals the number of BFV slots (N = 4096), so slot b of every plaintext belongs to bin b. The bias of a 64-bit value reduced mod a 20-bit t is about 2⁻⁴⁴ [estimate].

7. The service's index [code: buildScreeningDB()] [live]

• Lists and order: ofac_sdn (OFAC SDN), eu_fsf (EU consolidated financial-sanctions list), seco (SECO, Switzerland). Each list's primary names and aliases are normalised and stored in data/screening-list/names.tsv with the codes of their lists (O, E, S). he-svc checks the file's sha256 and line count against manifest.json at start-up and stops on a difference. Snapshot at the live read: 74,757 normalised names, sha256 1447ab07d53c32ab7918dafd3965beece3d4bf945f2fae6685ecbb61129d5779; file dates OFAC 28.10.2026, EU 23.10.2026, SECO 29.10.2026.
• Roots: for each list, each name gives (bin, x); equal (bin, x) pairs within one list are one root.
• Rows: a list's worst bin holds L roots; the list gets rows = ceil(L / D) polynomial rows, D = 9. Live: OFAC L = 24 → 3 rows; EU L = 18 → 2; SECO L = 13 → 2; 7 rows in all.
• Polynomials: in row j of bin b, the roots j·D … j·D + D − 1 of that bin, padded to D with the root 0: P_jb(X) = ∏ (X − root) mod t, monic, degree 9. The padding root 0 does not create a match, because x ≠ 0 for every query.

8. Evaluation [code: answerQuery()]

For each list in order, for each row j:

1. Draw a fresh mask vector r_j[b], uniform in [1, t) for every bin, from crypto.getRandomValues (32-bit draws, rejection sampling).
2. For m = 9 … 1: if coefficient m of row j is non-zero in at least one bin, add Enc(x^m) ⊙ encode(r_j[b] · a_jm[b]). Coefficient 9 is 1 in every bin, so the sum always starts.
3. If coefficient 0 is non-zero in some bin, add the plaintext encode(r_j[b] · a_j0[b]).
4. Serialise with zstd.

Only plaintext × ciphertext products and additions; no relinearisation, no Galois or evaluation keys, no modulus switching. Which terms are skipped depends on the lists only, not on the query. In slot b, the answer decrypts to r_j[b] · P_jb(x). t is prime and r ≠ 0, so the slot is 0 exactly when x is a root of that row, and otherwise uniform over [1, t), independent of P_jb(x).

Noise budget left after this work: 21 bits in every answer of the test vectors [measured].

9. Decoding: the match bit and the per-list result [code: clientDecode()]

for each list L in params.answers order:
    hit[L] = false
    for each of its rows:
        ct = next answer part
        if invariantNoiseBudget(ct) ≤ 0: error (nothing is shown as a result)
        slots = decode(decrypt(ct))
        if slots[bin] == 0: hit[L] = true
possible_match_any = OR of hit[L]

The page reads the list set and the row counts from params.lists and params.answers, not from its own constants.

Chance match (a name on none of the lists shows "possible match"): a bin holds at most L distinct roots and x is uniform over t − 1 values, so at most one in ⌊(t − 1)/L⌋ such checks. [live]

Missed match: a listed person or entity whose name the visitor spells differently from every spelling on the list (beyond section 5) gives "no match". "No match" means "this exact normalised spelling is not on these list snapshots", nothing more. This is a property of exact matching, not of the encryption.

10. Parameters

Check of the figures given in the brief (109 total, 72 data level): both match the code. The live endpoint reports only the data level (72) as coeff_modulus_bits. One correction to the wording in R4: the full parameter set (109 bits) is at the HomomorphicEncryption.org Security Standard v1.1, Table 1 bound for N = 4096 with a ternary secret at 128-bit classical security (109 bits), not below it with a margin. The 72-bit figure is the modulus of the ciphertexts he-svc receives; the 109-bit total includes the special prime that only the key-level objects (secret key, public key) use, and they stay in the browser.

Wording proposed for outward text (legal to check): "Our encryption parameters use ring dimension 4096 and a total coefficient modulus of 109 bits, which equals the upper limit of the 128-bit classical security row of the HomomorphicEncryption.org Security Standard v1.1, Table 1, for this ring dimension; the ciphertexts we receive use 72 bits of it. This is our own check against a public table, not an outside review."

Not post-quantum. TAIA does not claim post-quantum security for this protocol. The full 109-bit modulus is above the same standard's post-quantum bound for N = 4096 with a ternary secret (Table 2: 101 bits). Whether the 72-bit level alone supports any post-quantum statement is a question for the outside review; this draft makes no such statement.

Live parameter fields (GET /v1/screen/params, stable names) [live]: protocol, scheme, library, param_class, poly_modulus_degree, plain_modulus, plain_modulus_bits, coeff_modulus_bits, bins, degree, answers[] {list, rows, max_bin_load, names, false_match_one_in}, max_bin_load_any, false_match_one_in_any, normalisation, lists[] {key, label, title, publisher_date, retrieved_at, records, names, source_sha256, attribution, max_bin_load, false_match_one_in}, snapshot_sha256, snapshot_names, free_daily_limit, max_query_bytes.

11. Threat model

The statements below assume the browser runs the page code exactly as TAIA serves it, unless the row says otherwise. "Learns" means: can read or compute from what it receives or stores.

11.1 he-svc (TAIA's service process) and anyone who controls it

Limits of these statements:

• The HMAC tag is a pseudonym, not anonymisation. The IPv4 space is small. Anyone holding the day's secret (the running process, a memory dump of it, or modified code) can recover the address from a tag by enumeration. The tag keeps addresses out of the service's log and metrics; it does not protect them from TAIA's own running code.
• Number of checks per address tag or per key id, per day, is known to the service.
• One check can carry many names. A modified client can place a different name in each of the 4,096 slots and get up to one name per bin answered in one check. The lists are public, so this reveals nothing unpublished, but it counts as one check against the quota (see 11.6, legal).

11.2 A dishonest or compromised service: result integrity

• The page has no way to detect a wrong answer. It checks only the answer count and that each answer still has noise budget. A service that returns Enc(0) in every slot makes every check show "possible match"; one that returns non-zero values makes every check show "no match", including for a listed name. Anyone who can modify the answer in transit after TLS ends (section 11.4) can do the same.
• For a sanctions check, a false "no match" is the material risk. The protocol gives confidentiality of the name, not integrity of the result. This is the same position Microsoft states for APSI ("a confidentiality protocol, not an integrity protocol").
• Chosen answers as a probe. A service can return answers that are zero in a chosen subset of bins and watch for any reaction it can observe. The page sends nothing that depends on the result, and the key is used once, which limits key-recovery-by-reaction attacks to one observation per key. What remains is the person's behaviour after a shown result (checking again with variations, asking for support, buying a plan), which can leak about one bit about the name's bin per check [estimate].
• Decryption failure (a crafted answer with no noise budget left) shows an error to the visitor; the page sends nothing about it.
• Idea for the outside review, not implemented: the client could fill the other 4,095 slots with names whose list status it knows from the public lists (some listed, some not) and check those slots too. A service that does not know which slot is the real one would then be detected when it alters answers in any slot other than the real one. This would turn the "many names per check" property into an integrity check at no extra bandwidth [estimate].

11.3 The page code: delivery by TAIA

• The JavaScript and WebAssembly that do the encryption are served by TAIA (taia.ch, a Google Cloud Storage backend behind Google's load balancer). A modified page could read the name before encryption and send it anywhere, including to TAIA. Homomorphic encryption gives no protection against this.
• At v0.1 there is no Subresource Integrity, no published hash manifest of the page bundle and no reproducible-build record [code: none found in the site's build configuration]. A visitor who wants to check today can read the unbundled source in the repository (once published) and watch the network tab: the only requests are the two GETs and the POST of section 3, and the POST body is binary SEAL data.
• Mitigations that R4 lists for Tier 1 (bundle hash manifest outside TAIA's server, readable code, a "what leaves your browser" panel) are not in place at v0.1 [open].

11.4 The network and the edge

• Between browser and traefik: TLS. An on-path observer without the TLS keys sees the destination host, the time, and the encrypted sizes (~418 KB up, ~620 KB down, which identifies a screening check by its shape).
• traefik terminates TLS for he.taia.ch on normal (non-SEV) nodes and forwards plain HTTP inside the cluster to he-svc. It therefore sees what he-svc sees: ciphertexts, sizes, times, the client's address, the route used (free or keyed) and the request headers. [repo, k8s/traefik/helm-values.yaml] traefik's access log is on (JSON, default fields kept: client address, path, router, sizes, status, duration, start time); request headers are not kept by traefik's default, and Authorization is set to redact. Read live on 01.11.2026 21:42Z: traefik runs with --accesslog=true --accesslog.format=json --accesslog.fields.defaultmode=keep --accesslog.fields.headers.defaultmode=drop --accesslog.fields.headers.names.Authorization=redact [live].
• Linkability: the traefik log (address, time, router) and he-svc's log (time, key id) can be joined by time. For keyed checks, TAIA can therefore link a key id to an address for as long as both logs are kept.
• Retention: container logs go to Google Cloud Logging; the _Default sink writes to the bucket zh-default in europe-west6, which keeps them 30 days [live, 01.11.2026]. A second bucket, he-key-usage (europe-west6), keeps he-svc's keyed-check lines (time, key id, plan; no address) for 396 days for plan accounting [live, 01.11.2026].
• Google Cloud, as the platform operator, can in principle see what traefik and he-svc see. Google's certifications cover Google's infrastructure, not TAIA's code.

11.5 AMD SEV on he-svc's node

• [repo] k8s/he-svc places he-svc on AMD SEV Confidential VM nodes (ComputeClass he-confidential-sev, europe-west6). Plain SEV encrypts the VM's memory against the host (Google's hypervisor and host operators). It does not protect against TAIA's own code in the pod, a new image TAIA deploys, anyone with cluster administration rights (kubectl exec, a debug container), or traefik, which runs on normal nodes.
• The badge on the page says "per GKE's node label, checked HH:MM UTC": it relies on the node label, not on an attestation the browser checks. The pod has no attestation token and no egress.
• For this protocol, SEV adds protection for the transient address, the HMAC secret, the masks and the index in memory against the host. It does not change any statement in 11.1–11.3.
• The SEV node class is applied: he-svc runs on a node labelled cloud.google.com/gke-confidential-nodes-instance-type=SEV (ComputeClass he-confidential-sev), image develop 6c39683d4 @ sha256:ad33e3fd… on node …bdcm [live, 02.11.2026 06:40Z]. The label is GKE's statement, not a hardware attestation.

11.6 Summary table

12. Test vectors

Folder: screening-test-vectors/ beside this file.

Determinism. node-seal 7.0.0 has no seed parameter. Its only entropy source is the Emscripten randomFill, which calls crypto.getRandomValues; the service's masks use the same function. The script replaces globalThis.crypto.getRandomValues with SHA-256 in counter mode over (seed, stream label, counter), with separate streams client/<case> and server/<case>. Seed (hex): 7461696120636f6e666964656e7469616c2073637265656e696e672074762031. The client stream drew 4,816–4,944 bytes per case (key generation and encryption), the server stream 114,688 bytes (7 rows × 4,096 slots × 4 bytes). The live page and service do not do this; it exists only in the test script.

Cases [measured]

Case 2 shows the per-list result: SECO lists the name as "Bank Melli PLC", whose normalised form differs. The vectors use entities only, no natural persons.

Reproducibility [measured, 01.11.2026, Node v22.13.1, node-seal 7.0.0]: generate was run twice into separate folders; diff -r found no difference, and the published folder equals the first run. verify then passed 26 of 26 checks: all sha256 sums; the parameters; for each case, the stored key opens the stored answer with the stored result (this check does not depend on the seed), the service's answer recomputed from the stored query is byte-identical, and the key, query and full run regenerated from the seed are byte-identical.

54f86b2de5ecc88a1029d26fb2198271dfce2bd34fbdde8649240398f29a6063  case-1-match-all.answer.bin
1584ccd9d25afb6d7711a0da8d3f2ea0f714b6f28647ede442d640a0b1f847f8  case-1-match-all.query.bin
6c0a222aac482770cfd0015ed38aa0e9ca3692a433f2233496af528d04e3d07c  case-1-match-all.secret-key.bin
416e5412faa4f1a790ab362d2c0d9e4d1481396405cdfc9d8600d6a50a0375b0  case-2-match-some.answer.bin
24eeb333e4f7720e303c6cfd517c2e8495211440bb5adacd3ff646c3b33d35c1  case-2-match-some.query.bin
9ad17ea932043f34809e69b01f14c568a60827c859ad75229ca1d4766334eb58  case-2-match-some.secret-key.bin
0745c59300ff7fa315c6e30f56ccdff1f25869e5db6760fd76f549870b7f787b  case-3-no-match.answer.bin
a55741f06d9d0f84bffc21ac5639e40367ed44af86cc4d54d0e98d3cda85c3f8  case-3-no-match.query.bin
7cc4dc2cbb2929518e25bf5b6ace9162b268fc361afc92fda9a094c75af31bc0  case-3-no-match.secret-key.bin
1aac0ddeeae3a8a0b86b2fbaf2906f2e30cbef94d00ed5352039732b5f3651d4  vectors.json
make-vectors.mjs: 4384cb835a01455fa107394e757c6cf0860f90237303353d556d59c069e73985

Re-run:

git archive <commit> services/he-svc | tar -x -C <dir>
cd <dir>/services/he-svc && npm ci
node --experimental-wasm-exnref make-vectors.mjs generate --he-svc <dir>/services/he-svc --out <out>
node --experimental-wasm-exnref make-vectors.mjs verify   --he-svc <dir>/services/he-svc --vectors <folder>

The vectors depend on the list snapshot (snapshot_sha256 in vectors.json): a new weekly list build changes answer.bin and may change the rows; a protocol, normalisation or parameter change also changes query.bin. Byte equality across other Node or node-seal versions has not been tested [open]. A query file is a valid request to the live service with the same snapshot; the answer would differ in bytes (fresh masks) but open to the same result with the stored key. That was not done for this draft (one live call was allowed: the parameters).

13. Versioning, changelog, contact

Version rules (proposal).

• protocol id changes (…-2) when the item derivation, the framing, the evaluation or the answer layout rule changes.
• normalisation id changes (cscr-norm-3) when any step in section 5 changes; the list is rebuilt.
• param_class changes when N, t, the coefficient modulus or D changes.
• A list refresh changes only snapshot_sha256 and the per-list fields; it is not a protocol version.
• This document's version follows MAJOR.MINOR; each published version names the code commit and the live-read time it describes.

Changelog.

Contact.

• Security reports: [security contact address: to be set; security.txt not yet published]
• Questions about this document: [contact: to be set]
• Outside review: [reviewer, date and report link: none yet]

14. Points for the legal seat

1. Integrity (11.2): the page shows "no match" without any proof the answer was computed honestly. How the terms and the page describe the result, and who carries the risk of a false "no match".
2. Page delivery (11.3): "the service does not receive the name" holds only for the page code as TAIA serves it. The current page and terms text should say so in the same sentence as the privacy statement.
3. Address and logs (11.1, 11.4): traefik logs the client address with time and route; he-svc logs key id with time; these can be joined. The 30-day retention and the existing 396-day key-id bucket (time, key id, plan; no address) must match the privacy notice.
4. HMAC wording: "pseudonymised", not "anonymised"; reversible by enumeration while the day's secret exists.
5. Many names per check (11.1): a modified client can screen up to 4,096 names in one paid check. Terms and pricing question, not a privacy one.
6. SEV (11.5): "protected from Google's host", not "protected from TAIA"; the badge relies on a node label, not attestation.
7. Parameters (10): the 109-bit total is at the table's bound, not below it; no post-quantum statement.
8. "No match" meaning (9): exact normalised spelling against dated list snapshots; the chance-match figure; missed matches on spelling variants.

15. Open questions

1. Live state not read for this draft: the live image commit, traefik's live access-log fields and log retention, and whether the SEV node class is applied.
2. Ternary secret and error width in this exact SEAL build (defaults assumed, not inspected).
3. Whether the compressed-size variation (4.2) carries any information; for the outside reviewer.
4. Byte reproducibility of the vectors on other Node, node-seal or CPU combinations.
5. Whether the canary-slot idea (11.2) should be built before the outside review, so the review covers it.
6. Where the spec, script and vectors are to be published (repository, taia.ch path) and under which licence.

Markdown