LibreDrive and Encryption?

[My1xT]

I read the what is LibreDrive thread but one question that I still dont exactly understand is, that is the issue of Encryption, or specifically how older MakeMKV versions are able to decrypt newer discs.

As far as I have read LibreDrive primarily deals with the Bluray Drive's refusal to read certain areas unless you present a proper key to it, which helps access all the data on the Bluray, but isn't it still encrypted or are player keys just used for policing what can be read? because I would be assuming that the disc is encrypted with not just a single, by now well known keys (I mean even CSS did have multiple key encryption already)

like if MakeMKV only has keys for say AACS1/v78 but you have and AACS1/v80 disc, how would having Libre Drive and being able to raw-read the disc allow MakeMKV to decrypt it, I mean unlike with CSS which had joke cryptography, AACS actually uses AES, which STILL is the go-to for symmetric crypto with 128-bit keys, so you should not be able to trivially brute force them even now.

[ryley]

I read the what is LibreDrive thread but one question that I still dont exactly understand is, that is the issue of Encryption, or specifically how older MakeMKV versions are able to decrypt newer discs.

As far as I have read LibreDrive primarily deals with the Bluray Drive's refusal to read certain areas unless you present a proper key to it, which helps access all the data on the Bluray, but isn't it still encrypted or are player keys just used for policing what can be read? because I would be assuming that the disc is encrypted with not just a single, by now well known keys (I mean even CSS did have multiple key encryption already)

The distinction between being able to back up and decrypt a disc is important.

Backup: Cloning a disc sector by sector and storing all associated disc metadata
Decrypt: Removing all protection so that the AV content can be freely played/converted/streamed etc

There are two distinct "layers" of encryption for bus encryption enabled (BEE) Blu-ray discs. Both layers apply to certain AACS1 discs but all AACS2 discs.

The first layer is bus encryption. Bus encryption is applied only to disc sectors which correspond to AACS protected content. The read data key (RDK) used for bus encryption is derived from the drives AACS private key and the discs "volume ID" (VID). Licensed players can retrieve the RDK for a particular title by performing the AACS authentication process. This requires the host to have a valid, non-revoked AACS host certificate and private key. Historically the host certificates used by unlicensed tools were identified and revoked reasonably quickly.

It is important to remember that the drive will not refuse to read sectors flagged for bus encryption but they will be encrypted for BEE AACS1/AACS2 discs.

LibreDrive mitigates the need for a valid AACS host certificate & private key by disabling bus encryption and permanently allowing retrieval of protected disc metadata such as the VID. This means discs can always be backed up by MakeMKV but it doesn't mean they can always be decrypted.

like if MakeMKV only has keys for say AACS1/v78 but you have and AACS1/v80 disc, how would having Libre Drive and being able to raw-read the disc allow MakeMKV to decrypt it, I mean unlike with CSS which had joke cryptography, AACS actually uses AES, which STILL is the go-to for symmetric crypto with 128-bit keys, so you should not be able to trivially brute force them even now.

This is where the second layer of encryption comes into play.

You are absolutely correct that LibreDrive alone would not allow for decryption of titles using a newer/unsupported MKB version. This exact scenario plays out whenever a user tries to decrypt a UHD disc not supported by either the public keydb or MakeMKV's hashed keys. The need for dump files could also occur for AACS1 titles if the keys embedded in MakeMKV were revoked in the future.

[My1xT]

okay but is an encrypted backup that basically just floats there without any thing being able to be done with it useful for anything? I'd assume that generally when backing up you'd make a decrypted one that you can actually use, or as the program's own name implies, make an MKV for easy playback, which likewise needs decryption.

[Coopervid]

okay but is an encrypted backup that basically just floats there without any thing being able to be done with it useful for anything? I'd assume that generally when backing up you'd make a decrypted one that you can actually use, or as the program's own name implies, make an MKV for easy playback, which likewise needs decryption.

