Huh? I'm not certain why you are talking about authentication? I am referring only to the encryption. I fully understand that the AVR communicates with the source for authentication of downstream devices. However, authentication has no bearing on my point.

Perhaps if you could point out a specific aspect of my post that is not correct, that would help resolve this.

You don't understand. I know you think you do. You've been told 3 times yet you still confuse the HDCP authentication with the encrypted data of the high speed data stream. High speed data also includes the audio data stream. This data does not require authentication.

No data is sent till source and sink communicate and authenticate each other. This is done via low speed data or DDC channel. The AVR has nothing to do here but pass this signal on to the sink. It does not look at it. It does not decode it. It does not alter or change keys. It passes the DDC data on to the sink. In fact the source and sink manufacturers have no control over this data. They are purchasing chips and these chips are handling the data handshake. The CE manufacturer is purchasing these chips and allowing data to enter and leave. What happens to this data in these chips he has no control. The return communication from the sink to the source all passes through the AVR without the AVR doing anything to it. These are different data streams. In fact authentication is more akin to serial data. The CE manufacturer will "touch" the high speed data for video and audio but do nothing with the authentication data save pass it from chip to chip.

You might begin to comprehend my questioning of how JAP handles its authentication because they do stop sink and source from authenticating each other.

At the point that source authenticates that the sink is valid the high speed data is sent. If not no data is sent and there's a black screen. It is this data that the AVR is decoding. Even here, it is only the audio portion that it will touch. The audio has its own header and the AVR is parsing the data stream for this header and only stripping out these bits from the data. All the rest is passed on. It may be buffered, parsed and then pushed out. But it's not being retransmitted as you imagine.



These are different data streams. Authentication data is low speed and has nothing to do with the audio and video data streams. The AVR never does anything to the low speed data. Once the high speed data begins to pass from source to sink the AVR will parse this data without destroying it. Holding the data in a buffer while parsing it and then passing it back out to sink is not retransmission.

Alan

Unless I misunderstood him, Brent told me audio was part of the low speed data.

Hmm, well even after reading this post, I still think I do and that everyone is misunderstanding me, but let's see if we can't straighten this out.

To begin, all of my points have been on the high speed (TMDS) data.  This is where the encryption is applied.  I imagine we can all agree on that.

The OP complained of sparkles, and this means an issue with the high speed data.  I imagine we can agree on that, as well.

My point is that the high speed data must be retransmitted "from scratch" because it is sent with an entirely new key for encryption.

My point has nothing to do with the low speed data.  I do not intend to make any claim about whether it is passed through or retransmitted.  It's not that I am confusing this low speed and high speed data, it's that the low speed data has nothing to do with my point.


I did not know that this doesn't require authentication.

EDIT: Actually, I'm not sure what this means. I initially thought you meant that the audio portion of this does not required authentication, but that doesn't really make sense. If you're saying that there is no authentication performed directly on the TMDS lines because the authentication is already done before the stream starts out of band on the low speed lines, then of course I know that.

However, as I've said, I don't believe my point has anything to do with authentication.  The audio data is still sent encrypted over the high speed TMDS stream.  That's what I care about.


That's fine.  Again, I am referring to the high speed (TMDS) data.


This is the crux of the issue. Let's look at this video data. When it arrives at the AVR, it is encrypted using the keys of the BD player and AVR, right? When it is sent from the AVR to the display, it is encrypted using the keys of the AVR and the display, right? It may be the same underlying data, but it is encrypted with different keys. That means it is not bit for bit the same when it is on the line. That is why I assert that it is being retransmitted.

Sorry to be daft, but I still do not see what I am missing.  If you could specifically address the last few sentences (in bold), that would help.

The audio is definitely part of the high speed (TMDS) stream. If I'm wrong about that, I'll retire the discussion, as this is the underpinning of my whole point!

While my points have applied to the high speed data - and that is what I am most concerned about in this thread - what you describe here actually conflicts with what I understand about the low speed communciation, as well.

The previous link I posted ([Link: crestron.com]) describes the authentication process as working differently from how you describe. Specifically, a multi part authentication process is described when a repeater is involved, and in this process the repeater (i.e. AVR) plays an active role in gathering downstream device info and sending it back up to the source in the form of an HDCP tree that the repeater assembled.

The document also establishes that the source authenticates directly with the repeater in the first part of this process. So, again, the AVR is not just dumbly passing info back and forth, but rather creating it's own data.

If you think about it, this makes sense, since the repeater has in hand an unencrypted signal. If the source did not authenticate the repeater, that would setup the system for a breach.

Here's an excerpt from the paper:

Authentication Part 2
Part 2 of authentication only occurs if the downstream device is a repeater. The purpose of Part 2 is to inform the source of all downstream devices and the HDCP tree depth. The source uses this information to ensure that the tree topology maximums haven't been exceeded and to ensure that none of the downstream devices have been revoked by DCP.

The repeater first assembles a list of the KSVs of all downstream devices, as well as the device count and the tree depth. The repeater then passes this information up to the source. To ensure that this information hasn't been tampered with during transmission, each device takes this list, appends its secret value M0/M0' from Part 1, and calculates a SHA-1 hash of the whole thing. The transmitter reads the

Audio is part of the High Speed Data (it is overlayed on the Video Feeds).
It is however controlled by the Low Speed Data like this.

Source to Display with no AVR.

Source: Do you want audio?
Display: Yes.
Source: How would you like that audio delivered?
Display: Dolby 2.0.
Source: Is there anything between us?
Display: No.

Source to Display with AVR (with audio capture enabled).

Source: Do you want audio?
Display: (No answer)
Source: Is there anything between us?
AVR: Yes I am here.
Source: AVR Do you want audio?
AVR: Yes.
Source: How would you like that audio delivered?
AVR: Dolby HD.

Note:
Video is not effected as a passthru.
Audio is captured by the AVR (source treats it is display, this is expected by the source).

The below spec is a bit dated, but unless it changed significantly (or I am misreading it) then I believe you have a misunderstanding about how the HDCP authentication works when an AVR is involved.

If the AVR is capable of accessing the encrypted audio stream, then it is behaving as an "HDCP Repeater", and as such does not simply pass authentication messages blindly back and forth. Rather, it first authenticates with the source, and then gathers information about downstream devices in order to send its own authentication messages describing those devices back to the source.


Please see page 10.

[Link: digital-cp.com]

I see now, you are confusing an HDMI repeater with an HDCP repeater.
Two different things.
I am watching Dr. Who now and will fill in more after its over.

OK, thanks - I'm very keen to get this sorted out!

BTW, a key distinction that I'm making is between an AVR that does note extract audio and one that does. One that does not extract audio obviously does not require any keys of its own or to participate as a node in the authentication. (And, as such, can just physically repeat whatever bits show up to the downstream device.)

However, the AVRs we're talking about all do extract audio.

Thanks, again.

The AVR will anounce itself as a repeater in the HDCP and EDID handshake. Announcing itself as a repeater does not make it a sink. Nor is it retransmitting keys. It's simply letting the system know it's there.

You have the source. It asks who is out there? It gets a response from the AVR that a repeater is present. It gets a response from a display that a sink is present in the system. Sink then is authenticated by source. High speed data is then sent.

In the document above, retransmission means pass through. It does not mean retransmit as in a network switch retransmits the data. It means the data into the repeater is allowed to pass out of the repeater without being turned off.

It announces itself as a repeater it is condered a valid part of the system by the source so the source will not turn off data. But it's not a sink. Without the sink no data is going to be sent.

Try the following test. Connect a cable box to an AVR and disconnect the sink.
Tune to channel. Do you hear audio?

Add the display to the signal chain. Do you have picture? Do you have sound? Remove the display from the system. What happens?

Part of HDCP is that each device announces itself every 1.5-2s. As soon as sink stops communicating the system ought to shut down. As part of the low speed data issue, the aduio chat between source and AVR is the one most apt to be lost when system limitations are encountered. EDID is passed and understood, HDCP is passed and understood. Video data is sent from the source and decoded successfully by the display. Only no audio. The Display did not hear the quarry, failed to respond to the source to send audio and the no audio flag is set.

Concptually this is much more simple then you are making it. The AVR is not passing on a new set of keys. It is setting the repeater flag high and so informing the source that it is a legal device called repeater and that it will be the data on to sink

Sparkles are not part of the low speed data. They demonstrate issues with high speed data transmission. The eye pattern is not correct. Skew, the RGB timing, is off sufficiently that the error correction built into the system cannot compensate

I presented an argument as to how the AVR is not simply passing data through, but rather is creating a new outbound stream. I have been told that my argument is wrong and that I am confused, but I don't believe anyone has yet provided any consistent and/or cogent explanation as to how I am mistaken.

Once again, here is the argument, which I will break down into numbered points to hopefully facilitate a counter argument. The context here is that a source is sending data over HDMI through an AVR to a display, and that the AVR is being used to strip out and play the audio portion of that data.

1. When a source sends HDCP protected data via HDMI to an AVR, the TMDS stream between the source and the AVR is encrypted using the keys of both the source and the AVR.

