Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Security Remeasured


Ed's an EE, PE, and author in Poughkeepsie, NY. Contact him at [email protected] with "Dr Dobbs" in the subject to avoid spam filters.


Cryptography revolves around the keeping of secrets: knowing things that others should not. Although the only certain way of keeping a secret is to never tell it to anyone else, useful secrets require at least two people in the know. Keeping everyone else out of the know is the hard part.

Understanding the hardware and algorithms of a particular crypto scheme is easy compared to the challenge of actually deploying a secure system. Classic security can lock down point-to-point communications between a few relatively secure locations. We're discovering the inadequacy of those techniques applied to widely deployed embedded systems.

In recent months, I've read of several incidents that show how secrets sneak out of their crypto containers. Embedded systems with long lifetimes must keep secrets from their users, so these attacks reveal only the leading edge of the wedge.

Cracking RFID

In my January column, I related the story of how to get a month's free gas from a stolen SpeedPass token. Shortly after that column went read-only, a group of researchers from Johns Hopkins and RSA Laboratories described their SpeedPass crypto crack: You can now get a month's free gas without even touching the victim's keyring.

The SpeedPass payment system lets you buy gasoline by simply holding an RFID token near a reader in the fuel pump. Each token contains a Texas Instruments Digital Signature Transponder (DST) chip powered by the radio-frequency energy from the reader, so it can operate without batteries inside a sealed housing. Each DST has a unique, hard-coded 24-bit serial number and a programmable 40-bit signature (essentially a crypto key), a radio transponder, some special-purpose crypto hardware, and barely enough compute power to make it all work.

The 24-bit serial number identifying the token links into an account entry in ExxonMobil's customer database, which contains the 40-bit signature for that token. The RFID reader and token engage in a challenge-response handshake to verify that both sides know the same signature without exposing it to public view. If they agree, the reader activates the pump, the charge appears in your database entry, and away you go.

In pragmatic terms, this might not be a whole lot faster than swiping a credit card through the adjacent card reader, but it's attractive enough to be marketable. You can also buy junk food and other necessities using a SpeedPass, which might be faster than cycling your wallet at the head of a line at the counter.

The 40-bit signature is the system's only secret, despite a few other flourishes. Because formulating the challenge-response handshake requires knowledge of the signature, there should be no way to extract the signature without knowing it in the first place. Note that the customer does not know the secret, and in fact, the SpeedPass system design depends on that lack of knowledge.

However, because the customer possesses the hardware containing the signature, the initial attack can take as long as required. It turns out that extraction uses off-the-shelf hardware, a dash of cryptanalysis, and computational brute force. I won't repeat the researchers' analysis here, other than to observe that it's a great example of what notable experts can accomplish with a gaggle of talented graduate students.

The end result is a hardware system that can extract the 40-bit digital signature from any SpeedPass token without first knowing the signature, given just two challenge-response transactions. A token can handle eight transactions per second, so acquiring the data is essentially instantaneous and, because it's RF, doesn't require physical possession of the token. A few hours of computation on a special-purpose parallel processor, which costs a few kilobucks, suffice to crack the crypto and produce the signature.

The researchers project that some engineering and a touch of Moore's Law can increase the range to a few feet, stuff the machinery into an iPod-size case, and shrink the cracking time to a few minutes. The attack scenarios include sniffing SpeedPass tokens at a valet parking station (just wave the victim's keyring near your pocket) and walking the length of a subway car or mall holding a neatly wrapped package containing a big antenna.

The SpeedPass system's fraud-detection logic trips on excessive purchases, impossible locations, or atypical usage. However, if you harvest a few thousand tokens and use each one exactly once, you can probably get free gas for a long, long time.

While longer keys and tougher crypto may delay the inevitable cracks, the basic principle seems to be true: You cannot keep a secret from someone if you give them the secret. Seems obvious, doesn't it?

