Just as it was with DVDs, when movies first started to be distributed in that format, commercially-recorded Blu-ray disks today use an encryption system, which is sometimes referred to as ‘content scrambling’, to prevent people from making unauthorized copies. It’s actually named ‘aacs’.
Experts already know about this, but I’m putting this in layman’s terms for anybody who might not.
Basically, Blu-ray playback-devices have a hidden store of public keys, which the users are not allowed to access, and this time, the company is able to update that store of keys via the Internet, because most Blu-ray players today are also online devices.
Unlike how it is with Blu-rays, the content-scrambling system of DVDs was famously hacked. This means that Linux computers are well-able to play back Movie-DVDs. OTOH, the ability to play back commercial Blu-rays, is mainly unsuccessful on Linux computers, or on any other unauthorized devices, because the content-scrambling which gets used – was never hacked.
As long as the encryption continues to work, Linux users and pirates will not be able to play back or rip Blu-rays.
As it stands, the company is able to revoke public keys which it was once using.
This is a shame, because some Linux users might only be wanting to view Blu-ray movies which they purchased and paid for. But the main fear of the industry remains, that as a platform, a Linux computer is more susceptible to an unauthorized copy being made of anything, which that Linux computer would also be able to perform authorized playback of.
Therefore, when I gave instructions on how people can record Blu-rays privately, my assumption was that we would not be using any encryption. I don’t see encryption as being important in any way, for home-movies which people might shoot. But, the Blu-ray folder must nevertheless contain a sub-folder named ‘CERTIFICATES’. In the example I wrote about, this sub-folder will simply remain empty.
Further, the mere use of the Blu-ray (single-layer) disk, as a step-up from DVD+Rs, where a Blu-ray can store up to 25GB of pure data instead of 4.7GB, is unfettered for Linux users to use as they wish. All we need is an external Blu-ray burner, and we’re all set to burn pure data. But as soon as we want to burn something using ‘UDF’, which is the approved file-system of Blu-ray players, the level of difficulty already increases, even though no encryption has been used yet.
(Updated 09/19/2017 : )
There does exist an open-source library called ‘libaacs‘, which aims to duplicate what commercial Blu-ray playback-devices do, but specifically for Linux users. But I merely find the site to be interesting, as a theoretical description of how Blu-ray encryption is supposed to work. According to the source above, the process involves a combination of one specific Processing Key, and any one Host Key / Certificate, out of several known examples of each. Given these keys, methods that have been published as an open standard, will generate a Volume-Unique Key, also known as a ‘VUK’, with which one specific Blu-ray disk can be decrypted and played. ( :3 )
( Another piece of input which gets used in this process, is something called a Disk ID. This should not be confused with the Volume ID. The Volume ID is an arbitrary character string which we can set, when we format a volume. The Disk ID is a kind of serial number that gets stamped onto each optical disk, when they are mass-produced. I.e., We can burn an .ISO-Image-File onto an optical disk, but doing so will not redefine its Disk ID, which stays the same from the moment of manufacture.
In principle, if a cryptographic key is applied to a Disk ID, to unscramble the media content successfully, and if the same, encrypted content is then burned onto a different disk, the same cryptographic key will derive a different VUK, from the new Disk ID. This different VUK will fail to unscramble the content.
The reason this process has failed with DVDs, is the fact that the copy-protection of DVDs was conceived from the start, only to involve one cryptographic key, and may never even have taken a Disk ID into account… )
The way in which ‘libaacs’ tries to duplicate this process – for Blu-rays – has two problems in practice:
- The programmers of ‘libaacs’ only have a limited set of Processing Keys available in their database, so that even with the software working, they could only decrypt Blu-rays that were published before a certain date. Blu-rays made after a certain date would presumably have been encrypted with a Processing Key not yet known to this programming project, and can therefore not be decrypted. Every time the programmers of this project gain the knowledge of a ‘new’ Processing Key, this gets treated by Sony as a major intelligence failure, and it only happens once in a blue moon.
- In my experience, the versions of this software available to end-users, have never generated a single VUK in fact. Instead, end-users have access to an online database of VUKs, which were provided for them by other parties, and which cannot be revoked, and each of which is valid for one disk. Hence, users wanting to watch Blu-rays on their Linux computers, could in practice only watch movies, for which the privileged VUK is already in the database. ( :1 )
AFAIK, The main way in which VUKs get into the database, is through cracked Windows-based software, from other users who upload them, and who therefore give permission to Linux users, to watch one specific Blu-ray.
This assessment does not mean, that the encryption has been hacked. What it
actually means, is that ‘libaacs’ has even failed to implement a methodology which is openly-documented, and when the Processing Keys are known.
Further, there exists a tool named ‘aacskeys’, whose main problem is that nobody has been given instructions on how to use it. We are told how to supply the Processing Keys, but not how to supply the Host Keys.
This means that ‘aacskeys’ will continue to produce zero results, until Linux users learn, how to use ‘aacskeys’.
(Edit 09/14/2017 :
Unfortunately, there is no ‘man page’. But, (under Linux,) there exists a package-installed folder named:
Within that folder, there is a GZipped Readme -File. When we unzip that file, it gives clearer instructions. Essentially, the ‘aacskeys’ command is meant to be given, when the Present Working Directory is in fact that folder. The program is hard-coded not only to use the provided file which contains Host Keys, but also the other files in that folder, by their original name.
… Additionally, it seems to be a fact, that encrypted Blu-rays have their encryption-data on a separate partition, which is not mounted, if we simply tell our Linux desktop-managers to mount the disk in question, from the GUI. If we have done so, then we’d need to run ‘aacskeys’ as root, before this utility can extract the data it needs, to try decrypting the disk.
The fact that even the Readme -File does not mention this, seems to suggest that the utility was not primarily designed to be run under Linux, since under Windows, there is no such thing as root. Under Windows, the software in question needs to have raw access to the device.
Alternatively, situations exist under Linux, where the playback application mounts the disk in question, so that we’re not expected to use our desktop manager to do so first. In that case, some possibility exists that the playback application can decrypt the disk.
However, since my favorite playback application never runs as root, and since I need to mount the disk manually before using that playback application, there was never any way in which this playback application could have generated the required VUK.
Further, although it is possible that the firmware of an external BD- Drive / Burner contains encryption keys, my understanding of the situation (was) such, than any decryption that takes place, (would have been) carried out by the CPU of the Host, and not by the Device. )
(Update 09/08/2017 : )
As an alternative to always using open source software, Linux users also have the option these days to use paid-for software.
Specifically, there is now a paid-for application I can recommend, named ‘DVDFab‘. It strikes me as quite robust. ( :2 )
The main problem with open source software obtaining keys is, that Sony collects royalties, from owning the Blu-ray standard. If a given Linux distribution was programmed by people who do not collect money for it, then those developers also have no source of funds, from which to pay royalties to Sony.
But, there is a version of ‘DVDFab’ now, that end-users pay for, and that is also a Linux binary version. It has specifically been programmed to run on Ubuntu 16.04 and up.
For me personally, the problem in trying to buy this software is, that I’m based on Debian / Jessie, which is also known as Debian 8, which is pre- Ubuntu-16.04 . The Debian version which would be up to requirements for this version to run, would be Debian 9, which is also known as Debian / Stretch, which is now also the modern version of Linux, while my Debian / Jessie systems are by now marked ‘Oldstable’.
What this means for me, is that I can purchase the Windows license of DVDFab 10, and install that on my remaining Windows computer, which I name ‘Mithral’. But none of that will work for my Linux computers. But I suspect that if other users do have Debian 9, or Ubuntu 16.04 (+) , with a little bit of tinkering, they’d be able to get a paid-for instance of ‘DVDFab’ to work either way.
Please Beware however: When buying a DVDFab license, The Windows and Linux versions require separate licenses. Existing Windows license keys will not work for the Linux version, and if the reader wants both, or wants to migrate, he will need to repurchase.
(Update 09/11/2017 : )
1: ) I have just purchased another remastered, Blu-ray version of “2001: A Space Odyssey”, at full price, just to experiment with playing it back, using an application, that uses ‘libaacs’. The result was that again, the VUK for this one version was already in the database, so that again, I was not able to confirm in any definite way, that ‘libaacs’ is capable of using its (known) Processing Keys on the end-user’s device, to generate VUKs locally.
Odds are quite high, that whatever movie the user wants to play back, if it was recorded using one of the known Processing Keys, it also has its VUK listed as such in the DB.
Further, even though properly used, the utility ‘aacskeys’ fails to decrypt this disk.
FWIW, I don’t believe this is due to any programming-deficiency in the ‘libaacs’ project. Instead, my next guess would be that all the Host Certs have in fact been revoked, which the ‘aacskeys’ utility has been using. If they have been able to make their keys public, then they’ve also made known to Sony, which Host Keys have just been compromised.
2: ) The advantages of using ‘DVDFab’ over ‘tsMuxer’ to record a Blu-ray should be:
- DVDFab will burn the correct UDF version ( 2.50 ), or save a disk-image of that File System to a file with an .ISO File-Name Extension.
- DVDFab will allow the user to create a Disk Menu, which tsMuxer cannot do high or low. tsMuxer can merely author a Blu-ray whose video-content plays from beginning to end.
And No, DVDFab does not give out the VUKs for each disk. I suppose that leaks from the royalty-payers could be one way in which keys get hacked. But from what I can tell, the newer versions of DVDFab have been altered in such a way, that methods which once coerced VUKs from this application, will no longer work. And this is a sign of good faith on the part of the operators of DVDFab, towards Sony.
( Optimally, each application would have one Host Certificate / Key Pair, with which it would extract the VUK for one Blu-ray, and never export that VUK. Because a Host certificate can in fact be revoked, this would mean that a company which sells its applications, agreed that their Cert could be revoked, and if it was, would lose its only means to earn money. This gives a strong incentive to paid developers, to disallow abuse of their keys and credentials, by certain users. )
3: ) I suppose that some readers might wonder, why the manufacturers of some playback-systems create a Host Key and a Host Cert as a pair. The answer to that would be the apparent fact, that this pair is a valid example of Public Key Cryptography, where The Certificate is another way to say, ‘The Public Key’, while The Key is another way to say, ‘The Private Key’. In general, a Public Key can be used to encrypt a message, which only the holder of the Private Key can decrypt. And, the Private Key ostensibly cannot be derived from the Public Key.
It’s my understanding that the makers of playback-systems give the Certificates – i.e. their Public Keys – to the publishers of content, while equipping their playback-systems with one Private Key. This allows publishers to encrypt media in such a way that only the authorized playback-systems can decrypt it, while also reducing the risk that the actual Host Keys are revealed.
( … Details removed because erroneous … )
(Edit 09/19/2017 : )
A possibility which secure encryption needs to take into account, is that a legitimate exchange of data could be monitored, so that even if an unauthorized third party did not possess the Private Key, some sort of playback-attack could still take place. Further, Public / Private Key systems can be used to authenticate, rather than to communicate a secret message. In the latter case, the recipient of the Public Key needs to define a message, which either the holder of the Private Key is next supposed to encrypt, or vice-versa, the recipient of the Public Key could encrypt a message, which the holder of the Private Key would decrypt and report back in cleartext, as proof that the originator of the Public Key actually holds the corresponding Private Key. This is known as public-key authentication, and the message used can be a nonce of some sort.
Alternatively, a nonce can be appended to the secret message, just so that every time it has been encrypted to a Public Key, a different ciphertext results, and thus to add security to the transmission of data.
A key detail to this idea of a nonce would be, that according to established principles of secure cryptography, this nonce is supposed to be a different number, for each communications-attempt, and is usually decided by the recipient of the Public Key. If the nonce was always the same number, it would no longer add any security to the communications attempt.
But this idea could be important to the encryption of Blu-rays, in the traditional case where the BD-Burner did not have the CPU-strength required, even to carry out one public-key encryption. Rather than encrypting the Disk ID to the Host Certificate, a public-key authentication could take place, and if it was negotiated successfully by the host, the weaker Burner could respond by transmitting the Disk ID in cleartext.
What this could mean is that the Burner, or the actual Disk, could in fact rely on storage instead of on local encryption, by which the nonce has been stored as encrypted to each supported Host Cert.
(Edit 09/18/2017 : )
More precisely, it seems that both the Processing Key and one Host Key out of several are needed to decrypt the disk. The Processing Key is applied first, when decrypting, to the Media Key Block, thus resulting in the Media Key, which are all visible to the software. Then, the device is queried to reveal its Disk ID, which it encrypts to the Host Certificate of the computer. After the computer has decrypted the Disk ID using its Host Key, it applies the Media Key to that in a one-way encryption scheme named “AES-G”. The resulting VUK is a symmetrical key, and which can be used to encrypt or decrypt the actual media-stream at practical processing speeds. The playback-systems only need to apply the Public Key Encryption method, to decrypt the VUK, not the stream, so that the media-stream can be played.
I suppose that a plausible follow-up question might be, ‘How can one out of several Host Keys work?’ My answer to that question would be that a Mathematical solution exists.
I do not know of any system, where Any Host Key will decrypt a message, which only Fails to match a CRL – an explicit List of Revoked Certs. This would amount to nonsense, because then, anybody could generate an arbitrary Key-Pair (which has not explicitly been authorized)…
(Edit 09/12/2017 : )
I suppose that the idea of ‘Broadcast Encryption’ (see above link) should be compared with RSA Encryption, as well as with ElGamal Encryption. In certain practical cases of RSA encryption, the public key consists of the exponent 65537 and a given modulus, while the private key consists of a (full-length) secret exponent, and the same modulus.
If it was the intent to redesign RSA such that a message can be encrypted, so that either out of two recipients can decrypt it, then there are essentially two possible ways to proceed:
- Hybrid Encryption, where the message is itself encrypted with a symmetric key, but where that symmetric key is encrypted once with each of the public keys, so that the encrypted results are stored separately. Each result can then be decrypted using its own private key.
- As the exponents are the same, the moduli of the two public keys could simply be multiplied, to result in a larger modulus, that having twice the length of either original modulus. In that case, either secret exponent, together with its corresponding sub-modulus, should be able to decrypt the message / hybrid, symmetric key.
An interesting observation about this example would be, that the size of the message would seem to increase linearly with the number of public keys encrypted to, regardless of whether approach (1) or approach (2) above is taken. It’s just slightly easier computationally to go with approach (1).
This is a cost which would need to be paid, in order for the encryption to retain the strength, which the RSA Cryptosystem originally gave it. In fact, if such cryptographically-strong methodology was needed, then indeed we’d be interested in a Threshold Cryptosystem. And in that case, I’d guess it would be at a slight disadvantage to base the Threshold Cryptosystem on ElGamal, compared to basing it on RSA. ( :4 )
But I think that in the case of Blu-ray disks, there only exists one MKB (Media-Key Block), as well as numerous Host Key / Certificate Pairs in parallel. I do not know what the size of the MKB is, but if it was the basis of establishing revocations, then the fact that its size is eventually restricted, would weaken its eventually encryption-strength.
And the necessary result of that is, that Broadcast Encryption cannot be as strong, as Threshold Encryption would be. It’s just strong enough, to base the distribution of movies on, and not, to base ‘matters of national security’ on, for the sake of argument. And this would also be why, actual Threshold Cryptosystems are so rare in any household context.
( … )
4: ) The WiKipedia definition of Threshold Encryption exceeds what I can imagine as attainable. Which is, that a set of potential recipients could have public keys set up, so that one or more member of the set will provide a necessary private key that the other recipients will need, together with their own private key, to decrypt an eventual message. The difference in my own idea of how this would work, is that at the time the message is sent, the sender designates a specific recipient as the ‘group leader’, whose private key will be needed, before the individual private keys can decrypt the message.
The way it sounds according to the WiKiPedia article, the total number of private keys available at any time, needs to exceed a number, which was determined when the public keys were set up.
But then, according to my own interpretation:
- In the case of RSA: Two encryptions need to be carried out sequentially, one using the ciphertext from the previous, one to the public key of this ‘group leader’, and the next to the public key of an individual member…
- In the case of ElGamal Encryption: All message-versions would need to use the same ephemeral key, resulting in the same value for ( c1 == gy ) according to the WiKiPedia article. But the computations that are performed to generate ( c2 ) would need to be chained, once against the public key ( h == gx ) of each required private-key holder. Each application will require that a separate shared secret ( s == hy == gx·y ) be computed, both when encrypting and when decrypting.
(Edit 09/14/2017 : )
I suppose that a system matching the WiKiPedia description can be derived, in which indeed any 2 private keys will decrypt a message, if the symmetrical key is encrypted once to every combination of 2 possible recipients. This would eventually require (n)(n-1)/2 encryptions. As well, it would be possible to encrypt the symmetrical key so that any 3 private keys can decrypt it, if a total of (n)(n-1)(n-2) / 3! encryptions is considered allowable…
But then, the number of encryptions that would need to be stored, would grow either in proportion to the number of individual members squared, or in proportion to that number cubed, whichever case is being aimed for.
Some people might prefer a strictly formal definition. Thus, to recreate the Threshold Cryptosystem (t, n) of the WiKiPedia Article above, where (n) was the number of members, and (t) was the minimum number of recipients’ private keys required to decrypt a symmetrical key, then the number of differently-encrypted, symmetrical keys would actually equal:
n! / ( (n-t)! · t! )
(Edit 09/15/2017 : )
I’m willing to entertain a hypothetical scenario which would run as follows:
- The state of miniaturization today could be so far advanced that, contrary to my traditional assumptions, the CPU inside a BD-Burner could be powerful enough, to carry out a public-key encryption once, before a movie is played.
- A ‘special protocol’ could exist between an external BD-Burner and a PC, by which the PC sends a query to the Burner, stating the Host Certificate the application is using, and by which the Burner encrypts the VUK to that Host Cert.
- The PC-application could then use its Host Key, to decrypt the VUK, and therefore the media-stream-files.
One problem with this scenario would be, that the VUK would need to be present in some literal form on the actual disk for this to work, still mapping according to a directory-like structure, which may correspond to how the earliest Blu-rays were actually encoded, but which has fallen out of favor. Instead, only the encrypted Media Key Block and the Disk ID are actually stored on the disk, thereby requiring that the Processing Key and a Host Key be provided externally, before the VUK can be found. And the list of accepted Host Certificates can then be stored in the Burner.
How this gets implemented under Linux, would be an open-ended question, since Linux abstracts hardware differently from how Windows does. Under Linux, the H/W in question would still need to exist as a device-file, in the ‘/dev’ folder, which data can nevertheless be written to / from it as an arbitrary stream-within-Linux. But additionally, when the device has been mounted correctly, the Burner could be intelligent enough to create a virtual folder, as seen by Linux user-space processes.
The problem with that last idea would be, that according to how the Linux kernel manages its own file-systems, if the directory is readable and empty, the kernel itself will prohibit trying to access a file within it, without any query being sent to a physical device. Alternatively, setting the directory-permissions ‘x’ but not ‘r’, may produce desired results under Linux, but wouldn’t be supported under Windows…
As my technical appraisal of the ‘aacskeys’ utility now stands, any attempt to use it with a modern Burner, as root, will ultimately result in the specific error message, that the current Host Certificate has been revoked by the drive.
If people are in fact using the utility ‘aacskeys’, which I mentioned above, then one observation which they may not have an explanation for, is that ‘aacskeys’ allows them to specify a ‘binding nonce’, which would not be the actual, decrypted Disk ID, which a user-space application can receive. And I can actually offer two possible reasons why this utility would have such an option in its command-line:
- When we make a binary copy of a disk, let’s say from an .ISO-File, our copy of the disk will have a different Disk ID, from the mass-produced one, the new Disk ID having been determined when blanks were manufactured. The no-nonsense explanation for why the utility would then allow its user to specify a datum which is different, is so that this datum matches the unencrypted Disk ID of the original disk, so that he can generate a working VUK, and so that afterward, the user doesn’t need to pay attention to whether the VUK actually matches the disk he’s using; the VUK will still allow him to play the disk.
- The user may be facing a situation, in which the utility cannot decrypt the Disk ID, because the Burner has revoked all the HOst Certs he has available to him. In that case, if he can supply this datum from someplace else, then he could still proceed to use this utility to derive a VUK. but in that case, his next stumbling-block would be, that the utility does not have up-to-date Processing Keys, one of which would need to fit.
I suppose that an additional piece of information which a non-expert might find helpful, is that a condition which must exist in order for a Cryptosystem to be deemed ‘secure’, is that a hypothetical attacker could know the system being applied in full, Mathematical detail, but should still not be able to decrypt a ciphertext, unless he also possesses the appropriate key for doing so. Hence, if an encryption-scheme is devised which merely applies a secret protocol, as I was musing above, this is not considered to be cryptographically secure by today’s standards, as merely knowing the protocol could decrypt the ciphertext, or confirm a cleartext-message, in a case where one-way encryption was meant to do the latter.
This criterion is taken seriously today, even though most of the encryption which took place before World War 2, would not be considered secure then, as many of the methods simply required that a secret methodology be known to a hypothetical enemy…
dirk@Klystron:/dev$ ls -l sr* brw-rw----+ 1 root cdrom 11, 0 Sep 6 21:10 sr0 brw-rw----+ 1 root cdrom 11, 1 Sep 16 14:40 sr1 dirk@Klystron:/dev$
The above excerpt from my ‘/dev’ folder shows two CD-ROM-type devices, and from practical usage, I know that the second one, identified as ‘/dev/sr1′, is in fact the BD-Burner. What these permission-bits show is standard Debian-security-policy, according to which all users in the ‘cdrom’ group, have both read and write permission to the actual device-file.
I.e., There should not be any obvious reason for the utility ‘aacskeys’ to require root, since the group of the present user can write directly to the device. Hence, an application running entirely in user-space can also offer a Host Certificate – a Public Key – and wait for the device to reply in some way with a VUK, which the application would need its (Private) Host Key to decrypt.
If we mount either device, the properties of the mount-point – i.e. of the mounted file-system – may vary widely, since either device may contain an arbitrary volume. And in fact, what those properties are depends more on the kernel than it does on the external Burner. But mounting either device will not change the properties of the device-file, in the directory ‘/dev’.
Nominally, write-access to the device-file is granted to certain users, just so that they can burn a disk. Optionally, a BD-Burner could react in a specific way, if it was sent data to the device-file, which indicated that some special protocol was to be invoked.
The ‘b’ indicates that both are block-devices as opposed to character-devices, but a character-stream can be sent to a block-device. Conversely, block-access to a character device would not be possible. And the ‘+’ character indicates that as created by the kernel, each file has extended attributes, which in turn are not shown here.