Error in XML -> WBXML conversion for ROs in NowSMS

Author

Message

Mikael Christersson
New member
Username: Micke_c

Post Number: 1
Registered: 01-2005

Posted on Friday, January 14, 2005 - 12:30 pm:

During test and development of our products, it has come to our attention that there is an error in the XML -> WBXML conversion for rights object in OMA DRM files. This problem leads to invalid right objects with too short decoding key values. Instead of the expected 16 (0x10) byte long keys, they seem to be truncated when a special sequence of the base64 encoded key is encountered.

To be more specific, if the base64 encoded key has a sequence of characters that will be translated to an all-zero byte (that is, a byte containing the bits "0000 0000") the converter seems to cut the key at this position, believing that it ends there. It is uncertain if this is true for all combinations leading to an all-zero byte, or if it only happens when the all-zero byte is positoned aligned at the beginning of a new group of four (base64 encoded) converted to three (binary format) characters.

In all cases, an example of a wrongfully converted object is as follows:

The XML-object:
<o-ex:rights
xmlns:o-ex="http://odrl.net/1.1/ODRL-EX"
xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#/"
>
<o-ex:context>
<o-dd:version>1.0</o-dd:version>
</o-ex:context>
<o-ex:agreement>
<o-ex:asset>
<o-ex:context>
<o-dd:uid>cid:P1008511f07b_20041129170329-1108204941@semc</o-dd:uid>
</o-ex:context>
<ds:KeyInfo>
<ds:KeyValue>kwFSALNmyPM/CHFCsPiQeg==</ds:KeyValue>
</ds:KeyInfo>
</o-ex:asset>
<o-ex:permission>
<o-dd:play>
<o-ex:constraint>
<o-dd:count>5</o-dd:count>
</o-ex:constraint>
</o-dd:play>
</o-ex:permission>
</o-ex:agreement>
</o-ex:rights>

This will result in the following WBXML-code (in hex):
030E6A00C505850686078701464703312E30000101494A4648036369643A50313030383531316630 37625F32303034313132393137303332392D313130383230343934314073656D630001014B4CC303 9301520101014D4E5253033500010101010101

The interesting parts of the two above are:
XML: "<ds:KeyValue>kwFSALNmyPM/CHFCsPiQeg==</ds:KeyValue>" which is converted to WBXML: "4C C3 03 93 01 52 01".

This is clearly a too short key valuein the WBXML code, since the key itself should be 16 bytes. The tool itself has recognized the key to be no more than 3 bytes, which is described by the "03" in the third position this should really say "10" (hex value for 16) since the keys are always 16 characters long. Looking at the XML tag, it is apparent that the key is cut at the position AL, which translates to the bit pattern "000000 00..." This is true for all similar bitpatterns in the aligned position.

Hopefully this will provide you with enough information to swiftly fix the problem. If there still are any uncertainities, we will try to explain them in further detail, but I cannot see that to be very probable.

Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 3905
Registered: 10-2002

Posted on Monday, January 17, 2005 - 10:27 pm:

You are correct. Basically, if the key value contains a null byte, then it is currently being truncated at the null byte.

That should not happen.

I've uploaded an update for v5.51 that will fix this problem. It is currently available at http://www.nowsms.com/download/20050117.zip.

-bn