Your Universal Remote Control Center
RemoteCentral.com
Custom Installers' Lounge Forum - View Post
Previous section Next section Previous page Next page Up level
Up level
The following page was printed from RemoteCentral.com:

Login:
Pass:
 
 

Page 5 of 8
Topic:
Weird HDMI issues - Imagine that !
This thread has 112 replies. Displaying posts 61 through 75.
Post 61 made on Sunday June 13, 2010 at 13:13
crosen
Senior Member
Joined:
Posts:
April 2009
1,262
On June 13, 2010 at 13:09, mr2channel said...

Well, can you see that Brent, Audible Solutions and Bob are not all in agreement about whether the video data is encrypted on the line between two HDMI devices using HDCP? Would it not be useful to sort out the truth, here?

Last edited by crosen on June 13, 2010 13:32.
If it's not simple, it's not sufficiently advanced.
Post 62 made on Sunday June 13, 2010 at 13:28
BobL
Founding Member
Joined:
Posts:
March 2002
1,351
Crosen,

Got to run right now. I'll try to answer sometime tomorrow. BTW, I think you meant HDCP and not DHCP unless you are talking about the ethernet channel:-)

Bob
Post 63 made on Sunday June 13, 2010 at 13:31
crosen
Senior Member
Joined:
Posts:
April 2009
1,262
On June 13, 2010 at 13:28, BobL said...
Crosen,

Got to run right now. I'll try to answer sometime tomorrow. BTW, I think you meant HDCP and not DHCP unless you are talking about the ethernet channel:-)

Thanks, Bob. Quite right - HDCP, not DHCP :-)
If it's not simple, it's not sufficiently advanced.
Post 64 made on Sunday June 13, 2010 at 14:09
WhiteVan Lifestyle
Loyal Member
Joined:
Posts:
July 2007
5,108
I would like to see this thread as a sticky!
As annoying as it is there is some great information here.

I'm not going to post a response because I do not believe I can be nearly as clear as Alan, Brent or Bob.

I do not believe I just said "Nearly as clear as Alan" (I need a drink)

I will say to crosen that this is one of those things that will frustrate the hell out of you and torture your very being and then one day just click. When it does I hope you remove your sunglasses before smacking yourself in the forehead. ;)
Safe 'n Sound Central Coast CA www.mysafensound.com [Link: facebook.com]
Post 65 made on Sunday June 13, 2010 at 14:15
crosen
Senior Member
Joined:
Posts:
April 2009
1,262
On June 13, 2010 at 14:09, WhiteVan Lifestyle said...
I'm not going to post a response because I do not believe I can be nearly as clear as Alan, Brent or Bob.

Well, you are saying this as though the three of them are all saying the same thing. However, they are not. Some say the HDMI TMDS stream is encrypted. Others insist it is not encrypted.

How about you? Do you think the stream is encrypted or not? This is quite essential to the overall discussion.
If it's not simple, it's not sufficiently advanced.
Post 66 made on Sunday June 13, 2010 at 14:21
Prime Design
Active Member
Joined:
Posts:
August 2009
747
When experts can't agree, bring in more experts until someone can be definitive and quiet all the rest.  Brent, get jeff online, stat.
Post 67 made on Sunday June 13, 2010 at 15:19
Brentm
Ethereal Home Theater
Joined:
Posts:
July 2003
2,688
On June 13, 2010 at 14:15, crosen said...
Well, you are saying this as though the three of them are all saying the same thing. However, they are not.

Did not notice, but okay.

Some say the HDMI TMDS stream is encrypted. Others insist it is not encrypted.
How about you? Do you think the stream is encrypted or not?

If what you are asking is...
Does the source, AVR &/or other inline device in any way change the actual video data (other than to overlay OSD) that is on the disc (or other media) to provide a measure of security?

No, nothing changes the data as it is written.
How the data is out-putted (Rez, Bit-Rate & Audio Formatt) from the source to the AVR/display is dependent upon Q & A in the EDID channels.


This is quite essential to the overall discussion.

Why?
And how does this effect what you do on the job?

