or Connect
AVS › AVS Forum › Gaming & Content Streaming › ReplayTV & Showstopper PVRs › Encryption and El Gamal Signature
New Posts  All Forums:Forum Nav:

# Encryption and El Gamal Signature

Quote:
Originally Posted by gatomon

From the El Gamal paper "A Public Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms"

If any k is used twice in the signing, then the system of equations is uniquely determined and x [, the secret key,] can be recovered. So for the system to be secure, any value of k should never be used twice.

This means that each time they updated the time, they had to use a different "k" value (the signature has two parts, "r" and "s"; if "k" is the same then "r" is the same). This would be hard for them to do day in and day out for every time update request. I saw somewhere that someone had recorded Replaytv transactions over several years. If we collect that data, and perhaps find some other similar data, I would be surprised if every "r" value is distinct (you only need to find one instance of a repeated use of the "k" ("r") value.

Furthermore, the algorithm has three steps, The first:

1) Choose a random number k, uniformly between 0 and p - 1, such that gcd(k, p - 1) = 1.

If they do this (i.e., randomly select k), then we have the "birthday paradox" on our side (http://en.wikipedia.org/wiki/Birthday_problem); if they do something like a simple counter, I expect that this can be exploited.

Just think'in,
-Chris

PS: I won't give up until the fat lady sings...

Good stuff.

One of the problems would be to actually determine when the common key was used, as well as a practical algorithm for actually using the weakness you mention in the paper, but that seems possible.

The vtime.pl (time getting) call looks like:

vtime2.pl?time=1079396652&r=ot9oaq10a02yfxdwwo38obv507ofu94z8e

with

time: The time of the request in epoch format.
r: Random alpha-numeric string of length 25 to 35 characters.

According to the 2004 documentation from Josh Stubbs:

Response: The response contains normal http headers for a 200 OK response, along with data. This data appears to be an El Gamal hash. It is believed that the hash is of a concatenation of the time and random strings or a hash of a md5hash of the concatenation of the time and the random string.

By the way, somebody, or somebodies, should probably record some logs of the back-and-forth conversations between the Replay and the Mother Ship while it is still occurring normally, especially including the activation itself. I am worried about re-activiating if I ever have to install a new disk in my unit.

I once did that kind of logging in case this day arrived, but the disk I had the data on had a head crash.

### AVS Top Picks

Thanks for starting a more specific thread.

Hopefully the powers that be will tell us the key(s), but in the meantime we should see if we can find it by other means. Leave the "politics" to the other thread(s). (BTW, I'm pissed off too...)

We need to examine the time request responses to see if we can isolate the "r" part of the hash. Then we could extract as many instances of the "r" from as much data as we can locate. One we have the list, I believe we need to apply an efficient sort on the list, then look down the sorted list for one or more duplicates.

Does that sound right?

-Chris

PS: I have over a dozen 50xx's and several spare disks. I'm thinking of swapping my spare disks into a replay and running the activation procedure, just in case. Any thoughts on this?
Any progress???
I have it. I have never worked for ReplayTV or SonicBlue or DNNA, nor have I had any knowing contact with anyone at those companies from whom I could have gotten it, so I don't want anyone thinking that someone revealed that trade-secret information to me.

I reverse-engineered it back in 2003, taking advantage of an apparent signing error in an early ReplayTV 5000 disk image of the software as released by SonicBlue. If DNNA doesn't release a way to deal with the clock, we can use that key to reproduce the RnsTimeSync exchange to validate the time (perhaps another WiRNS plug-in?)

I haven't released the signing key because it can be used for theft of service with unactivated Replays. However, I will probably make it generally available sometime between now and 7/31, anyway, since there is no more "service" to steal...

I have two 50xx's and one 45xx that are still in use, and I want to continue to use them. (I also have two 55xx's that have never been activated that I got for \$35 each in the final hardware sell-off.)
You, sir, are my freaking hero!

I have been freaking out for the past few days over this.

Since they have stopped all charges for the service according to their announcement, and it will take some time to program something in WiRNS, can you at least release it to the WiRNS developers so they can get started ASAP so we will be ready on 7/31?

By the way, all lifetime and monthly RTVs are now "Activated" by DNNA, so there is no more distinction between the two, so don't let that stop you!

I am assuming this key will allow full guide updates through WiRNS so that not much will change with how we use our existing devices? Like maybe only Replay-Zones will not work (I only use "Season Premiere" and "Series Premier" from the "More, More, More" option anyway).

Anyway, thanks again for letting me know this, as I have been scrambling trying to figure out how I was going to find an alternative in only 6 weeks.
Quote:
 Originally Posted by t.d. I have it.
Wow! Thank you!
Quote:
Originally Posted by t.d.

I have it. I have never worked for ReplayTV or SonicBlue or DNNA, nor have I had any knowing contact with anyone at those companies from whom I could have gotten it, so I don't want anyone thinking that someone revealed that trade-secret information to me.

Hooray!

Please get it to Henry (hdonzis) so he can test it with WiRNS. I'm sure he'd be willing to not release it unless you give him the ok.

Robert
Quote:
 Originally Posted by t.d. I have it.
I think I speak for all of us when I say THANK YOU!!!
That's great news! Thank you very much!
Quote:
Originally Posted by t.d.

I have it. I have never worked for ReplayTV or SonicBlue or DNNA, nor have I had any knowing contact with anyone at those companies from whom I could have gotten it, so I don't want anyone thinking that someone revealed that trade-secret information to me.

I reverse-engineered it back in 2003, taking advantage of an apparent signing error in an early ReplayTV 5000 disk image of the software as released by SonicBlue. If DNNA doesn't release a way to deal with the clock, we can use that key to reproduce the RnsTimeSync exchange to validate the time (perhaps another WiRNS plug-in?)

I haven't released the signing key because it can be used for theft of service with unactivated Replays. However, I will probably make it generally available sometime between now and 7/31, anyway, since there is no more "service" to steal...

I have two 50xx's and one 45xx that are still in use, and I want to continue to use them. (I also have two 55xx's that have never been activated that I got for \$35 each in the final hardware sell-off.)

