OK, now I"m really confused. I know you are far more knowledgeable than I on HDMI and HDCP. But, I've read from so many different sources that when you have, for example, a BD player sending HDMI with HDCP through an AVR to a display, that you essentially wind up with two separate encrypted streams: one from the BD to the AVR, and a second from the AVR to the display. Moreover, the BD to AVR stream is encrypted using the keys of the BD and AVR, and the stream from the AVR to the display is encrypted using the keys of the AVR and display.

Here's a whitepaper describing this from Crestron's site:

[Link: crestron.com]

ADDING: here are some excerpts:

The HDMI specification defines an interface for carrying digital audiovisual content from a source, like a DVD player, to a sink, or display device, such as a TV. Devices such as switches or A/V receivers may accept and re-transmit HDMI
content, and are known as repeaters.

Repeater devices have two separate HDMI connections: the upstream connection with the source and the downstream connection with the sink (or another repeater). Within each connection, the upstream device sends audiovisual data to the downstream device.

A single point-to-point HDCP link can only involve one HDCP transmitter and one HDCP receiver. As such, a repeater must decrypt the content at the HDCP receiver on each of its inputs. The repeater must then re-encrypt the data with an HDCP transmitter on each of its outputs. The repeater must inform the upstream device of its downstream connections, but it is the repeater's responsibility to maintain those connections.

I can see your confusion and I certainly do not want to upset big blue, but.....
AVR's (unless they have multiple HDMI out's), switchers, baluns & signal restorers do not do anything with HDCP keys (DCP) except pass them on unmolested.
However ANY device that allows a single source to go to multiple sinks (displays) MUST provide keys for each connected sink (as well as itself).
All of our products (SR-1, DAD, Baluns and Surge Protector) are HDMI certified (long before Big Blue got involved) and we did not need to purchase Keys until our 1x4 (DD14) DA came to market.

Just looked over the HDMI.org site and could not find the data on this (site has however been improved).

If the AVR is only passing along HDCP keys and not getting involved more deeply than this, then how is it that the AVR has the ability to decrypt the TDMS streams, which we know it does in order to decode the audio?

In other words, if the BD player is using the key of the display to encrypt the stream (and not the key of the AVR), then the AVR is just a "man in the middle" and should not be able to decrypt the stream.

The AVR doesn't encrypt with a different key. The source needs to authenticate with the display for HDCP/ EDID, the keys are part of HDCP and each display needs to be authenticated by the source. The source is the queen and controls everything. Aren't you happy to know that your system is controlled by a cheap cable box?

The receiver is just playing middleman and passing the data along both ways. However, the repeater does have to identify itself and in some situations will also require its own key. Don't confuse the security keys with the number of devices allowed by the source keys.

Here is a brochure from Honeywell's Curelight cables which Jeff helped them develop. It gives basic information on capacitance problems which I tried explaining before.
[Link: genesiscable.com]

It states "Capacitance is also cumulative – each device or connector adds to the capacitance of the system." The dielectric picture helps understand that multiple pieces will change the dielectric of the system and alter capacitance.

I know you like to think of a signal being perfectly repeated it is not. Relate it to a ground loop in a system. Ground loops are often the difference between the electrical ground and a low voltage ground. But, it travels through various circuits such as a cable box, receiver, speakers, subwoofer, TV, etc to create this problem. Can it be isolated with an isolation tranformer circuit? Certainly. Why isn't this type of isolation transformer circuitry built into receivers, amps, TVs, subwoofers, etc? In a nutshell cost.

The same is true for HDMI. The problem with HDMI is knowing exactly what is causing the problem, cabling or equipment. Like Brent said the AVR often gets blamed for a problem but it might not be the problem.

Please answer me this: if the AVR does not contribute its own key for encryption from the source, then how is the AVR capable of decrypting the TMDS stream?

