Friday, November 4, 2011

Android, CSS, Blu-Ray: (Sub)Standard Security pt. 4

Before wrapping up this series of posts on why standardized security systems fail let's do a quick run on a few more systems.


Though the Android mobile operating system isn't strictly a standard, it is very much like a standard in that there is someone who defines the system (in this case Google - who also supply the generic implementation) and anyone can create a specific implementation of this system.

Android includes various security elements including kernel security, anti-malware measures and secure key storage. All of these elements are routinely hacked to bits.

As in the previous systems we've examined, the root cause of the Android's system security failures is the lack of motivation on the side of the implementers to enhance security. Due to this, those aspects of Android security that are implementation dependent (and all security is implementation dependent) are not likely to be done in a robust way.

Furthermore, when vulnerabilities are found in the Android base code itself, though Google are very quick in releasing patches, the implementers (i.e. mobile device manufacturers) are much slower in adopting and deploying these patches. A study done by Lookout Mobile Security showed that implementers typically deploy such patches many months, if not years, after they are released by Google.

Finally, because Android is so widely deployed there is great motivation on the side of attackers to analyze it and find weaknesses.

In many ways Android is just a Linux distribution for mobile devices. Popular Linux distributions for PCs, such as Ubuntu, have historically done a much better job in deploying patches - despite being a major target for attackers. This is due to Ubuntu being fully implemented by a single group and the fact that this group (and Ubuntu users) are security aware and strongly motivated to make it secure.


The Content Scrambling System, or CSS, is the system used to protect content on DVDs. Today one might not notice that DVDs have any kind of protection, but for a few years in the end of the nineties this was a hot topic. The security of CSS is entirely dependent on the secrecy of the CSS secret algorithm, which is the same in all devices. In 1999, three years after CSS was introduced, this algorithm was reverse engineered and widely published.
Even on T-shirts
CSS didn't have a chance. The same algorithm was implemented in software by dozens of manufacturers who didn't make any real effort to prevent the algorithm from being reverse engineered.

It seems that the definers of the CSS standard didn't really expect the algorithm to remain secret for long. The commercial need of getting CSS adopted trumped any security concerns and produced a zero security standard. Perhaps they were hoping that they could stop the distribution of pirate device through legal means, something that they in fact tried to do and failed ( has the details).


Following the failure of CSS the movie studios and other DVD producers made an effort to improve the content protection solution for the HD DVD formats: HD-DVD and Blu-Ray.

The Blu-Ray standard includes two content protection standards: AACS and BD+. AACS includes what seems like a major security advantage compared to CSS, in that each device model uses a different key to decrypt the content so that if a key is extracted from one device it is possible to produce new titles that cannot be decrypted using the compromised key.

AACS keys were in fact extracted from several device models, but to the best of my knowledge no one has ever produced a title that is not accessible on these models. As I explained in the post on HDCP,  in the real world it is not commercially viable to prevent the many legitimate users of a certain device model from obtaining a title just because some pirates compromised one device of that model.

The BD+ security scheme includes a scripting language that allows using a different decryption algorithm in each title and to check the integrity of the device that is decrypting the content. The initial BD+ proposal as defined by Cryptographic Research (CRI) included some fairly strong mechanisms including the possibility of using an external security token (such as a smart card) but by the time it came through the standardization process the device manufacturers removed those elements which would be more difficult for them to implement which (not coincidentally) are the same elements that would make life harder for hackers. BD+ was doomed to fail.

Do you have other interesting examples of failed standardized security systems that I've missed? Or perhaps a success story? Please use the comments below.

No comments:

Post a Comment