Tuesday Jan 19, 2010

Tips for porting Java applications to PS3 or any Blu-ray player

If you have a Java application that you want see working on Blu-ray Player, you will first need to create a Blu-ray Java disk image. There are samples for creating disk images on the hdcookbook .

The second most important thing is to make your application work against the Blu-ray Disk Java (BD-J) security sandbox model. This is not as simple as it sounds, for there are no easy means to debug Java applications on Blu-ray Players. But, we in the process of porting a huge Java application learnt some tricks that saved us enormous debugging effort. The same applications would have otherwise run successfully on a software player that is less restrictive than the real BD-J implementation. Ironically, it's easier to get a debug version of a software player.

When we were all set and expected our application to work on a hadrware Blu-ray player, and it failed to load, the failure invariably used to be due to some Security Exception. In order to trap the Security Exceptions, we ran the application on Standard Java SE (5 or 6), with the Security Manager enabled and granted permissions as appropriate.

We added the required workaround to the application so that the security restricted API calls were eliminated. For example, getting and setting a thread's context class loader is blocked on BD-J Platform. These calls were replaced with obtaining the current class's class loader instead. One by one we replaced all the security restricted calls and our application seamlessly ran on the Blu-ray player.

Sunday Aug 02, 2009

Profiling for the Blu-ray Java Platform


  • Profiling frameworks like JVMTI are not available for the Blu-ray Java platform.
  • Using System.out may not be feasible for some players are known to hinder the application performance when it's used.
  • The system clock on the players is too slow to measure anything meaningful on non-PS3 players.


Our team at Sun have developed an innovative way of profiling of Blu-ray Java applications. I will refer to it as hdcookbook profiler as it's made available through our open source project at: https://hdcookbook.dev.java.net

More about hdcookbook profiler:

  • The execution time is measured using PC's clock, not the player's clock. This enables logging of nanoseconds instead of milliseconds.
  • The profiling data is collected with minimum heap data and time overhead.
  • The profiler does not generate any profiling information on its own. This is totally under user's control. The user explcitly adds the profiling points of interest to the application.
  • The profiling events (start/stop timer) are communicated to the PC by means of UDP packets. The profiling events can be debug messages as well.
  • For viewing the profiled data, we have two UI applications available, one of them was developed for immediate use and the second one came out later. A screen shot of the ProfileBrowser (second one) is shown here:


    • The vertical bars represent the execution times for each method. The RED stretches indicate the execution times that are out side the standard window of execution times for a given method. If you see many red colored stretches, you can increase the deviation factor say by: 2 ( i.e 2 \* standard deviation) or more to identify execution times that are taking way too longer than the standard execution times for that method.
    • You can select the time unit that is convenient for analyzing the data at hand. We have set Microseconds as a default time unit. You can switch between micro, nano, millis and secs without resulting in any loss of precision during switching.
    • The range slider (right side bar; looks like scroll bar but with arrows pointing in opposite directions) allows zoom-in and zoom-out (narrowing down) of the time scale with up and down mouse dragging. That means you could zoom into a time range of interest by just dragging the mouse.
    • Method Filtering: You can provide an expression to filter the data on the display (the editable box is on the left at the bottom) and get the timeline for selected method/s. For example, you could type in an expression: a | b This will only plot methods names starting with letters a or b. This is useful for focussing on the individual method/s of interest to see how the timeline looks for them.

    Also see this write up about profiler

Monday Dec 22, 2008

AACS- how it works and its attacks

Here is a brief overview of AACS, a DRM mechanism used in Blu-ray disk and HD DVD.The algorithm used for (Cryptographic) Key Distribution and Revocation process is core to the AACS security. Naturally, a good amount of effort has been put into making this mechanism better in AACS taking into account that it was broken in CSS(Content Scrambling System). CCS is used in DVDs and has led to the failure of DRM enforcement on them.

How AACS works:

AACS uses a popular algorithm called Subset Difference Revocation (SDR) for key

assignment and revocation. SDR has led to many papers in the Crypto conference.

Many of them are variants or enhancements over the basic SDR algorithm.

In the SDR algorithm, cryptographic keys (used for encryption) are represented as a complete(full) binary tree. For AACS, a tree with 32 levels is used. That means 232 unique keys are generated.

