A determined 'hacker' decrypts RDS-TMC

As told in a previous post, I like to watch the RDS-TMC traffic messages every now and then, just for fun. Even though I've never had a car. Actually I haven't done it for years now, but thought I'd share with you the joy of solving the enigma.[disclaimer 1]

RDS-TMC is used in car navigators to inform the driver about traffic jams, roadworks and urgent stuff like that. It's being broadcast on a subcarrier of a public radio FM transmission. It's encrypted in many countries, including mine, so that it could be monetized by selling the encryption keys.

A draft of the encryption standard, namely ISO/DIS 14819-6, is freely available online. Here's an excerpt[disclaimer 2] that reads blatantly like a challenge:

"After calling for candidate proposals, the submission from Deutsche Telekom was judged by an expert panel to have best met the pre-determined criteria the task force had established. The method encrypts the sixteen bits that form the Location element in each RDS-TMC message to render the message virtually useless without decryption. The encryption is only 'light' but was adjudged to be adequate to deter other than the most determined 'hacker'. More secure systems were rejected because of the RDS capacity overhead that was required."

TMC messages consist mostly of numeric references to a static database of preset sentences and locations; no actual text is being transmitted. The database is not a secret and is freely available. The location information is encrypted with a key that changes daily. Every night, a random key is picked from 31 pregenerated alternatives. The key is never transferred over the air, only its numeric ID (1–31). The keys are preprogrammed into all licensed TMC receivers, and they can decrypt the locations knowing the key ID.

The size of the key space is 216 and the encryption algorithm consists of three permutation operations:

[Image: A cipher diagram beginning with the 16-bit hex words C1A0 and F3D5, labeled 'location' and 'key', respectively. The 'location' word goes into a bitwise right rotation block, controlled by the first nybble of 'key'. The third and fourth nybble of 'key', taken as a single byte, go to a bitwise left shift block controlled by the second nybble of 'key'. Outputs from these two bitwise blocks are XORed. The result is the hex word 85E9, labeled 'encrypted location'.]

The algorithm is simple enough to be run using pen-and-paper hardware, and that's just what I did while creating the above crypto diagram:

[Image: A pink, heart-shaped Post-It note with a hand-written columnar XOR calculation in binary. One of the operands is shifted left from the alignment. The result is 85E9.]

The tricky part is that I don't know the keys. But there's a catch. To save bandwidth, only regional messages are transmitted. This limits the space of possible locations, giving us a lot of information about the encrypted data. Assuming all messages are from this limited region, we can limit the number of keys to a very small number, in the dozens.

The next day, we have an all new encryption key again. But there's another catch. Many messages persist over several days, if not weeks. These would be messages about long-lasting roadworks and such. We just need to wait for messages that we heard yesterday that only have their location code changed, and we can continue limiting the keyspace by collecting more data.

Once we've limited the keyspace to a single key, we can decrypt all of today's messages. When the key changes again, it is trivial to find today's key by knowing yesterday's key and comparing the locations of persistent messages; this is known as a known-plaintext attack or KPA.

Here's some encrypted data straight from the radio.

$ ./redsea.pl | grep TMC
══╡ TMC msg 00 1828 4400
══╡ TMC sysmsg 6040
══╡ TMC msg 00 1828 4400
══╡ TMC msg 07 8264 0294
══╡ TMC msg 07 8264 0294
══╡ TMC msg 07 8264 0294
══╡ TMC sysmsg 0021
══╡ TMC msg 07 5964 72ca
█

A little Perl script then decodes everything and even plots the affected segment on a little map. The screenshot is from a few years back.

[Image: Screenshot of a GUI with the title 'RDS-TMC'. It's divided into three sections. The first one, labeled 'TMC Service', tells that the service provider is 'MMN TMC+', we're using location table 6/17, and the data is encrypted with key number 5. The second section, labeled 'Received messages', shows a scrollable columnar list of traffic messages received, with a one-word description, an icon and rough location. The third section, 'Message', shows the selected message in detail. A map displays the affected road segment. A long event description is printed in Finnish, along with the road name, exact coordinates, speed limit, time of expiration, and the last time the message was received.]

Now I just need a car. Well, actually I prefer motorcycles. But I guess it would work, too.

Tools used: Ordinary FM radio, sound card, computer. All data is from public sources. RDS was decoded from intermodulation distortion in the radio's Line Out audio caused by the stereo demuxer circuitry.

Update 2014-07-27: Some news seem to highlight that I was the first one to break this joke of a cipher. This could be true; I don't really care. In any case, the often-referred-to 2007 work by Barisani and Bianco (PDF 13MB) was done on unencrypted RDS-TMC and no cryptanalysis was involved; "encryption is supported for commercial services but irrelevant to our goals". I encourage you to read it, it addressed some of the real-world security implications of injecting crafted TMC messages into cars.