BTW: I think that Bob L is referring to all of the batch header info (such as Clock, Row, Column, pixil number etc) which is digital by nature.
That has nothing to do with content protection.
What is sent is what is received (not accounting for line loss).

The HD Fury should be a good indicator about this.
It spoofs HDCP and does a video Digital to Analog down conversion and Viola!
Brent McCall
Paid Endorser for;
Ethereal (386) 846-7264 Cell
Post 68 made on Sunday June 13, 2010 at 15:53
crosen
Senior Member
Joined:
Posts:
April 2009
1,262
On June 13, 2010 at 15:19, Brentm said...
If what you are asking is...
Does the source, AVR &/or other inline device in any way change the actual video data (other than to overlay OSD) that is on the disc (or other media) to provide a measure of security?

No, nothing changes the data as it is written.

OK. So, my uneasiness comes from reading material from DCP that seems to state otherwise. The material seems to state that the TMDS stream is bit for bit encrypted using the keys of the transmitter and receiver. And, that in the link between AVR and display, the AVR would be considred the transmitter. Might I be misreading this material? Of course!

I hope I don't offend trying to reconcile the apparent difference between these two trusted sources of info (i.e. you and DCP.) Perhaps you could have a peak and reconcile this apparent difference. The first of the following links does not specify that the encryption is on the TMDS line, but the second one does:

[Link: digital-cp.com]
Page 5
After authentication, the transmitter uses its HDCP cipher engine and the shared session key to create a stream of encrypted data that can only be decrypted by the receiver. The receiver uses its HDCP cipher engine and its copy of the session key to decrypt the content.

[Link: digital-cp.com]
Page 35
HDCP Encryption is applied at the input to the T.M.D.S. Encoder and decryption is applied at the out of the T.M.D.S. Decoder (Figure 3-1).

Why?
And how does this effect what you do on the job?

Because, if the HDCP content sent between the source and the AVR is encrypted using one set of keys (i.e. that of the source and AVR), and then that HDCP content is sent from the AVR to the display using a different set of keys (i.e. that of the AVR and display), then the two streams are not the same set of bits. This means that the AVR is sending a new stream (i.e. and not just repeating an existing stream.) That means it is reconstuting any parsable signal.

BTW: I think that Bob L is referring to all of the batch header info (such as Clock, Row, Column, pixil number etc) which is digital by nature.
That has nothing to do with content protection.
What is sent is what is received (not accounting for line loss).

OK, let's see if this is what Bob L means? Or, if he means that the content is in fact encrypted?


The HD Fury should be a good indicator about this.
It spoofs HDCP and does a video Digital to Analog down conversion and Viola!

From what I understand, it doesn't just spoof the HDCP - it uses illegally obtained keys that have not been revoked to perform the authentication and decryption.

Here's one account of this from an old thread (see second paragraph of lined post): [Link: curtpalme.com]

Last edited by crosen on June 13, 2010 16:03.
If it's not simple, it's not sufficiently advanced.
Post 69 made on Sunday June 13, 2010 at 16:22
crosen
Senior Member
Joined:
Posts:
April 2009
1,262
BTW, the idea that the content is sent on the TMDS stream free and clear of encryption just because the sink was pre-authenticated would not really make for a robust content protection system. This would allow for a "man in the middle" attack. I wouldn't think the industry would have gone for such a solution.

In other words, my understanding of the DCP paper makes sense to me intuitively. This is another reason I feel compelled to clarify and verify these points.
If it's not simple, it's not sufficiently advanced.
Post 70 made on Sunday June 13, 2010 at 17:13
Brentm
Ethereal Home Theater
Joined:
Posts:
July 2003
2,688
On June 13, 2010 at 16:22, crosen said...
BTW, the idea that the content is sent on the TMDS stream free and clear of encryption just because the sink was pre-authenticated would not really make for a robust content protection system. This would allow for a "man in the middle" attack. I wouldn't think the industry would have gone for such a solution.

In other words, my understanding of the DCP paper makes sense to me intuitively. This is another reason I feel compelled to clarify and verify these points.

