GitLab

While working on bus encryption I've found out that some drives (if
not all) require a new AACS-Auth for reading data keys. It seems that
the same goes for reading PMSN. After digging through my discs I've
finally found one with PMSN and I was able to verify this with two LG
drives. Fix it by moving PMSN reading to a separate function with a
new AACS-Auth.

aacs_open2() returns aacs handle even if disc can not be decrypted. This allows app to query disc id, mkb version etc.

 - we have only one key
 - data is still encrypted and can't be verified

If this is still needed, it should be implemented as run-time option (environment variable ?).

Due to the fact that AACS bus encryption was only hinted by early AACS
specification there seems to be some misconceptions.

First, what bus encryption is _not_:
- it does not encrypt all communication between drive and host
- it does not encrypt VID retrieval
- it does not use bus key (this is only poor wording in the
  specification)

Second, what is required for bus encryption to be activated:
- a bus encryption capable drive, drive certificate will have 0x01 as
  a second byte
- a bus encryption capable disc, content certificate (located in
  AACS/Content000.cer) will have 0x80 as a second byte
- a bus encryption capable host, host certificate will have 0x01 as a
  second byte

There are various combinations of all of those flags, so let's provide
a short summary:
- if drive is not bus encryption capable, then bus encryption will not
  be used, other flags are not relevant and normal AACS procedure will
  work as usual
- if drive is bus encryption capable but disc is not bus encryption
  enabled then bus encryption will not be used; however, drive will
  only allow hosts with bus encryption capable certificates, without
  one normal VID retrieval will fail, but getting VID from other
  source will make the disc playable
- if drive is bus encryption capable and disc is bus encryption
  enabled then bus encryption will be used, only hosts with bus
  encryption capable certificates can read such discs; getting VID
  from other source is not enought to read such disc as one must also
  have Read Data Key to decrypt bus encryption which is drive specific
While most of the current drives are supposed to be bus encryption
capable, most of the discs currently are not and it is quite hard to
come across one. Obviously this might change in the future.

So what is encrypted by bus encryption? Excatly the same data that is
encrypted by normal AACS, this means .m2ts files located in
BDMV/STREAM directory. Only this and nothing else. Bus encryption is
applied on the fly by the drive. Since the disc is already AACS
encrypted the host must first decrypt bus encryption and then perform
normal AACS decryption. So what is the difference? Bus encryption uses
encryption key that is drive specific, this means that the same disc
read on another drive model will produce differently encrypted
data. Without bus encryption, files simply copied from disc can be
decrypted if one gets proper VID. With bus encryption, such copy is
useless, unless proper decryption key is retrieved from the exact same
model of the drive. I am not sure if the encryption key is specific to
the drive model or every drive unit will have a different one.

This and several previous commits implement everything that is needed
to support bus encryption:
- determining if bus encryption is enabled from certificates
- retrieval of read data key that is used to encrypt data
- proper decryption (bus encryption works on sector boundary) before
  main AACS decryption

Code was tested with mplayer on LG BH16NS40 with "The Alien Anthology
Archives" disc from Alien Anthology (it is the only bus encryption
enabled disc out of 6 in the anthology).

All drives do not support REPORT_KEY with format 0x38, so we need to
cache the certificate from aacs authentication procedure.

For bus encryption to be active it must be enabled both by the drive
and the disc.
Drive certificate contains Bus Encryption Capable (BEC) flag in the
least significant bit in the second byte of the certificate.
Content certificate contains Bus Encryption Enabled (BEE) flag in the
most significant bit in the second byte of the certificate.
Retrieve both bits so it is now possible to check if bus encryption is
active (it will not be active if the disc does not enable it, even on
bus encryption drive; most discs currently do not enable it).

(It seems that at least some drives require a new AACS-Auth every time keys are being read)

Bus encryption uses data keys (separate one for reads and writes) that
can be retrieved from drive after sucessful AACS-Auth. Add function to
retrieve those keys.

It seems that it requires a new AACS-Auth every time keys are being
read (at least reading the keys right after reading VID fails on my
drive).

AACS-Auth is required for bus encryption, not only VID retrieval, move
it to a separate function from _mmc_read_vid().

VID is required for BD-J and BD+, VUK is not enough.

Some new drives implement bus encryption. Such drives do not work with libaacs currently.

    Simplify --enable parameters in configure, and use a more common
    default output.

    Use attributes.m4 from xine/feng instead of a custom piece of code
    that uses mktemp.