Disclaimer 1: I will take this post down on the first appearance of any complaint from any party, of course. My intent is not malicious and I'm not even publishing any keys or code.

Disclaimer 2: This use of the above excerpt of the ISO standard is not an infringement of copyright as it is being used here under the doctrine of "Fair Use" of the United States Copyright Law (17 U.S.C. § 107), seeing as this blog is hosted on US soil.

61 comments:

  1. Can you put this up on github?

    ReplyDelete
    Replies
    1. Put anonymously? Information wants to be free

      Delete
    2. There's no way I can anonymously publish the code any more, ever. Also, there is no "proof of concept" that's all in code and ready to be executed. The process involved, for example, handwritten notes about persistent messages and recovered keys. But it should be very simple to implement based on this post. Anyone can do it, I believe.

      Delete
    3. Respect your efforts, hope we can get working online RDS decriptor with usage of simple LCD on Arduino or raspberr

      Delete
  2. To find my local RDS-TMC frequency, what am I looking for?

    As far as I know, Australia doesn't use RDS for anything other than an encrypted TMC broadcast provided by http://www.intelematics.com.au/products-services/motoring-content/traffic-services/suna-rds-tmc

    ReplyDelete
    Replies
    1. You can scan through the stations, decode the RDS and find a frequency that has TMC in its application list.

      Delete
  3. Nice one! You might enjoy reading Bamford's Puzzle Palace if you haven't already.

    ReplyDelete
  4. so, are you coming to defcon somday soon?

    ReplyDelete
    Replies
    1. I was invited to 44CON to talk about something else, and I'm still kind of pondering whether I can write a talk that long. But who knows.

      Delete
    2. I know they do workshops at 44CON. What if you offered to do a shorter talk and a workshop?

      Delete
    3. That kind of sounds doable.

      Delete
  5. I love it :D

    The thrill of solving these kinds of things is one of the main parts why I love my field of work.

    Thanks for writing it down so we can take part.

    ReplyDelete
    Replies
    1. Do share your field of work! For me, it's just a hobby.

      Delete
  6. This reminds me of the type of code breaking they did at Bletchley Park during the Second World War. At Bletchley they had to guess the messages but particularly loved the weather forecast because once they cracked that they had the days cipher ( there where lots of differences but you get the general similarity between weather and roadworks ). I find it particularly amusing you used PERL which is perfect for this and whose origins are also in security field. I only ever saw this system working in Germany. Great work deciphering and documenting it.
    Regards
    John Jones

    ReplyDelete
  7. Huge ! Now it is possible to fuzz RDS data and find bugs within GPS or car radios !
    Could be nice/evil to get remote code execution on cars as I assume GPS and other equipments using RDS are connected to other sensitives parts of the car, and the security isolation must be pretty low...

    ReplyDelete
    Replies
    1. "I assume GPS and other equipments using RDS are connected to other sensitives parts of the car, and the security isolation must be pretty low..."

      You'd be assuming wrong, in general. I won't say it doesn't happen at all, but I am very knowledgeable about the BMW systems from the late '90s on up (IBus and beyond, seen in parts on the E36 but fully utilized in E38/E39/E46) and can say that there the passenger-facing systems are on one data bus while the important systems like the engine, transmission, gauge cluster, etc. are on others. If you somehow got code execution on the radio in my E46 the most you'd have access to is the door locks. Sure, not the best, but if the radio is on the key's already in it, so if I'm not also in it the car is unlocked and running, so it's a moot point.

      From what I've seen when messing with other modern vehicles (VW, Kia, Ford) it's pretty similar across the board. Some parts are on both buses and will proxy specific requests, but they're things like queries for information or selection of performance / economy modes.

      Also, these are a few small, fixed length messages. Not impossible to screw up, but less likely to be exploitable than a variable length freeform text field, such as the RDS RT field, which is entirely unencrypted and publicly documented. That is to say if you want to fuzz RDS, this doesn't really add much of use, the interesting bits were already out there.

      A more "interesting" use of figuring out the keys, aside from accessing a subscription service for free of course, is for pirate broadcasters to add their own traffic events to the system. Obviously that's a fast way to get your local radio authorities interested in your operations though, so experimenting with such in to anything but a dummy load is probably not a good idea.

      Delete
    2. That makes about as much sense as people saying they can hijack your locks to make the car accelerate since the locks lock automatically when you actually accelerate the car. Cause -> Effect does not always go backward.

      Delete
    3. That would be close to what is described in Comprehensive Experimental Analyses of Automotive Attack Surfaces from http://www.autosec.org/publications.html, which is an interesting read.

      The level of protection between critical and non-critical buses apparently was not high enough for their target vehicle(s), as they write that "Consequently, the result is that compromising any ECU with access to some CAN bus on our vehicle (e.g., the media player) is sufficient to compromise the entire vehicle."

      Delete
  8. Did you use some kind of third party lib to get Perl to plot on a map or is it just a image with scaled coordinates?

    ReplyDelete
    Replies
    1. Just an image that I know the corner coordinates of, and that I can then draw on using PerlMagick and crop to fit.

      Delete
  9. Ciao Feds? Hah! Intentional, I guess? :)
    Great work!

    ReplyDelete
  10. Where did you find the locator databases? I guess they have to be maintained so they're not in the standard (or are they?).

    ReplyDelete
  11. What do the yellow boxes with >>> and << in the diagram mean?
    I'm trying to understand what you did on the piece of paper, but can't figure out where the two middle lines used for "xoring" came from.

    ReplyDelete
  12. Sad to request, but can you take thisoffline. It is kind of our service you hacked :)

    Tuomo Eloranta,
    Technology Director
    Mediamobile Nordic

    ReplyDelete
    Replies
    1. "Kind of"? Sure, if that's what you deem appropriate.

      Please send me a cryptographically signed email (windyoona@gmail.com) with the complaint, i.e. some explanation as to how I'm infringing your IP rights, and which parts of the post are infringing and should be removed. I will replace them with [deleted as requested by Mediamobile Nordic].

      Also, please provide me with a means of verifying the signature and sender, preferably a public key at a URL under your company domain.

      Delete
  13. Please ignore Eloranta's request. His company sells this service. He does not provide sufficient justification for censorship.

    ReplyDelete
    Replies
    1. Well, he might have a legal angle anyways, so heeding a complaint is an understandably prudent thing to do. But indeed it is also wise to ask for specifics, and to ascertain that he's actually representing the company (after all, one wouldn't want to aid some pretender in smearing the company name).

      I'm guessing this post is getting a fair number of persistent copies made at this time.

      Delete
  14. Hi,

    The size of the keyspace is s^16, but there are far fewer actual keys. Docs say:
    "To minimize the overhead potentially required when encrypting data, the parameters used to encrypt the location codes are stored in eight Service Key tables in the terminal equipment. Each of the eight Service Key tables has 32 “lines”. Each line gives the values of three parameters used to encrypt the 16 bits of the location code."

    256.

    ReplyDelete
  15. I actually think you have your copyright footnotes shifted the wrong way round.

    1. It is very hard to block you from publishing what you've just published. In no way are you explaining any of the secret parts of the encryption. Instead all you did was reference some publicly available data on how the algorithm works and then explain how a crypto analytic attack on the code would work. What you do not do is explain this in great detail. You do not give a list of the location codes that are in use, nor do you give the key. With the standard in hand , that contains a description of the algorithm, any trained analyst should be able to write this blogpost. As a result the company can't really do anything. The crypto analytic and digital signal analysis literature contains many such examples.

    You do say however that you can cite Fair Use of the ISO standard, because the content is hosted on a server in the USA. That is incorrect. Most of the jurisprudence focuses on where you were at the time of writing and the intended audience. The location of the server is only relevant in case the courts want to seize something. And BTW you may know of the converted paper mill that Google has in Harmina, Finaland. So you should evaluate whether there is a citation right under Finnish law and jurisprudence. You should also check whether somehow someone can make a case against you based on your relations with another country.

    Now your mileage may vary, so always verify with a lawyer that understands Finnish copyright law and rules and regulations on reverse engineering and crypto.

    ReplyDelete
    Replies
    1. You are correct in that I'm not legally bound to remove anything. But I kind of promised to be nice. However, there are limits as to what I consider a "complaint" and a "party".

      Use of the citation also complies with the Citation Right of the Finnish Copyright Law (22§). I made Disclaimer 2 because the standard explicitly forbids any citation unless allowed by law.

      Delete
    2. I have a judgement under Finnish law against me for hosting a service where a friend posted some homebrew Haskell DeCSS code along with commentary (among others, but that was the one they decided to pursue).

      That does not fully apply to this case since as you said, Oona didn't publish any code. However, this is a form of DRM, and the law says that even offering service that _helps_ circumvent it is illegal. Service is vague, but a blog dedicated to such evils as "hacking"? I wouldn't put it past the courts to judge it to be one, when my mailing list qualified as well.

      One could probably argue that the stuff being accessed is not actually copyrightable, but that's always a can of worms, especially with our European database monopoly rights or whatnot.

      So the legal situation is actually way murkier than it would be in a sane world, and unscrupulous companies are within their legal rights to exploit that (hi, Tuomo).

      (And yeah, that comment is "kind of" a complaint but not really... The "kind of" is especially vague. Is it or is it not, do they have standing for anything?)

      Delete
    3. For future reference:
      -log into tor
      -upload source code to www.pudn.com, it is a source sharing site. You can find stuff there like factory workers uploading whole design files they got from US firm to manufacture (including source code, gerbers, case design). Basically its repository for Shanzhai manufacturers :)
      -wait few hours and make a blog post about this kewl code you just found
      -wait two weeks for first clones to appear on the market

      Delete
  16. The pink heart-shaped paper is a nice touch.

    ReplyDelete
  17. Kudos to you. Interesting blog post. Shame I don't have even the first clue what "RDS was decoded from intermodulation distortion in the radio's Line Out audio caused by the stereo demuxer circuitry." means but that just shows the shortcomings in my own education. :-) Thank you.

    ReplyDelete
    Replies
    1. That piece of text is a hyperlink - follow the hyperlink :)

      Delete
    2. I did - and interesting reading it was too! I do get the general principles (and this is what makes the posts interesting), but it's the technical nitty-gritty I'm struggling with! Like I said though, just my ignorance, not your posts.

      Delete
  18. Well done indeed! Congrats on your passion for this hobby, and your principles staying pure. This level of devotion and play-nice isn't something I see all that often. Especially in a potentially ego-teasing field (I agree the standard reads like a challenge.) I'm in so much respect for the way you are handling your discovery here.

    And that your passion will most likely lead you away from this and on to the next cool thing to stumble into your scope's screen.

    Bleassings!

    ReplyDelete
  19. So, wait a second. The key space isn't even 2^16, is it, since the top bits of the lower 8 bits of the key are actually shifted away, depending on what the second-most-significant hex digit says, right? In fact all keys x800 .. xFFF are all identical, no? What a ridiculous scheme. There are 16*256 + 16*128 + ... 16*1 -> 16*511 + 8*16 = 8304 unique, canonical keys, by my back of the envelope calculation.

    ReplyDelete
    Replies
    1. Err, just 8192 unique keys. Not sure where the 8*16 came from.

      Delete
    2. Yes, that would be 2^13. I'm not sure whether this should actually be called encryption at all, or perhaps scrambling or something like that. But that's the term they like to use.

      Delete
    3. $ for s in `seq 0 15`;do for v in `seq 0 255`;do echo $((($v<<$s)&0xffff));done;done|sort -u|wc -l
      1280

      That makes 16*1280=20480 unique keys.

      Delete
  20. You mentioned some books on cryptanalysis, would you mind posting a few you'd recommend?

    This is really a great site!

    ReplyDelete
    Replies
    1. Thank you.

      As a teenager, my introduction to cryptanalysis was a declassified U.S. military field manual, called FM 34-40-2, that I printed out and bound as a little book. It is most probably available online as scanned images.

      Delete
  21. Brilliant!! My question is how to feed the decrypted TMC messages onto the car CAN bus to display on the car navigation system? Any ideas?

    ReplyDelete
    Replies
    1. As I said, I don't have a car or driver's license so I can't really try that kind of stuff out.

      Delete
    2. Related research from 2007 http://www.defcon.org/images/defcon-15/dc15-presentations/dc-15-barisani_and_bianco.pdf

      Delete
    3. Yeah, I met Barisani at t2infosec :)

      Delete
  22. Nice work no doubt! Since I've written TMC broadcasting systems it's nice to see that some people are enjoying them. :)

    ReplyDelete
  23. HI Oona, Nice JOb,
    maximum respect :)

    ReplyDelete
  24. I once owned a Michelin TMC gps: it shows a "hitparade" of TMC messages, "hitparade" in "distance" meaning, from close to further away. I bought a RDS TMC antenne for my Tomtom, but even when I plan a route over Brussels it doesn't give me no messages... Maybe I'm not close enough (120km) ...

    ReplyDelete
  25. Your blog is fascinating. I like how in this post, your method of attack is similar to the attack-from-guessed-similar-messages, famously employed to crack the Enigma cipher. Now I'm wondering if your first paragraph contains a subtle reference . . .

    Keep it up!

    ReplyDelete
  26. I like your blog and for a while I'm also tinkering around with decoding RDS/TMC/TMCpro. I pretty much like how simple they made the "encryption" and that they actually did it on purpose. To cite ISO 14819-6: "The encryption is only ‘light’ but was adjudged to be adequate to deter other than the most determined ‘hacker’."

    Please note that a similar brute-force attack like yours has already been described here: http://www.mikrocontroller.net/topic/229218. Unfortunately, it's in German. Watch out for the first post by user "Simon Budig". He claims that he's done successful brute-force attacks back in 2011 or before.

    ReplyDelete

The comments section is pre-moderated; it will take some time for the comment to show up.

You might want to check out the FAQ first.