The leaf nodes of this tree represent both hardware and software devices. The keys assigned to the leaf nodes are called device keys. Each device stores a subset of keys from the binary tree. The subset of keys is formed in such a way that only devices whose keys are not revoked are able to decrypt the content. In other words, the revoked devices, even if they all collude won't be able to decrypt the content using their keys. This is the core of Subset Difference Revocation method.

In Figure 1, a simple binary tree is shown. The leaf nodes n8 – n15 represent the devices. Ki,j means the key associated with node nj assigned with subtree rooted at ni.

For example, the device n8 stores the keys: k1,3 k2,5 and k4,9. Here, k4,9 is the keys associated with node n9, assigned with subtree rooted at n4. Note that the keys stored in device n8 are associated with its ancestor's siblings all the way up the root of the tree- n9, n5 and n3.

Figure 1

Diving one more step into the details of how this works, the subset of keys on a device (referred to as device keys) are not directly used in encrypting the media content. They are used in deriving a key called "Media Key" which is used in content encryption. The media key is encrypted using a carefully formed subset of device keys. A new media key is generated for each title just like a new secret key generated in each SSL session.

The content on the disk is encrypted as below:

[n1, n2, …,nm], Ek1 (K), Ek2 (K), … , Ekm(K) | EK(M)

Where, n1, …,nm are subset of nodes of the binary tree, whose keys k1, …,km are

used for encrypting the media key K. The content M is encrypted using the media

key K.

Note, the subset of nodes is formed in such a way that the non-revoked leaf nodes can derive one of the keys ki from the set: k1,.. ,km using node information ni from the set: n1,..,nm.

In Figure 1, the media key is encrypted using the set: {k1,3 k1,2}

Here is an interesting part of the SDR algorithm when a device is compromised, its keys need to be revoked. The subset of keys associated with a device or a leaf node includes keys for its ancestor's siblings but not the key associated with itself or its ancestors all the way up to the root of the tree. The subset of keys for the leaf nodes in the binary tree of Figure 1 is shown at the bottom of the tree. Also, using GGM algorithm, described later, given a root key K, it is possible to derive the keys for its left child KL and its right child KR. A leaf node in the binary tree is able to derive keys for all the nodes in the subtrees rooted at its ancestors but not its own key or its ancestor's keys.

Figure 2

When a device needs to be blocked from decrypting the media key, the key corresponding to that device is used for encrypting the media key. That's because the revoked device cannot derive its own key.When there are multiple devices that need to be blocked, a subset of keys is formed such that only non revoked nodes are able to decrypt the media key.

In Figure 2, nodes n8, n9, n12, n14 are marked as revoked. According to SDR algorithm, the following set of keys is used for encrypting the media key: {k2,4 k6,12 k7,14}

For more information on SDR algorithm please refer to this presentation.

Device keys:

Device keys are assigned by AACS LA. A set of device keys may either be unique per device(they do are unique on each hardware player), or used commonly by multiple devices (typically the software players distributed by a specific software vendor carry same set of device. It is expected that each device or player manufacturer treat these keys as highly confidential. AACS uses 128-bit AES keys as opposed to 40-bit DES keys used by CCS in DVD.

What is GGM?

The algorithm to determine the set of keys (to be held the device) need to take into consideration:

  1. The storage required by the keys that depends on the number of keys.

  2. Processing requirement for the device - time taken for each decryption and the number

    of times a decryption is performed.

In addition to using SDR algorithm, a key generation techniue called GGM (Goldreich, Goldwasser & Micali) is used. This technique helps in keeping a small subset of keys that are stored on each device and a short encrypted header (for retrieving the media key).

Given a key K for the root node, one can derive KL -key for the left child and KR -the key for the right child.

AACS Attacks:

First report:

The first attack was reported by a programmer, who identified himself as Muslix64, announced in the Internet discussion forum Doom9 on Dec. 18 2006. This programmer said he has successfully copied movies distributed in the HD-DVD format. Decryption keys were extracted from a weakly protected player (WinDVD). In an accompanying video demonstration posted on the YouTube Web site, the programmer showed encryption keys for six movies (this video is not accessible any more).

--Source NY Times (Jan 1st 2007)

Second Report:

SlySoft, an Antigua-based company that sells software to defeat various forms of copy protection, updated its AnyDVD (a commercial) product to allow it to copy the new AACS discs. Apparently, SlySoft had extracted a key from a different player and had kept the attack a secret. They waited until all other compromised keys were blacklisted before switching to the new one. And they came out openly 6 days after the new discs came out with updated keys :)