You see guys, this guy has had it since 2003. Geez. I knew it.
Please send it to Henry, I told him to expect it from you.
And thanks for hacking. We need more hackers. Heh
Quote:

Originally Posted by t.d. View Post
I have it.

If you could release the details sooner rather than later, we could write a module to test a server that would set the clock. I'm a bit of a programmer myself and would be more than willing to assist. Once that works, it could be added as a module to wirns. (BTW, I'm a mac/linux guy; I don't use windows much, but I run wirns in VirtualBox VM on one of my Ubuntu boxes.)

It would also be interesting to see if we could activate a replaytv box. That way, when someone has a disk crash, it's not the end of days...

Also, I've been thinking about those less tech savvy that will have trouble getting all the pieces to wirns, etc. to work after July 31. I was thinking it would be nice to set up a server on the internet for these people. Sort of a wirns service on the net. In the best case, they could redirect their machines to this server (via a small proxy server on a local pc or mac) and resume their replaytv world. I'm willing to help set such a thing up if there is interest. It would be run as a non-profit or for free based on donations.

Sounds like we might get a break on this...

-Chris
Obviously the best solution would be for the community to get access to the subdomain production.replaytv.net and put a proper server up on that so it can just go on.

Boxes can just keep connecting without intervention. No heroic measures.

I wonder what their plans are for that domain? If anyone is calling D&M or DNNA who whoever, ask that question. If they feel the domain replaytv.net has some value we really only need that subdomain. Or access to dns for that subdomain.

I suspect Henry would be able to put up a server that would just answer the connections correctly.
Quote:
Originally Posted by t.d.

I reverse-engineered it back in 2003, taking advantage of an apparent signing error in an early ReplayTV 5000 disk image of the software as released by SonicBlue.

That's usually how the best encryption systems fall.
Quote:
Originally Posted by t.d.

However, I will probably make it generally available sometime between now and 7/31, anyway, since there is no more "service" to steal...

Well, there's several thousand RTVs whose owners want to keep alive. And that probably requires the key.
Quote:
Originally Posted by Steevo55

Obviously the best solution would be for the community to get access to the subdomain production.replaytv.net and put a proper server up on that so it can just go on.

Boxes can just keep connecting without intervention. No heroic measures.

I wonder what their plans are for that domain? If anyone is calling D&M or DNNA who whoever, ask that question. If they feel the domain replaytv.net has some value we really only need that subdomain. Or access to dns for that subdomain.

I suspect Henry would be able to put up a server that would just answer the connections correctly.