As is typical of widespread embedded systems, quickly replacing or updating the entire SpeedPass infrastructure to use better token hardware is essentially impossible. The only short-term defense against this type of attack involves wrapping the token in aluminum foil to shield it from cracked readers.

Designers of always-on devices, take note!

Cracking Trust

My February column discussed the mechanics behind the Trusted Platform Module (TPM) found in some recent laptops and desktops. Several readers pointed out that the "Trusted" part of the name has a peculiarly Orwellian definition: In actual fact, many software and media companies do not trust their customers. The companies depend on hardware to increase the effort required by customers who might otherwise easily steal their software, data, or (shudder) music.

The essential TPM feature is a secure hardware-storage mechanism, typically a single-chip micro or a few chips within an armored package, holding crypto keys, digital signatures, or hash values. Well-validated protocols allow external access only by trusted programs with the appropriate secrets of their own. You can't even examine the information without destroying the TPM, quite unlike secrets stored on disk.

Software running on the PC can validate itself using hashes stored within the TPM, authenticate itself to programs running on external servers using digital signatures from the TPM, then download and store data that requires further crypto keys for access. As long as the secrets stored within the TPM remain unknown to the PC's user, the whole chain of trust from musical source to hard drive remains unbroken.

Sounds iffy to you, too, huh?

To build a system using Trusted Platform Modules, manufacturers must have access to documentation and sample parts long before production begins. The Inquirer reports that Infineon will not support small manufacturers or system integrators, claiming that they will supply TPMs only to "qualified" customers. The story doesn't go into much detail, so we're left with suppositions rather than facts.

The researchers who cracked the SpeedPass had some support from Texas Instruments in the form of development kits and sample DST tokens, as well as their own SpeedPass tokens and car keys. They did not have access to the DST's internal logic diagrams or other proprietary information, and in fact, discovering how the DST worked formed a major part of the effort.

Infineon may believe in "security through obscurity" or there may simply be licensing issues that we don't know about. In any event, if the security of the whole Trusted Platform Module infrastructure depends on keeping the documentation out of the hands of the bad guys, it doesn't stand a chance.

Cracking The Wall

Perhaps the single most obvious (and most touted) feature of Linux systems is their immunity to Windows security flaws. Linux and GNU software may present a compelling TCO justification, provide generally higher reliability software, and reduce the time to get bugs fixed, but security seems to be driving a broad-based change of opinion in their favor.

One unfortunate side effect reduces Linux system security to sound bites: "Linux is immune to viruses" and "Crackers don't bother Linux systems" and so forth. While Linux eliminates many of the common exposures, it cannot completely solve the problem.

One member of the Mid-Hudson Linux User Group noticed that his system had begun behaving strangely and asked for advice. His first post to the LUG's mailing list was titled "Have I been cracked?" and noted that:

I don't recall making an account called 'systens', but apparently, someone ssh'd into it from 200.96.xxx.yyy. 'host' returns this info about that address...
yyy.xxx.96.200.in-addr.arpa domain name pointer 200-096-xxx-yyy.cpece7021.dsl .brasiltelecom.net.br.
brasil telecom? uh oh.

Mainstream Linux distros install and enable software firewalls by default during installation. In this case, however:

I am running a firewall through my physical router. The inbound ports I open are for ssh, http, https, smtp, pop, 8080, and 81 for apache tomcat, ftp, and dns. [...] I'm not running a software firewall on the box itself though.

By default, hardware firewalls block incoming packets that are not related to previous outbound messages. If you are running a server on your system, however, the firewall must pass incoming connection to a particular port directly to the server, which means the server is directly connected to the Internet. Any security flaw in the server provides a direct link into the system:

Now that you mention it. I had a few CMS packages running on there. Namely, tikiwiki, drupal, and blog::cms. I locked down one of the tikiwiki instances [...]. The other instance was open to the public for use and anyone could use it - not as admin, but with rights to modify the wiki and add forum entries, etc.

Tiki systems lets users create and update web pages from their browsers, which means anyone with a web browser can change files on the system. Any security flaw provides an opening:

Saw this vulnerability in the tikiwiki web site of mid January. [...] The vulnerability, initially, lets a user get a sort of shell on the server under the web server user. From then on, it is just a matter of time.

With the Web and tiki servers exposed to the Internet, your "users" can, indeed, be anyone:

I bet that was it. I'll check my logs tonight when I get home. The 'systens' user account apparently was created on the 23rd - just one short week after this flaw was apparently reported.

Once an intruder has gained access to your system, becoming root isn't all that difficult and after the intruder is root, all manner of things become possible. If you don't use secure passwords on all your internal accounts, things become even more interesting:

I ran across this in my "/var/log/auth.log" file...
Feb 19 22:13:03 debian sshd[3020]: Accepted password for root from 192.168.1.1 port 3064 ssh2
This is curious because 192.168.1.1 is my router. [...] Is this just a bug in the router (I DO have NAT enabled) or something more I should perhaps worry about?

About a year ago, I described the process of cracking a router and uploading new firmware. I also observed that most users never change the admin account's password. That turns out to be a necessary, but not sufficient, security step:

My firmware is up-to-date, and I don't have remote access turned on. [...] However, I did use the same password for one of my accounts as I did for the router setup. So, in theory if that rootkit could crack passwords it could also allow access to the router.

The consensus advice for cleaning up after an intrusion boils down to two steps: reformat the hard drive and reinstall everything from scratch. You cannot assume anything about the compromised system—any command or program may do anything, including spoofing innocent return values.

In fact, you cannot assume anything about the status of any systems connected to the local network. In this case, the compromised router provides a direct link to the internal network, so restoring the compromised system wouldn't eliminate the vulnerability.

The lesson to be learned from this adventure is the inadequacy of simply keeping the patches to an Internet-facing system up to date. You must also monitor the system logs, become familiar with "normal" operation, and track down any anomalies to their source. That this level of involvement far exceeds the abilities or interests of most PC users, alas, goes without saying.

A Windows XP SP1 system without a firewall will be compromised in minutes, while a firewall completely eliminates incoming attacks. A firewall with open ports requires meticulous system security practices on the systems exposed to the Internet. In the end, however, firewalls and up-to-the-minute patches form just the first line of defense. Attention to detail must provide defense in depth.

Pop Quiz: What do we do with always-connected embedded systems with no user interface? Essay: Describe the user manual's section on network security.

Reentry Checklist

More on the SpeedPass RFID tag cracking adventure at http://rfidanalysis.org/. You should definitely read their preliminary research paper at http://rfidanalysis .org/DSTbreak.pdf, which does not provide quite all the details required to crack SpeedPasses on your own.

The Inquirer article on Infineon's TPM policy is at http://www.the-inquirer.com/ ?article=21113. Everything Infineon has to say about its TPMs, at least to us, seems to start at http://www.infineon.com/cgi/ecrm. dll/ecrm/scripts/prod_ov.jsp?oid=29049.

An overview of Digital Rights Management and online music from a Canadian perspective at http://www.pch.gc.ca/ progs/ac-ca/progs/pda-cpb/pubs/online _music/tdm_e.cfm, which uses a different definition of "TPM" than you see here.

Magnatune carries music released under the Creative Commons license at http://www.magnatune.com/, entirely without DRM. Streamtuner for Linux simplifies access to a myriad audio streams at http://www.nongnu.org/streamtuner/, which is completely different from whatever's offered on the stub page at http:// www.streamtuner.com/.

Writeups of the Linksys router flaw are at http://secunia.com/advisories/11754/ and http://www.wi-fiplanet.com/news/ article.php/1494941. An experiment measuring "system time to live" on the Internet is at http://www.avantgarde.com/ xxxxttln.pdf. Kevin Mitnick consulted on the study, should that name ring a bell.

Thanks to Alan Snyder, Sean Dague, Renier Morales, and MHVLUG for allowing me to slice up their threads. The original archives are at http://www.mhvlug.org/.

DDJ


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.