Why Revocation has not worked as expected in AACS?

After noticing the complexities surrounding AACS, the question that bothers is that, if some of the keys are exposed by hackers why isn't there a mechanism to revoke those keys and move on?

There seems to be a deployment problem with the way revocation works now: AACS license agreements allow 90 days for the player vendors to update the revoked keys, which is considered to be a very long period, that puts AACS and the studios in trouble.

The website: http://www.freedom-to-tinker.com/?p=1158 points out that that -

“at this point, Hollywood has released four generations of AACS-encoded discs, each encrypted with different secret keys. The industry is stuck on a treadmill: AACS changes keys every ninety days, and attackers promptly reverse-engineer the new keys and carry on decrypting the discs. And they wait and then publicly release the keys one by one, after a new disc has come out with different set of keys.

To be successful in the long run, AACS needs to out pace such attacks. Its backers might be able to accelerate the blacklisting cycle somewhat by revising their agreements with player manufacturers, but the logistics of mastering discs and shipping them to market mean the shortest practical turnaround time will be at least several weeks. Attackers don’t even have to wait this long before they start to crack another player. Like Slysoft, they can extract keys from several players and keep some of them secret until all publicly known keys are blacklisted. Then they can release the other keys one at a time the to buy additional time. “

While, AACS is the only protection that HD-DVD, Blu-ray claims that BD+ can further enhance Blu-ray disk security. Below is some information gathered from the web on BD+.

What is BD+ ?

BD+ lets Blu-ray Discs install and run a piece of encryption software on the player, allowing each title to have it's unique encryption scheme. Hacking into a protected disc only affects that single copy, it won't cause security breaches across the board for the same title. BD+ can detect tampering to a player, refusing to play once the intrusion is discovered. Sony and other studios that support Blu-ray believe this technology produces a secure, yet user friendly product that only punishes hackers for copy right violations.

BD+ was developed by Cryptography Research Inc. and is based on their Self-Protecting Digital Content concept. BD+ is effectively a small virtual machine embedded in authorized players. It allows content providers to include executable programs on Blu-ray Discs. On November 19 2007, Macrovision announced that it planned to acquire the SPDC technology (including patents and software code) from CRI for US$45 million in cash plus stock warrants.

On November 8, 2007, SlySoft announced that they had completely cracked BD+. This turned out to be not quite correct however. The crack allowed a user to copy a BD to the hard drive and play it back from there using only a specific version of Cyberlink's PowerDVD, but not to transcode, otherwise manipulate the content or play it back from a burned BD-R or BD-RE.


http://www.aacsla.com/ (AASC spec)


http://www.wisdom.weizmann.ac.il/~naor/PAPERS/stateless.ppt (SDR Algorithm)

http://www.freedom-to-tinker.com/?p=1158 (discussion on AACS attacks)

Thursday May 29, 2008

Want to Build applications that run on PS3 or Blu-ray player in your living room?

Give it a shot!

It's now possible to create Java programs for Blu-ray players without a disc burner. You can go to BDLive.com hosted by Sun and RCDb and sign up for a free Blu-ray developer disk. This disk comes with a bootstrap application that enables you to run your own Blu-ray Java programs on the player.

During Java One 2008 it was announced that the developer disk you get from BDLive.com will provide a code for registering on BDlive.com.This will enable you to upload your Blu-ray Java programs on BDLive.com. The next step is to stick in the disk on your player which will automatically download your program from BDLive.com and run it on the player. This is made possible with the BD Live feature available on profile 2 Blu-ray players.

I'm waiting for my disk to be delivered to check out if it works as expected. I'm going to post more blogs on how to create fun and useful Blu-ray Java programs.

Thursday Feb 16, 2006

Check out what Mustang offers in the I/O libraries Mustang-Core-Libraries


Mustang release has small but very useful enhancements in the core libraries area.
Here is a brief look at  some of them in the I/O area that you must have heard about during the  JavaOne 2005 talk given by Mark Reinhold.

Free Diskspace:

One can now discover the amount of disk space left in the partition named by
the given file. This is one of the highly voted RFE (697 votes). This is a very
handy feature, for example, installers can now determine beforehand
how much diskspace is available on a partition that it's going to install the stuff on.