I'm not sure what the point of this would be. You wouldn't be able to get individual guide data without setting up your individual WiRNS. And, setting up your individual WiRNS alleviates any need for using replaytv.net. So, I don't see how it would help much to still have servers at replaytv.net which would be unable to serve guide data...

Henry
Quote:
Originally Posted by t.d.

I have it. I have never worked for ReplayTV or SonicBlue or DNNA, nor have I had any knowing contact with anyone at those companies from whom I could have gotten it, so I don't want anyone thinking that someone revealed that trade-secret information to me.

I reverse-engineered it back in 2003, taking advantage of an apparent signing error in an early ReplayTV 5000 disk image of the software as released by SonicBlue. If DNNA doesn't release a way to deal with the clock, we can use that key to reproduce the RnsTimeSync exchange to validate the time (perhaps another WiRNS plug-in?)

I haven't released the signing key because it can be used for theft of service with unactivated Replays. However, I will probably make it generally available sometime between now and 7/31, anyway, since there is no more "service" to steal...

I have two 50xx's and one 45xx that are still in use, and I want to continue to use them. (I also have two 55xx's that have never been activated that I got for \$35 each in the final hardware sell-off.)

Given that DNAA won't even sell you service any more, there is really nothing left to steal, so I don't see any harm in releasing it now. Also, I just pulled a 5504 unit out of my basement (that hasn't had service in 3+ years) and it is now activated and pulling guide data, so they are just giving it to everyone now.

Does this same key work on the 4xxx units? It seems plausible they would use a different key.
Quote:

You wouldn't be able to get individual guide data without setting up your individual WiRNS.

it might be possible to serve the guide over the internet, rather than having an individual wirns (i.e., a public/common version of some pieces of wirns). For example, the users could have a SD account and the server on the internet would use their login credentials to collect the EPG and serve it to the replaytv box of the user.

Just try to figure out how to save more replaytv fans...

-Chris

PS: Wirns is great, but not for the faint at heart.
Quote:
Originally Posted by hdonzis

I'm not sure what the point of this would be. You wouldn't be able to get individual guide data without setting up your individual WiRNS. And, setting up your individual WiRNS alleviates any need for using replaytv.net. So, I don't see how it would help much to still have servers at replaytv.net which would be unable to serve guide data...

Henry

Henry,
Tell me about the architecture then.

Currently my box connects to production.replaytv.net. What is the transaction like? Does my box ask the server for what it wants, or does the server know what my box wants when it connects?

I realize WIRNS only has on it what I said was to be there. Now.

Keep in mind, putting the data on a centralized host would violate SD's contract with Tribune (over client redistribution), so isn't allowed by SD's terms of service.

I'm not saying something can't be worked out, but what you're talking about is a new app, not just "putting WiRNS on an internet attached server".

I don't think DNNA/DirectTV will release the domain, so we'll always need a "private" DNS server.

The configuration still could be simpler than a local WiRNS (pointing DNS to an internet host, no need to install WiRNS), but the new application would need to be written and would have less functionality than WiRNS. I wouldn't expect such a solution before 7/31.

Remember we still don't know what will happen after 7/31. Even if we get a working key, does that key work on all units? We won't know until we try.

Robert
Quote:
 Originally Posted by t.d. I have it. .... I reverse-engineered it back in 2003, taking advantage of an apparent signing error in an early ReplayTV 5000 disk image of the software as released by SonicBlue. If DNNA doesn't release a way to deal with the clock, we can use that key to reproduce the RnsTimeSync exchange to validate the time (perhaps another WiRNS plug-in?) ...
That's great news. Any chance you might be willing to say what software revision is is/was? This is just for the sake of curiosity.

As an aside, I am sure it is possible to set the clock via the ptvio shell, but it's definitely not a process for the average user.
Quote:
Originally Posted by Steevo55

Henry,
Tell me about the architecture then.

Currently my box connects to production.replaytv.net. What is the transaction like? Does my box ask the server for what it wants, or does the server know what my box wants when it connects?

I realize WIRNS only has on it what I said was to be there. Now.

I'd like to see an architecture like this:

1) A single authorization/time server at production.not-replaytv.net (to pick a random host name) that responds to the time requests and allows disks to be replaced. I like this better because it sounds more palatable to D&M and thus less likely to get someone sued.

