Is it a reasonable idea to try to figure out a way to play HD-DVDs on an
Open Source Software OS? I think that this is possible and it would be
much more secure than M$ Vista.
Further research indicates that the license for AACS requires that the
decompressed signal sent over the connecting bus (AGP, PCI, PCIe, HTX,
etc.) be encrypted. These people are seriously paranoid -- it doesn't
do any good to be paranoid because hackers have already found out how to
get the disk key for HD-DVDs.
IAC, this actually does help solve the problem.
So, my design so far for the graphics board:
We have two PCI addresses (secondary addresses) one to communicate with
the system and one for input of streaming video.
We have an AES decoder for the streaming video input that can be turned
on and off.
We have a MCU on the board (soldered to the board) with built in ROM and
I2C to communicate with the HDCP enabled HDMI transmitter and an
external connection.
There are two things that the OS driver can do:
1. Turn HDCP on and off BUT not override the MCU turning it on.
2. Turn the AES decoder on and off.
The MCU will know if the AES decoder is on and the video resolution
being used, not by being told by the OS but by reading the information
from the registers in the video controller and or being told what to do
over the I2C bus. If the decoder is on, it is presumed that video is
being received -- the OS needs to turn it off if no video is being
received. When the decoder is on, the MCU will turn HDCP on or off and
other outputs on or off based on the requirements of the video disk's DRM.
Now, we can't stop somebody from making a software decoder for AACS that
produces 'clear' (unencrypted) video, but you can't stop hackers from
making one for Windows (which has already happened).
Now we also make a video decoder board that has an AACS decoder for
input and a AES encoder for output. If we use something like the NXP
chip the board would have firmware on board. If this needs to be
loadable or flashable, then you would also need an MCU with ROM
(soldered to the board) to handle the issues of encryption, DRM and
communicate with the graphics board.
So, this video decoder board accepts the unchanged data from the HD-DVD
or BR decodes the AACS or CSS (if needed), decompresses the video, and
encrypts the output with AES (if needed).
The board can communicate with the graphics board over the I2C bus
regarding resolution, HD rules, and encryption.
The I2C bus is not considered a consumer accessible bus so this is OK.
This is totally secure to the extent that appears to be required by the
DHCP & AACS licenses -- you can't get unencrypted HD out of the HDMI
port, or the computer's internal bus, without serious hacking of the
hardware. We can even publish the source code for the MCU firmware on
the boards since it is in a ROM soldered to the boards.
Does anyone see something that I missed? Can this be broken without
using a soldering iron and a ROM programmer, or tapping into the I2C bus?
I have some questions about this.
AES requires a common key -- the encoder and the decoder need the same
key. Do we give all of our boards the same key, or would each graphics
board get a random key which the video decoder board would need to
obtain over the I2C bus?
This does not address the issue of copying. Obviously, allowing no
copying is simple. If the disk says no copies, then the video decoder
board would refuse to provide the needed output. Remember, it won't
work to try to record the AES encrypted video data.
I still have not figured out how making a copy is prevented. I would
think that you could just directly copy the contents of the disk. I
presume that there is something in the drive that prevents it.
Otherwise, you could just install 2 drives in a PC an make copies IAC,
it isn't our problem.
What I don't know about is what to do when a disk allows copies. How
can you determine if a copy has been made since you can't burn a pressed
disk. Perhaps 1 copy means one level of copying which can be
implemented in the video decoder board if it also has an AACS encoder.
You just output a header with 1 less copy allowed.
--
JRT
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