Three new methods have been added to java.io.File class:


Using these methods one can do something like:

import java.io.\*;
  File dir;
  System.out.println("Total MB     Free    Usable");
 System.out.format(" %6d    %6d   %6d\\n",
        (dir.getTotalSpace() >> 20),
        (dir.getFreeSpace() >> 20),
        (dir.getUsableSpace() >> 20));

Changing File Attributes:

In Mustang the java.io.File API provides access to the file attributes for changing its readability, ability to write and ability to make it executable. Check out the following methods for playing around with file attributes:

Changing readability:                            owner-only, owner or everybody
Making it writable or read-only:              owner-only, owner or everybody
Making it executable or not executable: owner-only, owner or everybody


Password Prompting:

This is one of the highly voted RFE (438 votes) as well, that fixed the good old problem of password input being echoed on a system console. This is useful for command line tools that accept password from system console, eg: keytool.

The new class  java.io.Console enables reading the password from the console
without echoing it. Here is a small code snipped that shows this:

import java.io.\*;
    Console cons;
    char[] passwd = null;
    if ((cons = System.console()) != null)
        passwd = cons.readPassword("[%s]", "Password:");

Tuesday Feb 14, 2006

New bytes in Mustang release of JNDI/LDAP Service Provider

LDAP response timeout:

When an LDAP request is made by a client to a server and the server
does not respond for some reason, the client waits forever for the
server response till the TCP timeouts.
On the client-side what the user experiences is esentially a process
hang. In order to control the LDAP request in a timely manner, a read
timeout can be configured for the Sun JNDI/LDAP Service Provider
since Java SE 6, i.e mustang.

The property com.sun.jndi.ldap.read.timeout is used to specify the read
timeout.The value of this property is the string representation of an integer
representing the read timeout in milliseconds for LDAP operations.
If the LDAP provider cannot get a LDAP response within that period,
it aborts the read attempt. The integer should be greater than zero.
An integer less than or equal to zero means no read timeout is specified
which is equivalent to waiting for the response infinitely until it is received.

If this property is not specified, the default is to wait for the response until
it is received.

For example,

env.put("com.sun.jndi.ldap.read.timeout", "5000");
causes the LDAP service provider to abort the read attempt if the server
does not respond with a reply within 5 seconds.

Pooling Custom socket factory:

The JNDI/LDAP Service Provider allows connections from custom socket
factories to be pooled since Java SE 6 (Mustang).

Pooling of connections from a custom socket factory is allowed when
java.naming.ldap.factory.socket  environment property is set
and the custom socket factory to be pooled implements the Comparator
interface. The LDAP Service Provider calls Comparator.compare()
method for equality comparison of the socket factories whose connections
are being checked for equality by the pooling mechanism.The socket factory
comparison should ensure that the socket factory parameters that influence
the connection equality are being compared. This comparison is made
in addition to the connection identity comparison described in
How Connections are Pooled. A custom socket factory class should have
the following structure if its connections were to be pooled:

    public class CustomSocketFactory extends SocketFactory