2) The current WiRNS capability to get guide data from Schedules Direct or other sources and stream mix that with the time/authorization key. This means that we each need a WiRNS box. Maybe some entrepreneur will start selling pre-setup PCs on eBay, for the less PC inclined, like the folks that sell pre-formatted hard drives.

It would be my second choice to embed the key and signing algorithm in WiRNS, because that opens all the WiRNS users up to potential legal challenge. It's un-necessarily adding moving parts. I'm not hard over, and I'm waiting for the dust to settle.
Quote:
Originally Posted by RSaunders

It would be my second choice to embed the key and signing algorithm in WiRNS, because that opens all the WiRNS users up to potential legal challenge.

What legal issues? When they shut down the service, there is no "service" to steal anymore. There is no monetery damage to them.
I would rather see a local key embedded in WiRNS so we don't break the agreement with Schedules Direct.
Internet Server:
If each replaytv box had it's own paid SD account and the EPG data only was served over the internet to that particular replaytv box, SD should be fine. They should be happy with that (more paid users).

I would concentrate on the time set issue first, then downloading the EPG second. If that worked, most of the functionality that people need would be served. After that, issues such as box activation, Zones data, etc. could be addressed if there was interest and resources.

Wirns key:
Putting the key into wirns poses little risk since the pay service is gone. Sure they could sue (you always can sue), but what would they gain? What attorney would take that case?

I fully support adding the signature function to wirns; I would use it. I'm just thinking about the non-tech people (the majority I suspect), that will not survive 7/31 without help.

My 2 cents...

-Chris
Quote:
Originally Posted by SoNic67

What legal issues? When they shut down the service, there is no "service" to steal anymore. There is no monetery damage to them.
I would rather see a local key embedded in WiRNS so we don't break the agreement with Schedules Direct.

Intellectual Property Rights maybe?
Waiting to hear if the key works. Everything depends on that. It is not an insignificant issue to implement even with the correct key. We don't know if there are multiple keys, do the keys work for every model, etc.
Quote:
Originally Posted by gatomon

it might be possible to serve the guide over the internet, rather than having an individual wirns (i.e., a public/common version of some pieces of wirns). For example, the users could have a SD account and the server on the internet would use their login credentials to collect the EPG and serve it to the replaytv box of the user.

And, just exactly how would this common server figure out the user's SD account information, much less that it would then have to download the guide on the fly? If we could change the protocol to include such information, then we wouldn't have much of a problem in the first place...

Henry
Quote:
Originally Posted by Steevo55

Currently my box connects to production.replaytv.net. What is the transaction like? Does my box ask the server for what it wants, or does the server know what my box wants when it connects?

It is a multi-phase transaction which basically starts with the configured ZIP code. The RTV tells the server what ZIP code it has and the server replies with the providers for that ZIP code. The user then picks the provider, and subsequent connections ask for the guide for that provider...

Quote:
Originally Posted by Steevo55

I haven't seen anything since your PM from yesterday...

Henry
Quote:
Originally Posted by Reden

Keep in mind, putting the data on a centralized host would violate SD's contract with Tribune (over client redistribution), so isn't allowed by SD's terms of service.

You're saying that having a single app log into multiple accounts is a violation? I would have thought that having separate accounts in the first place would have been what made it allowable...

So, how does that work for users that need more than four lineups and have to pay for multiple accounts? WiRNS supports up to three accounts, which allows for up to 12 lineups...

Henry
Quote:
Originally Posted by g501

As an aside, I am sure it is possible to set the clock via the ptvio shell, but it's definitely not a process for the average user.

That's an interesting point, if possible! While it wouldn't take care of the problem overall, it would at least take care of the clock drift problem. And, would be quite similar to installing the clock set control panel for ShowStoppers (although, not as easy to use)...

Henry
Quote:
Originally Posted by gatomon

Internet Server:
If each replaytv box had it's own paid SD account and the EPG data only was served over the internet to that particular replaytv box, SD should be fine. They should be happy with that (more paid users).

This part's just not going to happen! Assuming that logging into SD with individual account's wasn't a viloation, there's just no way to have the RTV provide the SD account information in the first place. The protocol is built around the RTV communicating with ReplayTV, and WiRNS just builds on that...

Henry
New Posts  All Forums:Forum Nav:
Return Home
Back to Forum: ReplayTV & Showstopper PVRs

### AVS Top Picks

AVS › AVS Forum › Gaming & Content Streaming › ReplayTV & Showstopper PVRs › Encryption and El Gamal Signature