2. This stream, therefore, can only be decrypted by the AVR. That is, if any portion of the TMDS stream were forwarded bit for bit to the display, the display would be uneable to decrypt that data.

3. When the AVR sends the video portion of the data carried in this TMDS stream on to the display, it does so by taking the unencrypted video data extracted from that stream and then encrypting that data using the keys of both the AVR and the display.

4. The video stream portion of the TMDS stream sent from the source to the AVR is therefore comprised of an entirely different set of bits then the video sent in the TMDS stream from the AVR to the display.

(While the decrypted version of both streams would contain the same bits, the encrypted version - which is what appears on the line - contains entirely different bits because the bit streams result from applying encryption using different key sets.

That is:

a. The bit stream from the source to the AVR is derived by encrypting the original video stream with keys from the source and AVR.

b. The bit stream from the AVR to the display is derived by encrypting the original video stream with keys from the AVR and display.

So, again, these two bit streams are not comprised of the same sequence of bits.)

5. Since the stream from the source to the AVR is comprised of entirely different bits than the stream from the AVR to the display, then it is not possible that the AVR is just passing bits through. Rather, it must be creating a fresh stream of bits in the link from itself to the display.

CONCLUSIONs:

A. Provided that the bits in the signal arriving in the TMDS stream at the AVR can be decoded successfully to 0s and 1s, then the AVR should be entirely capable of generating a perfect TMDS signal out to the display.

B. Any signal loss in the link from the source to the AVR is, therefore, of no consequence to TMDS portion of the link from the source to the display UNLESS the signal loss (or skew, etc.) is enough to prevent the AVR from parsing that signal. If the AVR can parse the signal, the output of that parsing is a perfect stream of 0s and 1s. And, that perfect stream of 0s and 1s is what is fed as input into the HDMI transmitter that creates the stream going out to the display.

C. The AVR, itself, should not be a source of signal loss, as would be the case if it were simply passing along the signal as do baluns and other devices that are not, in fact, producing a new stream.


Now, I am not asserting that I am 100% certain this is all true. However, given all of the information available to me, it certainly seems to be so.

If anyone sees where this argument takes a wrong turn, I would very much appreciate if they could point to the specific (numbered) point and describe exactly how that is the case.

Thanks,

Brent, I really like the way you explained that. It's the technical equivalent of "See Spot Run." Makes it all easy to understand.

So, if I understand correctly, I can hook up HDMI and it works.:>

Crosen:

I am about to do something that I do not think I have ever done on any forum
(and I know at some point I will regret this).
"WTF".
You are worrying about stuff that even product designers do not need to worry about and making assumptions based on a misreading of the data.

At this point I have to think that you are spending way too much time on AVS listening to the "Digital is Digital" crowd (after all a cheap cable is just as good as an expensive one), you are really putting more into this than there is.
Also after all of the reading and research that you have done on this I find it hard to believe that you still think receivers should be zero loss.

Lets start with what a digital signal (1 & 0) really is.
Digital Data is just a voltage on/off relay that works really fast a "1" is voltage on and the "0" is voltage off.

Think of 4 light switches on the wall direct connected to a bulbs (Red, Green, Blue & Clock) that must see between 4.7 & 5 volts with 50 mA each to work (this voltage/amperage is augmented by the vast majority of inline HDMI devices) .

Remember that there is 1dB of signal loss per meter of cable (assuming a good cable) plus 1dB of loss per contact point (this does not take into account added issues so as timing, impedance and trace EQ) & 1dB of loss thru circuit board.

Most sources (not including CATV STB's which have less) start with about 22 dB on signal.

Option #1: Switches direct to bulbs at 6 meters with no connection points.
Only 5dB of signal loss as there are no added points of contact.

Option #2. Switches thru AVR (1 meter cable) to bulbs (still 6 meters).
Loss here is 9dB.

At this point we have lost just under 50% of starting signal headroom (which may have been poor to start with).

There is no such thing as a zero loss device (think about your Fax machine or photo copier).

Now to the above loss lets add timing problems as this is what causes many of the real world problems.

All four of the above listed switches must keep the signal switching in a very small time window, this time window is established between source/display by the clock feed.
Here is where the real problems start.
Pull a dollar out of your pocket and look at it in side profile, the thickness of that thin slip of paper is the max allowed variance between the four feeds in the High Speed signal path (the whole signal path including source, cables, AVR and display).
If any one of the feeds has a different overall length it will affect how the signal is reintegrated at the display (what this means is that when you look at an "EYE" pattern you must look at ALL four over layed, as just one does not tell the story).

AS this is just the High Speed side we must now add to it the low speed data (to which all of the above applies).

Actually that fact that this works at all is really amazing.