Key Transparency on iOS¶
Purpose¶
Key Transparency protects call setup from using a substituted peer public key. The server may deliver key data, but the device still verifies that the key is anchored in a signed transparency log before using it for encryption.
KT is not the media encryption layer. It is the identity/key verification layer before the call session key is encrypted for peers.
Business Flow¶
Need to call or invite a peer
-> request peer device keys from KT
-> verify returned proof locally
-> compare verified key set with local trust cache
-> continue, warn, or block depending on flow
What the Device Verifies¶
| Check | Why it matters |
|---|---|
| Requested hash matches returned hash | Prevents the response from being swapped with a valid proof for another key. |
| Checkpoint signature is valid | Prevents a fake log root from being accepted. |
| Key is included in the Merkle path | Proves the key belongs to the signed log snapshot. |
| Recomputed root equals signed root | Detects tampered proof data. |
| Known peer key set is unchanged | Detects device changes or suspicious key injection after first trust. |
Trust Cache Behavior¶
The app stores a verified view of each peer device-key set locally.
| Situation | User impact |
|---|---|
| First verified view | Cache it and continue. |
| Same verified key set | Continue silently. |
| Verified but changed key set | Warn the user before replacing local trust. |
| Invalid proof | Reject the verified-key path. |
This keeps normal calls fast while still surfacing unexpected identity changes.
Runtime Decisions¶
| Flow | Behavior |
|---|---|
| Friend request send/accept | Verify peer key hashes in background and cache valid trust data. |
| Outgoing call | Proof failure can show a warning and continue if the user accepts. |
| Mid-call invite | Requires verified keys; failure blocks the invite. |
| Rejoin host response | Requires a verified requester key before sharing the active call key. |
Important: the verifier itself fails fast, but outgoing call UX currently allows a user override. That is a known security trade-off and should not be described as full fail-closed behavior.
Failure Meaning¶
| Failure | Meaning |
|---|---|
| Hash mismatch | Server returned a key for a different requested identity. |
| Bad proof format | The transparency proof cannot be parsed. |
| Bad checkpoint signature | The signed log snapshot is not trusted. |
| Bad inclusion proof | The key is not proven to be in the signed log snapshot. |
| Invalid encoded field | Required proof/key data is malformed. |
Current Limits¶
| Limit | Current state |
|---|---|
| VRF verification | Performed server-side; the device verifies from the returned hash onward. |
| Outgoing-call override | User can continue after proof failure. |
| Public auditor / safety number | Not available in the app. |
| Consistency proof / rollback detection | Not available in the app. |