fix(vaults): verify vault content keys per KID from the fragment map

Map each KID to its fragments from the ciphertext moov/moof (tenc, seig, ISM duration clock) and decode up to three windows per KID that never cross into another KID, so a clear lead cannot hide a wrong key and only the failing KID is flagged. Decode every frame (wrong-key HEVC keyframes decode clean), re-judge mid-GOP starts on keyframes, time out every FFmpeg run, and refuse to store a flagged pair again in SQLite.
This commit is contained in:
imSp4rky
2026-09-18 01:10:14 -06:00
parent cf2906f120
commit b30e6d7cbe
10 changed files with 921 additions and 41 deletions
+6 -4
View File
@@ -40,10 +40,12 @@ key_vaults:
stores it.
!!! note "Bad content keys"
A content key from a vault is proven by a short FFmpeg decode of the decrypted output.
A content key that fails the decode is written to the `bad_keys` table of every `SQLite`
vault with the name of the vault that supplied it, and every vault lookup skips a flagged
pair from then on. Only the `SQLite` backend stores flags. A `serve` instance with
A content key from a vault is proven by short FFmpeg decodes of the decrypted output,
with windows inside the fragments of each KID in a fragmented MP4. A content key that
fails the decode is written to the `bad_keys` table of every `SQLite` vault with the name
of the vault that supplied it, and every vault lookup skips a flagged pair from then on. A `SQLite` vault also refuses to
store a flagged pair again. Only the `SQLite` backend stores flags; an `API` vault that
supplied the pair gets a report. A `serve` instance with
`server_cdm` flags a pair the same way when a remote client reports it, so a server whose
`key_vaults` hold no `SQLite` entry cannot remember a bad content key.