The purpose of the HDCP is spot "the man in the middle" if it is an illeagle device, this is not the job of the Video stream .

Again I must ask...
What does this have to do with your installations (?), this is for equipment mfgr's to know/employ.
As an installer as long as the product works you are good, when it does not it is not because of encryption it is because there is a signal loss somewhere in the line.
That is what you as a "CI" need to worry about (because most mfgr's seem to not care).

What you keep bringing up (and possibly misunderstanding) has to do only with product design and DCP implementation.

There must be something here that I am too thick to notice (which my wife accuses me of a lot).
Brent McCall
Paid Endorser for;
Ethereal (386) 846-7264 Cell
Post 71 made on Sunday June 13, 2010 at 17:30
crosen
Senior Member
Joined:
Posts:
April 2009
1,262
On June 13, 2010 at 17:13, Brentm said...
Again I must ask...
What does this have to do with your installations (?)

A fair question. If the encryption behaves the way I understand it to from the DCP material, then I think one must conclude that the AVR generates a new signal. (Yes, I know that assertion can be debated, but one point at a time!)

Now, if the AVR generates a new signal, that has significant implications when configuring and troubleshooting HDMI setups. For example, it would mean that signal degredation on the TMDS lines was not additive over the two links when going from source to display through an AVR, the way it is additive when going from source to display through a typical balun. Instead of being additive, it would be "weakest link" determines the integrity. (Again, I know my conclusion here is debatable, but I'm just trying to explain why it is important to me to understand. I'll try to justify this portion of the argument if we get that far. First, we need to deal with the encryption issue, because if I am wrong there, then my whole argument likely goes away!)

I have put together a diagram that shows my understanding of the encryption, which I will post in a moment. I'm not sure how much it will help me or anyone else, but it helped me to put it together, so I'll post it and we'll see.
If it's not simple, it's not sufficiently advanced.
Post 72 made on Sunday June 13, 2010 at 17:35
crosen
Senior Member
Joined:
Posts:
April 2009
1,262
OK, here's the diagram that shows my interpretation of video data travelling from a BD player through an AVR to a Display based on the DCP material.

The salient point here is that the video pixel (shown as being 8 bits, even though I think it goes over HDMI as 10 bits?) appears as 01010101 when going over the HDMI link between the BD Player and AVR, but as 11001100 when going over the HDMI link between the AVR and display.

(BTW, the diagram assumes that all devices were already authenticated over the DDC lines just prior to the video pixel being sent.)

Brent and Audible Solutions - I understand your explanation that it doesn't work this way. I'm not ignoring that explanation. I'm just having trouble swallowing it at the moment, because of the DCP material and because it leaves HDCP content pretty vulnerable on the line. Thanks for bearing with me.


Last edited by crosen on June 13, 2010 17:43.
If it's not simple, it's not sufficiently advanced.
Post 73 made on Sunday June 13, 2010 at 18:52
Audible Solutions
Super Member
Joined:
Posts:
March 2004
3,246
On June 13, 2010 at 16:22, crosen said...
BTW, the idea that the content is sent on the TMDS stream free and clear of encryption just because the sink was pre-authenticated would not really make for a robust content protection system. This would allow for a "man in the middle" attack. I wouldn't think the industry would have gone for such a solution.

In other words, my understanding of the DCP paper makes sense to me intuitively. This is another reason I feel compelled to clarify and verify these points.

If you go back and read some of what I've written it will seem as if my argument is changing. It's not that I'm attempting to mislead nor am I trying to play games. I am trying to get to see the flow chart without adding further confusion. I edited out encryption of the TMDS because I felt it would move you away from what is happening schematically even if it wasn't completely accurate technically. You continue to focus on the irrelevant. How data is encrypted and read is irrelevant to our installations. You need to understand the process to see where it's been hung up and where to fix it.

Yes, the data is encrypted. The keys are part of this process. Yet the only place it is relevant is for a manufacturer understanding how many keys he needs to purchase for his product to work in a system. The source is simultaneously dealing with keys from sinks and repeaters. The are multiple "links" established. Even while it's technically incorrect my description of the keys as a means of opening a door to validate a system as legal is the best way to understand the process. All devices announce themselves and each will pass their keys to source. But it's not pertinent to understanding the encryption/decryption process nor is it useful in diagnosing a system and fixing it.

Source authenticates sink. Source will accept X amount of keys as valid in a system where X is the number of keys a manufacturer has chosen to support ( purchase ). Source will accept as valid Y number of repeaters in a system which is a function of the protocol. However, why do you think any of this of any importance? This is an academic exercise? You need to understand why the HDCP and EDID handshake work. You further need to understand that there is an audio handshake as part of the EDID handshake and this is the part most susceptible to failure when there are issues on the low speed data bus.

Here is what I think you need to know from the point of view of a CI. Did the HDCP handshake make it? Did the EDID handshake make it? If so you will have a picture. If you are expecting audio and you have the former 2 but no audio you have an EDID issue to solve.

If you have sparkles or the colors are off you have issues with the high speed data bus.

Why do you care at all how devices read the data? You do want to be mindful that there are a finite number of devices that a source will permit before deciding the system is illegal and turning off video. How the repeater strips off the data is important how? For what reason? You're on to a side show that will not help you install, sell or troubleshoot. You are getting lost in the tree of details when you ought to be focusing on the forest.
"This is a Christian Country,Charlie,founded on Christian values...when you can't put a nativiy scene in front fire house at Christmas time in Nacogdoches Township, something's gone terribly wrong"
Post 74 made on Sunday June 13, 2010 at 20:05
2nd rick
Super Member
Joined:
Posts:
August 2002
4,521
On June 11, 2010 at 22:43, dafunkdawg said...
this lady will blow a gasket if I tell her she needs to buy a $300 part to make this work correctly after it has been working flawlessly for almost a year.

"What exactly do you mean when you say I need a $300-400 part to make the cables work correctly?"
Rick Murphy
Troy, MI
Post 75 made on Sunday June 13, 2010 at 20:27
crosen
Senior Member
Joined:
Posts:
April 2009
1,262
On June 13, 2010 at 18:52, Audible Solutions said...
Why do you care at all how devices read the data? You do want to be mindful that there are a finite number of devices that a source will permit before deciding the system is illegal and turning off video. How the repeater strips off the data is important how? For what reason?

I specifically seek to verify whether an AVR repeats inbound video as is (timing issues and all) to the display, or whether there is an element of signal restoration. I'm sure you will agree this is important information for a CI.

(I have been told that there is no signal restoration from the AVR. However, I have also been told that there is no encryption on the TMDS stream. It clearly makes sense to vet any assertion :-)

You apparently do not see the connection between how encryption is handled over the HDMI links and whether the AVR creates a new stream. However, I have presented an argument that there is a connection, and that through this connection it becomes apparent that the AVR does, in fact, perform an element of signal restoration.

Here is argument, again, in a more brief form:

a. if the video stream on the inbound link to the AVR is encrypted using a different set of keys from the video stream on the outbound link from the AVR, then the two video streams do not consist of the same bits. Agreed?

b. also: if the video stream on the inbound link to the AVR does not consist of the same bits as the video stream on the oubound link from the AVR to the display, then the AVR is not simply repeating the inbound link. Rather, it is creating a new one. Agreed?

c. it follows that: if the video stream on the two links are encrypted using different keys, then the AVR is not simply repeating the first link. Agreed?

I believe both a. and b. are true. That means c. is true.

Right or wrong?

Last edited by crosen on June 13, 2010 20:40.
If it's not simple, it's not sufficiently advanced.
Find in this thread:
Page 5 of 8


Jump to


Protected Feature Thread Closed
This thread has been locked. Replies are not allowed at this time.

Please read the following: Unsolicited commercial advertisements are absolutely not permitted on this forum. Other private buy & sell messages should be posted to our Marketplace. For information on how to advertise your service or product click here. Remote Central reserves the right to remove or modify any post that is deemed inappropriate.

Hosting Services by ipHouse