An encrypted backup can be used later to be decrypted when a key is available either by Makemkv itself or when a VUK is in the keydb.cfg database. But the encrypted backup must be done with bus encryption defeated. You can't just do a encrypted backup using Windows explorer and just copy the files because the first encryption part (bus encryption) must be removed.

[My1xT]

so if I understand it correctly the bus encryption isnt a thing done to the bluray disc itself that the drive decrypts if allowed but rather just encrypts but software that is allowed can also get a copy of the key and libredrive just skips that entirely?

if the bus encryption is done on the fly anyway, why would the bus encryption key be based on a private key and the VID anyway (and where's the public key in the equation) wouldnt it be more secure to just encrypt it with a random key generated each time a disc is inserted and providing players with that?

[Coopervid]

No. Bus encryption is negotiated between the drive and the computer. Not the disc. Libredrive takes bus encryption out of the chain and then there is only AACS encryption between the disc and the computer left. Does that make sense to you?

[MrPenguin]

if the bus encryption is done on the fly anyway, why would the bus encryption key be based on a private key and the VID anyway (and where's the public key in the equation) wouldnt it be more secure to just encrypt it with a random key generated each time a disc is inserted and providing players with that?

AACS uses the AES encryption algorithm, for which you use the same key for both encryption and decryption. The "on the fly" bus-encryption key is called the "Read Device Key" (RDK). The RDK is calculated by encrypting the disk's VID using a secret key buried inside the drive, and every drive has its own such secret key. The end result is that every (disk, drive) combination has its own unique RDK, and this key is stable.

Personally, I'm very happy that these RDKs are stable.

[My1xT]

if the bus encryption is done on the fly anyway, why would the bus encryption key be based on a private key and the VID anyway (and where's the public key in the equation) wouldnt it be more secure to just encrypt it with a random key generated each time a disc is inserted and providing players with that?

AACS uses the AES encryption algorithm, for which you use the same key for both encryption and decryption. The "on the fly" bus-encryption key is called the "Read Device Key" (RDK). The RDK is calculated by encrypting the disk's VID using a secret key buried inside the drive, and every drive has its own such secret key. The end result is that every (disk, drive) combination has its own unique RDK, and this key is stable.

Personally, I'm very happy that these RDKs are stable.

sure AES is symmetical, but why even use a derived key in the first place if it's only for on the fly? couldnt depending on the specific way the drive makes the RDK the that secret key be exposed?

why not just make a random one each time you put a disc in a drive? or is there a need for a disc/drive combination having the key stable?

[MrPenguin]

why not just make a random one each time you put a disc in a drive? or is there a need for a disc/drive combination having the key stable?

I didn't design AACS, and have no problem with being able to cache each drive's set of RDKs . It's actually useful to be able to obtain the RDK for a drive/disk pair, knowing that such an encryption key won't be lost forever whenever a drive is power-cycled or its disk ejected.

[keydb_helper]

sure AES is symmetical, but why even use a derived key in the first place if it's only for on the fly? couldnt depending on the specific way the drive makes the RDK the that secret key be exposed?

why not just make a random one each time you put a disc in a drive? or is there a need for a disc/drive combination having the key stable?

If I had to guess, I'd say the AACS designers back in 2003-2005 may have had concerns about the lack of entropy and difficulty in generating secure random numbers in embedded systems such as the SoC of a Blu-ray drive.

It is absolutely possible to retrieve the drive private key and drive seed for certain drive platforms. This allows for a permanent bypass of both AACS 1.0 and 2.0 bus encryption by allowing for offline RDK calculation and can even allow for UHD playback on otherwise "hostile" firmware combinations.

[ryley]

why not just make a random one each time you put a disc in a drive? or is there a need for a disc/drive combination having the key stable?

I know it sounds contrived but key stability may have been beneficial if trying to avoid issues with drives/hosts caching stale data after updating the RDK. Otherwise I can't think of another obvious reason.

It is important to remember that the first generation of Blu-ray drives didn't support bus encryption at all. So given that there was already a permanent workaround for backing up BEE AACS1 titles, I'm sure a more dynamic RDK system wasn't the absolute highest priority.