Hi, T.J. Duchene wroye: > Whether you believe me or not, think me paranoid,
I got mistrusting, too. > makemkv forum why they > get key revocation warnings even when using Linux Trying to grok their complaints and proposals ... (well, yes kids, a medium error is indeed bad) ... They talk of keydb.cfg (clearly a disk file) and quote the program "most likely current AACS host certificate is revoked by your drive". Also its about "vid", "vuk". (whut ?) Since this all stays a bit obscure, how about this summary statement: Be aware that inserting a commercial Blu-ray video disc into the drive can have undesired effects on the overall video decoding and display system. (This does not affect the use of the BD drive with self-burned BD media.) --------------------------------------------------------- I tried to get a grip on the math: AACS can target an individual player not by modifying its firmware but rather by invalidating its decryption keys for all newly produced BD-ROM media. (Now wondering how many players they can blacklist by cutting off their access path to the actual decryption key ... and whether one can steal that key, when found.) The used player keys cannot but identify themselves in the video output stream by decrypting slightly different versions of the video. (Well, one could postprocess the video in order to deceive Sony's recognizer.) So if a cracked video shows up, Sony can revoke the player key, and the newly released videos are safe from it. At some number of revoked keys, i'd expect that more and more collateral damage is done to valid uncompromised player keys. That's because the number of possible combinations of revoked keys grows very rapidly if the number of revoked keys grows. Dirichlet's socks drawer (or somebody else's pigeon holes) tells that there must be collisions as soon as the number of combinations exceeds the number of media keys. Well, actually already at the square root of that number, according to the birthday paradox. So this protection depends on the assumption that it is quite hard to crack a player. Somebody who can crack many players and release a video from each could topple the global revocation system. A million suicidal BD players could suffice, crying "Kill me, Sony. Kill me." while Sony runs out of bullets. According to https://en.wikipedia.org/wiki/Advanced_Access_Content_System AACS is even weaker than this contraint, because the number of collaterally affected keys would depend on the depth of the common ancestor of the compromised ones in the key tree: "to revoke a given device key, the MKB needs only be encrypted with that device key's parent key." The higher parents have lots of innocent children. So each key revocation grows the sub tree of player keys which are excluded from viewing new video Blu-rays. The individual remedy for an innocent victim would then be to get a new firmware for the drive with a new key which is not in the affected sub tree. If the global system is flexible, then one would probably get a reshuffled key tree where the compromised ones are consolidated in a small sub tree. But it already has to be cryptic. So many reshufflings will not uphold the property that a key cannot learn about its ancestors in the tree. In this theory, players like AnyDVD and makemkv keep compromised keys (e.g in file keydb.cfg) and their warnings tell that the currently used compromised key is not of use with the given video. I.e. one needs to get new compromised player keys, which were harvested after the given video disc was pressed. --------------------------------------------------------- Have a nice day :) Thomas