To the best of my knowledge (I will check with Jeff B) the AVR only extracts audio (which has it's own header call outs) and does nothing with the video (other than overlay OSD).
Audio is not as security conscious as video (you can have audio without a display).
Remember Audio is turned on/off only by EDID, it is not always there.
EDID (DDC) is the intelligence channels that carry the queries and answers between source/sink.
The AVR can tell the source to output (and in HD format if desired) where as the display can usually only reply with two channel (this is important to understand in D/A systems).
This is one case where the AVR can take priority.

The (now) classic "Digital is Digital it is always the same" or even more popular
"Digital is Digital it either works or it doesn't".

Yeah about that.....

There are way too many things that can affect the signal at what appears to be a random schedule, heat, ground problems, age of products (copper does not get better with age), distance effects from power spikes etc.

Just because the same SKU's worked on a job last week does not guaranty that they will do so this week.

Hmm, that's different from what I understood, but it would help explain things.

To be clear about what I understood, I thought that the original source would encrypt the entire TMDS stream (with audio, video, etc.) using the AVR's key such that 1) only the AVR could decrypt the stream sent by the original source, and 2) the AVR could decrypt the entire stream. Then, the same would be true between the AVR and the display (i.e. the AVR would encrypt the TMDS stream using the display's key so that the display and only the display could decrypt the stream.)

Please do let me know what you turn up. I'm really interested to fill in the blanks. Thanks.

I for one would like the brand of the AVR that was a pos. Sounding like I know something that you don't stinks. All you would be saying is that this brand uses an HDMI cable inside the unit. We as CI's need to know what to avoid as much as what works.

To the OP, have you tried a different cable box?

Tried connecting the Cable box via Component?

Excellent thread! Lots of good info.

I have already had my ass handed to me (our lawyer said to shut up).
However it is in a product line that will soon be available at Wally Mart.

And I'd guess its CI brand also has the same problems?:-(

I spent some more time combing through various documents on HDMI and HDCP, and everything seems to reinforce this understanding.

Using the OP's configuration as an example, it really seems like this is how things work:

1. The Cox STB sends an encrypted HDMI stream to the Denon AVR. This stream is encrypted using the key of the Denon such that only the Denon would unencode the stream. If the Denon simply repeated the stream as is to the Samsung display, the Samsung would not be able to decode the stream, because only a device with the Denon's key would have that ability.

2. The Denon AVR decrypts the stream. The audio portion is directed to the Denon's signal processing and amplification circuitry. The video portion (etc.) is then reencrypted and retransmitted through a new HDMI stream to the Samsung LCD, using the Samsung's key for encryption.

In other words, there are two totally separate HDMI streams, with two totally different circuits (i.e. one for the STB to AVR, and another for the AVR to LCD.)

Because they are two totally separate circuits with two totally separate streams, the idea that the TMDS stream showing up at the AVR from the Cox will will up leaving the AVR for the LCD with any signal loss just doesn't make any sense. Why? Because they are two seprate streams. It's not like the AVR is just taking bits from the Cox and resending them.

Any given 0 or 1 showing up at the AVR from the Cox can either be read by the AVR or it can't. If it can't there is a bad signal and that's that. If it can, then that bit is processed by the AVR. It is processed in the AVR as either a perfect 0 or a perfect 1, and is then fed into a new HDMI transmitter circuit for encryption and transmission.

This is definitely not correct. Everything must be authenticated to the source for EDID/HDCP or the source doesn't send the data. I think you are confusing the encryption and copy protection process.

The source originates the copy protection and the devices take that data process it and responds with its answer. If that answer is correct it will send the data. This is the authentication process and the source has to know that the display(s) are compliant. This is all done on the low speed DDC channel. The source doesn't just talk to the AVR. AVRs are repeating devices and not source and sinks themselves even though they have receivers and transmitters and can decrypt and encrypt the data.

Encryption is a secret code that is encoded to the high speed data streams (TMDS channels) so it is not easily recognizable to a device that might be monitoring the data. The AVR (repeater) is allowed to decode this stream and modify it but this stream would not have been sent if the source didn't authenticate with the sink on the DDC channel. Repeaters need to be identified with the source or the source won't send the data stream.

Hope this helps.

Bob