DRM via response times, spoofing it, then preventing that

DRM via response times, spoofing it, then preventing that

My latest half-baked idea involves latency and something that someone might try to do in the name of "DRM" some day. The premise is simple enough: some device might try to ping another to make sure they are not too far apart.

The logic would be simple enough: you can't get any faster than the speed of light, so if the two devices aren't in the same locale, then the round-trip times from a ping will betray your scheme. This might be used to do some kind of geographic content limitations like blacking out certain TV shows (syndex) or the other garbage they do for sports.

So as long as I'm proposing that, let me also put forth a way to fool it. Let's say whoever builds this thing uses the usual Unix-style ping program. ping tends to be pretty deterministic about the packets it puts out. One frequent trick is that it buries its own PID in the outgoing packet. Check it out:

11:26:02.706856 IP 127.0.0.1 > 127.0.0.1: ICMP echo request, id 21105, 
seq 38, length 8
        0x0000:  4500 001c 0000 4000 4001 3cdf 7f00 0001  E.....@.@.<.....
        0x0010:  7f00 0001 0800 a568 5271 0026            .......hRq.&

See that "5271"? My ping process is PID 21105, or 0x5271. Easy.

The "0026" there is just the sequence number, and it increments by one with every outgoing packet. This gives you the "icmp_req=nnn" on each line.

I purposely dialed down the size of the packet with "-s 0". If you make it just a bit bigger - at least 16 bytes - then you'll also get time data back. This is also not hard to spot.

11:31:36.789867 IP 127.0.0.1 > 127.0.0.1: ICMP echo reply, id 21158, seq 
3, length 24
        0x0000:  4500 002c 8bdd 0000 4001 f0f1 7f00 0001  E..,....@.......
        0x0010:  7f00 0001 0000 fe7d 52a6 0003 187c 314f  .......}R....|1O
        0x0020:  0000 0000 590d 0c00 0000 0000            ....Y.......

"187c 314f". Turn that around into 0x4f317c18 and you have 1328643096. The significance of that number soon becomes clear:

$ date -d @1328643096
Tue Feb  7 11:31:36 PST 2012

... that's right now, in other words.

The rest of it probably adds enough precision to have milliseconds and nanoseconds since the ping I'm using can give results like "0.026 ms". If you really want to know, go dig around in the source for your ping.

My point is: given the first ICMP echo request message, you can probably predict everything which will be in the second. If you wanted to look "closer" than you actually are, just eat the first one. Then use what you've learned from it to generate a fake response to #2 and then send it off.

Given this, how would you work around this workaround? Well, first, you could keep track of every packet you send out. Instead of just trusting the incoming data and subtracting it from the current time, go look and see if it's what you transmitted in the first place. Someone who's generating fake responses from far away can't both know what you sent *and* get it to you quickly.

Another step up from that would be using some signed blob of data in the actual ping so that the other end would have no idea what it meant. You'd be able to make sense of it upon its return, but they wouldn't be able to take it apart and fake responses.

Writing this reminded me of the old Telebit Trailblazer modems and the UUCP "g" protocol spoofing they used to do. That was a case of spoofing replies locally in hardware to avoid having them clog up a tiny little backchannel link. While I never ran one of those myself, I did have some fun with both the USR HST with its 300/450 bps backchannel and the V.23 1200/75 stuff used by US Videotel. Such luxury!