implements Comparator<SocketFactory> {
public int compare(SocketFactory sf1, SocketFactory sf2) {
// do whatever comparison that's required

If the socket factory class does not implement Comparator interface,
the connections from that socket factory class do not get pooled.
This requirement for implementing the Comparator interface is to ensure
that the LDAP Service Provider does the necessary checks when
comparing connections from different socket factories whose
implementation is not known to the provider.

Download mustang beta from here

Thursday Dec 29, 2005

A Wild Chrismas with a little one!!

Blog on Bannerghatta
A Wild Chrismas with a little one!!

On a clear, sunny chrismas day in Bangalore we set out to visit
Bannerghatta Park, located at 25 Km from the city to show some
animals to our 14 month old son Rishabh who otherwise has seen
them only in pictures. I think this park is worth a visit for (Wild)
Animal lovers visiting Bangalore.

Bannerghatta Park offers an exclusive Safari ride which is a
unique experience that this park offers to the visitors and that's
the main reason for people to go there.
It being a Sunday, the park was crowded like any other place in
Bangalore. We took a ticket for the Grand Safari but the line to
get into the safari was so huge that we decided to move on
seeing the zoo first.


We saw colorful sparrows, two cobras twisted within each
other, black bears which were moving their necks in rotation
as if they were asked to do it repeatedly. We were hoping
that Rishabh would be thrilled watching all these animals. But
not all the times-- he was busy with something totally
different at times- like playing with the net kept  for the birds or
climbing the steps if he happen to come across any.

The Cheetas were sleeping but one of them was agile and was
 looking around. We tried hard for Rishabh to look at the
Cheeta but he was excited at a crow sitting next to it and ignored
our pleas to look at the Cheeta. He gets to see the crows everyday
in our backyard!!
The yellow haired monkeys that I had seen 8 years ago are were
quite amusing but now they have grown old with their hair shed off.
By then it was time to take the safari as it closes at 4:30pm.


Our friends Durgam and Shachi had already got into the safari line
and we got our turn after waiting in the line for nearly 40 minutes.
But the safari ride paid for it.

In the first part of the safari, dears, bears, sambars were spotted.
But then came our wild friends tigers, cheetas and lions.
The lions and cheetas are caged. But not all the tigers are caged.

It was a thrilling experience to see the tigers gracefully walking on the
pathways, on the sides of the safari van just as if they are walking
on the roads with the traffic around. I had not seen tigers
in such a close vincinity until then. Some of them were really big ones,
and thier bodies waved as they walked. There is only one white tiger in
the park and that is left free as well. I believe in all we saw about
10-12 tigers that were freely moving about. The park is worth a visit
just for this unique experience.
The park has caged gates as you enter in which gives a feeling
of being in the Jurassic Park!

Our dear Rishabh for whose sake we went to the park promptly slept off
when the safari van took off and woke up as we were getting down
the van :) But anyway thanks to him for making us visit the park
on a bright chrismas day.

Sunday Dec 04, 2005

Problems with Pooling when using JNDI?

I am writing a blog on this topic because many advance users of JNDI often have problems in getting the JNDI/LDAP pooling work as expected Here I will try to provide some tips that will help in self analysis of the application design.

JNDI provides a mechanism where by the connections used by different contexts can be pooled for the purposes of sharing. Pooling is required in production systems that need to create thousands of connections.

The pooling mechanism requires that a JNDI application release resources i.e. Context references held by it by calling Context.close() and any NamingEnumeration instances created by the Context must also be closed. Closing the Context or the NamingEnumeration objects indicates to the pooling mechanism that the specific use of a connection by the Context object is over, and the connection can now be reused by a new Context that is waiting for it.

Keeping track of all the Context instances becomes cumbersome in a complex application. To aid tracking of Context objects in an application, I will try to enumerate below all the cases when a new reference to a Context is created
Developers can use this as a checklist when the connections are not being reused or released by the JNDI/LDAP pooling mechanism.

  1. A Context object is obtained when lookup() methods and their variants are invoked.
    • Context.lookup()
    • Context.lookupLink()

    The lookup() method or any other API methods mentioned below returns by default a Context object unless the Service Provider finds an approrpiate Object Factory configured by the Application.

  2. A Context object is returned by invoking createSubcontext() and its variant methods:
    • Context.createSubcontext()

  3. A NamingEnumeration obtained as a result of any of the below API method invocation and their variants must be closed:
    • Context.list()
    • Context.listBindings()
    • DirContext.search()

  4. It's not enough if the NamingEnumeration is closed, a next step is required in some cases. And some developers may not realise this step (as it's not obvious) When any of the following API methods are invoked on a Context:
    • Context.listBindings()
    • DirContext.search()

    and the search() method is configured to return Objects as below:

            SearchControls ctl = new SearchControls();

    The Object returned by the search() or the listBindings() methods could be of type Context and that needs to be closed as well:

        NamingEnumeration ne = ctx.search(...);
    while (ne.hasNext()) {
    SearchResult sr = ne.next();
    Context ctxObj = (Context) sr.getObject());

    // do whatever is required with ctxObj


  5. A DirContext is returned when the below Schema retrieval methods are invoked on it:
    • DirContext.getSchema()
    • DirContext.getSchemaClassDefinition()

  6. A InitialLdapContext is used and a new instance of it is obtained by invoking the method:
    • InitialLdapContext.newInstance()

$ whoami

I presently lead the JNDI API development activities at Sun. I work on Java Libraries as well. In the past I have worked on Java Security and Networking API development. In my blog here I am going to share tidbits of using the APIs/Technologies that I'm most familiar with so that the other developers can possibly benefit from it.



« April 2014