Having finished up with the BlackHat briefings, it was time to go on to DefCon.  While many of the speakers from BlackHat stay on for DefCon, there’s also a lot of DefCon-only presentations, usually with a more attack-oriented focus (in keeping with DefCon’s nature as a hacker convention rather than a security conference like BlackHat.)

The day began with Hacking E.S.P. (Educational Software Packages.)  Schools, by their nature, have sensitive PII data — transcripts, schedules, billing information, etc.  A lot of this data is either stored directly in web-based educational software used by students, or is stored in other systems students access… probably with the same password.  Overall, though, this was a pretty typical application service provider hacking presentation — many of the schools they investigated used the same software on their sites, and that software was often woefully bad: Passwords sent “encrypted” in Base64 encoding — and not even that if JavaScript is turned off.  Trivial session stealing via Hamster-style sidejacking, with the added bonus that the Session ID is set before login so you can steal a session ID then wait for someone to use it.  Copious cross-site scripting vulnerabilities to allow for cookie stealing.

Generally someone would have to have a login on such a system to be able to exploit these things.  However, the username/password scheme is often helpfully revealed on the front page, and some schools even allow you to create your own account on the system. Google showed 34,000 instances of this one flawed software package alone.  Considering as schools account for 34% of data breaches, this sort of buggy software is probably commonplace.

The second presentation I attended was about Adobe local shared objects.  In short, these are Flash cookies.  Just as your browser will store small data items (cookies) for a website, and return those items to the website when asked, Adobe Flash has a similar mechanism for Flash applets.  However, since these are stored by Flash and not by the browser, your browser doesn’t manage them — there is no indication to the user what data is being stored, and the data is not removed when you delete cookies or “private data” in your browser.  Ad networks have used these to “back up” your cookies — if you delete them, they are restored from a Flash local shared object when you next visit a site with the ads on it.  These are also hard to filter for systems like Privoxy and other anonymizers, because Flash uses a proprietary encoding for its XML RPC calls, in which the local shared objects are embedded.

On the bright side, there is a Flash applet on the Adobe site called Flash Settings Manager that will let you delete these objects and put in settings to manage them.  On the not-so-bright-side, this is in-band signaling (i.e. Flash is configured by a Flash applet), so any advertiser can override your settings later.  Also, as you may recall from the RIA presentation at Black Hat that I discussed earlier, there are a lot of other local storage mechanisms besides this one in Flash — Silverlight, HTML 5, and other frameworks also have local storage that is outside your browsers’ ability to manage.

I next attended a presentation about vulnerabilities in TOR, the onion-routing anonymity provider originally developed by the Department of the Navy and until recently maintained by the EFF.  TOR has become quite popular, at this point containing 1,500 relays and 200,000 users.  However, over the last several years, it’s seen several vulnerabilities that have threatened the anonymity it provides:

• 2004: Error in how AES counter mode was used resulted in cryptography with only 16 bits of entropy.
• 2005: A relay cell length overflow could be used to force an exit node to send contents of memory
• 2005: Diffie-Hellman handshake bug in OpenSSL didn’t check for trivial keys, so a malicious entry node could mount a man-in-the-middle attack
• 2006: By running several fast TOR servers, an attacker could end up as both entry & exit node for a user, thus compromising anonymity and potentially finding hidden services.  The fix for this was the addition of “entry guards” — trusted entry nodes that are re-used by users.
• 2006: Clients could create or extend channels even if server mode was turned off
• 2007: “Stable” or “Guard” status, normally applied to the top n nodes, could be stolen by malicious nodes by claiming high uptime and bandwidth.  The fix for this was to put in thresholds above which a node always gets guard status, rather than making it a top n calculation.
• 2007: XSRF attacks by web sites could make use of the TOR control port
• 2008: Nodes could be made to connect to their own public IPs
• 2008: The Debian OpenSSL PRNG flaw compromised 300 of the 1,500 relay identity keys, and 3 of the 6 directory authority keys.  If one more authority key had been compromised, someone could have taken control of the network

There are still some outstanding issues in TOR:

• You can build infinite-length circuits and use them as a DOS multiplier
• Snooping on exit relays works — if someone uses an insecure protocol that gives away their identity (like POP… or even HTTP depending on what they send), TOR won’t necessarily protect them.  This isn’t a bug in TOR, but just the nature of what it does — no software package will give totally anonymous communication if the communication itself gives your identity to the recipient.
• People who run relays are unknowns — there is no way to know how many are malicious.  However, TOR depends on having a large, diverse set of servers, so making more restrictions on who can run servers might actually lower, rather than raise, the network’s secuirty.
• Exit relays sometimes end up in restricted space (e.g. behind China’s firewall) — which means TOR users get restricted, too.
• Many users of TOR toggle it on and off during a single browser session.  However, a JavaScript refresh attack on one of the non-TOR sessions can sometimes retrieve data from the previous TOR session.
• Firefox bugs leak data, and that data doesn’t go through TOR, since on Windows it works as an HTTP proxy.  Users can work around this by proxying their entire network stack through a VPN connection like a JanusVM.
• It’s possible to block access to TOR.  If an adversary (say, the Chinese government) filters out the directory authorities, the download site, and all the relays, it’s very hard to get on.
• If you can see both input and output (by running many, many nodes, or having a massive filtering apparatus at the Tier3 ISPs — FBI, maybe?) traffic confirmation is easy.  (i.e. if I already suspect you, specifcially, of doing something, I can confirm you did it much more easily than I can “go fishing” for people doing unknown bad things.)  Defensive dropping or adaptive packing would help with this, but would raise TOR’s latency.
• You can fingerprint websites based on the size & response time of the pages and tell what people are doing via traffic analysis.
• A congestion attack by a website can find TOR nodes, and coupled with latency analysis on routers, can find the person communicating.
• Data retention laws in many countries are resulting in data being stored that could make traffic analysis easier.

So, with all these problems in TOR, does that mean we shouldn’t use it?  Not at all!  The known vulnerabiliites currently outstanding would apply to any low-latency mix network.  They’re not bugs in TOR, they’re limitations in this approach to anonymity, which remains better than any other approach to anonymity known.  TOR isn’t perfect, it’s just better than everything else.  Now, there may be better approaches to specific problems (e.g. there is one particular adversary you want to hide from, not just people in general), but for general anonymity, you still can’t beat TOR, even with its flaws.

I unfortunately missed much of strace and RSnake’s presentation on Google Gadgets.  In short, gadgets are pieces of HTML and JavaScript code hosted on third-party sites and brought into a Google-owned namespace.  Though this namespace doesn’t have direct access to Google cookies, the fact remains that it’s loading unknown JavaScript onto a Google page — it’s basically XSS-by-design.  Gadgets can communicate with or post to other users and gadgets on Google, and it turns out to be pretty easy to sneakily force a user to install a gadget onto their Google homepage.  If someone could crack a server hosting a trusted gadget, they could take control of the data of many Google users simultaneously.  Most of these vulnerabilities would apply to any gadget-based architecture, such as the Live start page, or Facebook’s apps, too.

The next presentation I attended was “Satan is on my Friends List,” about attacking social networks.  In short, social networks are full of promiscuous and pervasive trust relationships, which results in a large number of business logic flaws.  These attacks aren’t on code vulnerabilities like SQL injection, but rather just exploiting how the systems work.

Sites often don’t protect “non-sensitive” operations, like logging out or adding friends, from XSRF attacks.  Thus, it’s possible to craft comments that log out anyone who views them… which makes it rather hard to delete them (since you have to be logged in to delete a comment.)  XSRFs can be put into image links, meta refresh tags, IFRAMEs, etc.

In addition, social networks are ideal platforms for social engineering attacks.  Build a plausible profile for someone else using social and public sources, and then friend a few dozen people who are known to friend everyone right back to build a “respectable” number of connections.  Joing groups, and start friending real associates of the person being impersonated.  At that point, you have a web site that can be used to confirm your identity as someone else.

The Facebook and OpenSocial APIs for integrated social apps are also good avenues for attack.  They have convenient APIs and execute arbitrary code by design — the social networks don’t care about application malware, as it’s on a second domain and they’re legally protected by their EULA.  However, if you widely distribute an app based on some current meme, get hundreds of users, then replace that app in-place with malware, you have an instant social network botnet.  You can use them as open redirects, put phishing items on their social network page, etc.  Also, applications have all the access that friends do — just the data disclosure may be enough for identity theft, impersonation, or at least some minor mayhem.  They can publish to a user’s profile to infect others, too.

Unfortunately, the fixes for these issues are just what the social network sites don’t want to hear — less external content, reduced API functionality, no opt-in security models, review and lifetimes for applications, etc.  Thus, these vulnerabilities are probably here to stay.

The last presentation I attended was by Errata Security, about interesting penetration tests.  Modern penetration tests are “supposed to be boring” — they’re often done for the purpose of meeting compliance objectives, so companies are mostly interested in meeting a checklist, not in security.  They want to be secure against likely attacks and “script kiddies,” but are not interested in making the kinds of expensive changes required to defend against a determined, well-funded adversary.  The main exceptions are government agencies and Wall Street, who know they’re the targets for those determined adversaries.

Maynor & Graham walked through a couple of interesting things they did as part of penetration testing.  One of these involved hacking the well-firewalled network of a company that was based at a secure facility, one where they could not simply walk onto the premises.  Instead, the wired an iPhone to a UPS battery and put it into the original iPhone packaging, then mailed it to the company.  With a UPS battery, an iPhone can run for 5 straight days with the WiFi on.  They modified the phone to add tcpdump and APlogger, and added a cron job that would send an SSH tunnel out to their computers every hour over the AT&T EDGE connection.  The result was a WiFi sniffer & endpoint inside the “secure facility” from which they could scan the internal network and run Metasploit to break into things.  An iPhone, after jailbreak has been run, is essentially a tiny BSD box — a perfectly suitable hacking platform.  Who thinks about their network being hacked by a cardboard box in the mailroom?

They also built a better phishing site.  Even security-aware people who are looking for phishing sites look for a valid SSL certificate bound to the site and signed by a trusted authority.  However, all it takes to get a real SSL certificate signed is about $2,700.  Start a business, register with Dun & Bradstreet to get a credit rating, then apply for a real certificate from VeriSign or Thawte.  You can even sign ActiveX controls and require users to install them as a “secuirty feature.”  Since so many banks and companies outsource their applications or their HR and IT infrastructure, a phishing site with a good certificate is often indistinguishable from an outsourced site.  Just send someone at the comapany an email saying that the company has changed 401(k) providers, and they need to go to this outsourced site and sign up.

As is customary with DefCon, there wasn’t much talk about how to prevent these vulnerabilities.  However, it gives you something to think about, and it’s often very hard to guard against clever attacks against business logic flaws.  There’s no substitute for good threat modeling and flexible thinking.

Early this week, some researchers at Princeton University’s Center for Information Technology Policy released a fascinating video of whole-disk encryption being cracked quite quickly and easily.

Whole-disk encryption products — such as PGP Whole Disk Encryption, TrueCrypt System Encryption, and Windows Vista’s BitLocker — work by encrypting the entire hard disk with a symmetric key, save for a small loader.  When the computer is powered on, the loader prompts the user for a password or other authenticator (like a smart card or a certificate on a USB keyfob), which is used to decrypt the key.  Assuming the correct authenticator is provided, the key is decrypted and then the OS is booted from the encrypted drive.  The key remains in memory until the machine is powered off, since continuous access to the key is required to access the drive.

The purpose of whole-disk encryption is to protect against an attacker bypassing all of the operating system’s defenses (logins & passwords, filesystem ACLs, etc.) by simply pulling out the hard disk and putting it in another computer (or, equivalently, booting up a LiveCD on the system) such that the operating system isn’t loaded at all.  Instead, the drive is mounted into an OS the attacker controls, where he has the ability to change ACLs, bypass logins, etc.  With whole-disk encryption, you can’t do this — even if you steal a laptop, without the boot password the entire drive contains nothing but a useless encrypted bitstream.

(As a side note, Vista BitLocker has a mode in which the symmetric key is stored in the TPM of the laptop, so no boot password is required.  At first this seems useless — why encrypt if decryption is automatic? — but it does provide protection against simply stealing the hard disk or booting into another OS.  The OS being booted must be in that specific computer, as only it has the TPM, and must be BitLocker-aware and capable of getting the key from the TPM.  It’s not completely secure in the stolen-laptop scenario, but neither is it useless.)

The Princeton group’s attack on whole-disk encryption relies on a little-known fact — computer memory (DRAM) is not wiped out when the system is powered off.  Rather, it becomes unreliable, decaying over a period of seconds to minutes as it gets randomized bit by bit.  It turns out that if cooled to a very low temperature, this decay is slowed considerably, to the point of being stable for tens of minutes.  Thus, the attack is as follows: get access to a laptop that is currently operating (so that the whole-disk encryption key is in memory), spray the RAM with an inverted compressed air can to cool it to -50 degrees Celsius, and power the system off.  Either move the RAM to a system with a custom OS, or attach an external drive to the system and boot off that.  The custom OS boots with a minimal memory footprint and then copies everything from RAM to a file on disk.  Thus, in less than a minute a “snapshot” of RAM has been taken.  This snapshot can then be inspected to locate prospective cryptographic keys and try them on the target drive.  Some knowledge of the particular whole-disk encryption product being used would be needed to find the exact spot in memory where the key is, and some error-correction techniques must be used in case a bit or two has been flipped, but it reduces the problem from cryptographically impossible to something that can be cracked in a few minutes or at worst hours.

So is this the end of whole-disk encryption?  No, not at all.  First of all, whole-disk encryption still successfully protects computers that are powered off (or in hibernation) — in that state, the computer does not have a copy of the encryption key available to it until the user re-enters his password.  In most stolen-laptop scenarios, the computer isn’t running at the time!  Whole-disk encryption is still a critical mitigation in the case of portable computers containing confidential data, and enterprises and government agencies would do well to implement it.  Of course, the best mitigation for this is to not carry confidential data around on your laptop.  It always strikes me as absurd when some government employee loses millions of confidential records on a stolen laptop — why did they need to have millions of records to carry around with them?  Do they really need all of those on-the-go?  It’s possible that in a minority of cases they do, and in those cases encryption is imperative (either of the whole-disk variety or on the file), but in most cases they’d have been better off leaving those files at the office.

Second, this is only a concern in targeted attacks.  If a typical thief rips off your laptop and discovers whole-disk encryption in place, they’re not going to execute this attack and get at your data.  Instead, they’ll just reformat the hard drive and sell the laptop as hardware.  The only reason someone would carry out this attack is if they knew that your laptop in particular contained valuable data and thus set out to steal it specifically.  In other words, if you’re a spy, and your laptop is classified TOP SECRET UMBRA, you have to worry about this attack.  If you have a typical corporate desktop and aren’t widely known to carry around your company’s entire credit card database, whole-disk encryption will probably protect you just fine.

There are several things that can be done, both by end-users and whole-disk encryption vendors, to mitigate this attack.  For end-users:

• If using Vista BitLocker, do not use the automatic mode — choose a mode that requires the use of a USB keyfob or a password to unlock.  This makes this attack ineffective when the system is entirely powered off.
• Do not use sleep/suspend-to-RAM when the computer is not actually in your hands — either power off or use hibernate.  In a sleep or suspend-to-RAM scenario, the whole-disk encryption key is still maintained in memory and can be recovered.
• If you have a few truly critical files, use file encryption (such as Windows’s Encrypted File System or PGP’s file encryption) on those files with a different password than that used on the whole-disk encryption.

For makers of whole-disk encryption software:

• Provide an option to re-encrypt the symmetric key during sleep or screen-saver activity.  This would mean the the laptop would need to be stolen during a truly active state; however, it would also inconvenience the user with more frequent password prompts.
• Consider the cryptographic key expansion mitigation described in the Princeton research paper.  It vastly increases the chances of even a small amount of decay of memory rendering the key unrecoverable.  Of course, it does so at the cost of performance (by requiring an additional hashing and XOR operation every time the key must be used.)

The AP has a story about an electronic bank robbery foiled when a bank employee pulled the plug on the robbers’ network connection.  Apparently the robbers had gained physical access to the employee’s workstation at some point, and installed “advanced technical equipment” underneath the desk to remotely control the computer.

I would guess that the “advanced technical equipment” consisted of a cheap consumer wireless access point.  The attack probably went something like this:

• Gain unsupervised access to the machine in some way, either by breaking in or by impersonating someone with legitimate physical access (e.g. a cleaning crew.)  Perhaps it’s an inside job and one of them does have legitimate physical access.
• Install a wireless access point behind one of the computers configured as a network bridge, so it can be remotely accessed without setting foot in the bank.
• Bring the computer up offline (using some external boot media so no passwords are required) and install a remote-control Trojan — either some VNC variant or a system designed for use as a surreptitious Trojan like CdC BackOrifice2K.
• Wait until the next day when the user has authenticated but walked away from their computer, take control of it from a van across the street, and begin transferring funds.

As for the somewhat dramatic line “By pulling out the cable to the device, the employee managed to stop the intended transfer at the last second,” this is obviously meant to evoke movie scenes where there’s some progress bar on the screen marked “Transferring funds…” that gets interrupted at 99% by the heroic employee cutting the cable.  However, what’s more likely is that the employee looked at his computer, noticed the mouse moving on its own, clicking buttons to transfer funds and entering in an amount.  Before the button to confirm the transaction could be pressed, the remote control was disconnected so the transfer was never started.

This is an interesting attack in that it doesn’t really fit the profile of a traditional bank robbery, but neither is it a completely electronic theft.  The attackers had to have had physical access to the bank, but they didn’t use it to get at the money — they used it to get to the computers.

Security measures are targeted.  The bank’s physical security consists of cameras watching teller stations and heavy vault walls and doors guarding the money.  This is targeted at stopping two attacks — the vault stops simple burglary (walk in at night and grab the money), while the cameras detect employee fraud by tellers and armed robbery by customers.  Meanwhile, the bank’s electronic security consists of firewalls, intrusion detection systems, and access control systems that stop people from outside the bank from accessing the systems.

This attack went around both.  The physical security was not set to stop people tampering with desktop computers — there’s no money there!  Someone was thus able to either sneak in or social-engineer their way to the desk and tamper with equipment undetected.  The electronic security is not meant to stop someone actually sitting at a computer who has logged in with legitimate credentials — they’re supposed to be able to move money around.  By combining an electronic breach with a physical one, the attackers managed to be “sitting at the computer” while actually nowhere near it.  It’s an ingenious plan, and one of those rare cases where a rather elaborate “heist movie plot” sort of attack was attempted.

They were stopped by one of the most powerful countermeasures available — a vigilant employee.  However, there is a lesson to be learned from this: Physical security is important!  If an attacker has unmonitored physical access to hardware, he can modify it to do anything he wants.  No passwords or credentials are needed if he can reboot the system with a flash drive or CD-ROM.  How many of your company’s electronic countermeasures would be rendered useless by an attacker who could remotely control a computer inside the perimeter, or even just had a network tap to the internal network behind the firewall?  In most companies, it’s not too hard to gain physical access, usually by impersonating a service employee of some kind (janitorial staff, phone company employee, etc.)  Presumably the attackers who had physical access were in a hurry, since they put the AP under the same computer they were controlling; with more time, they could have compromised one computer and hidden the AP somewhere entirely different, making it harder to find and pull the plug.  Of course, if the employee was thinking clearly (and he probably was, since he thought to pull the plug at all), he still could have simply switched the computer off, so this wouldn’t have done a lot of good.

Also, it’s worth periodically searching for rogue access points.  Not only might an attacker install one deliberately, but employees in businesses without wireless networks have been known to install a wireless AP under their desks simply for convenience.  Often, these are configured very poorly, with no security or encryption at all.  Rogue APs can be detected in a variety of ways; if you have the luxury of having access to a product like Aruba Networks’ RFProtect (which was called Network Chemistry last time I used it, but seems to have since been acquired by Aruba,) monitoring can be automatic and continuous.  If not, there are still open-source rogue scanners, and even simple tools like the aircrack-ng suite can be used to look around, though it’s considerably less automatic (and thus more time-consuming) to do it that way.

This also points out the importance of defense in depth.  Host-based firewalls and intrusion detection might detect an attack like this, but traditional perimeter defenses like firewalls and NIDS are useless against it.  Layers of security, designed to interfere with different types of attacks, always provide much more security than any single countermeasure.

There’s an article in PC Magazine about a company called TraceSecurity that performs audits of physical security via social engineering.  Essentially, companies hire them to steal data, and they do so by simply talking their way into the facility and getting unrestricted physical access to the servers.

If a skilled attacker has unrestricted physical access to a machine, they can acquire all the data on the machine.  Database encryption can help quite a bit — unless they also get the system that contains the key to your database.  Since in many cases the database server sits in the server room right next to the middle-tier server that encrypts it, this is not necessarily much of a protection against true physical access.

To most people, it seems like it would be difficult to simply talk your way into a private facility and get left alone with the mission-critical servers, but really, I’m not surprised that TraceSecurity reports no difficulty getting abandoned anywhere short of a bank vault.  Daily life is based on trust — we assume that people are what they say they are and appear to be, because life is is impossible otherwise.  In addition, we encounter legitimate people so much more often than criminals that in a sense a criminal is a surprise every time.

Anyone who’s worked in a corporate office with badge-based security knows how easy tailgating is.  Wait for someone to swipe their badge and walk in right behind him — your chances of being challenged are very low, since people do it all the time and even people who originally challenged tailgaters have usually gotten tired of it within a few months (since it’s basically always just someone too lazy to get their badge out.)  What TraceSecurity does is pretty similar, with a dose of social engineering — just dress up as someone who belongs there, pretend to be someone who belongs there, and walk right in.

They tend to prefer pest-control services or fire marshals for their disguises (though they have to jump through a few legal hoops to dress up as a federal agent without committing a crime), though other penetration testers I’ve encountered favor telecom vendors.  If a company’s ISP is Verizon, they will think little of a Verizon technician showing up, and probably happily let him into a wiring closet or server room.

The bigger difficulty than getting in is getting left alone.  This is one area where simple surreptitious entry, like tailgating, is better than dressing as someone like a pest inspector or fire marshal who, in their normal jobs, you would not likely leave alone anyway.  Still, people at corporate offices are busy.  If one is following you around, dawdle long enough in non-sensitive areas and I’m not terribly surprised they get tired of wasting their day escorting you.  By the time you get to the server room, they swipe you in and get back to work.

This sort of penetration test makes the news, though, because it’s interesting and unusual.  Even TraceSecurity, which the article makes sound like specializes in this sort of assessment, offers a wide array of other security services.  A career exclusively performing on-site physical/social penetration tests may be limited to characters in Sneakers.  The main reason, though, is the perception of risk.

People see the security measures around physical intrusion.  The servers are in a locked room, in their locked building, surrounded by people who know each other, so getting in must be difficult.  On the other hand, most people have no idea how to hack into a server from the Internet, and thus have no way to gauge the risk other than the availability heuristic — and we hear about online break-ins and data leaks in the news all the time, so it must be easy.  This makes people inclined to overestimate the risk from network attacks (though, honestly, the risk is pretty high) as compared to from physical intrusion.

This said, another thing preventing physical attacks on servers is not the difficulty of the attack, but the simple dearth of people willing to carry it out.  Breaking into a building to steal something “feels” like crime, while just typing code into your keyboard is probably more easily rationalized — it’s the same reason why people who would never shoplift a CD happily copy music, despite the acts being legally similar.  Of course, there’s probably also a higher likelihood of getting caught in the physical intrusion — people have seen you.  This is a case where prevention is very hard but detection is less difficult.  It takes a special sort of person to be caught red-handed trespassing in a server room and still keep their cool well enough to get out of the situation without arrest.  Admittedly, this lowers the actual risk of attack — it reduces the threat, despite the presence of the vulnerability.

The usual solution posited to this sort of attack is user education — just teach people to be vigilant, ask to see badges of people they don’t recognize, verify the identity of service providers, call the fire department and ask if the fire marshal should really be here, etc.  However, in truth, this just won’t work.  TraceSecurity couldn’t get the bank manager to leave them alone in the vault — because people standing in a vault think about security, and know that a normal person might be tempted to steal when surrounded by cash.  But in a server room, where the potential theft may actually be much greater, it’s not what’s on their minds, and simple user education isn’t likely to change that.  Human beings trust each other, and criminals learn how to cultivate and play on that trust — a security awareness program isn’t going to change human nature.  What is necessary here is to worry less about prevention and more about detection and response.

When data is extremely valuable — say, personally identifiable information with credit card numbers, in bulk (20,000 records or more) — it shouldn’t be stored in a corporate office server room anyway.  You wouldn’t store $200,000 in cash in a closet in your office building, so don’t store something of equivalent value and easier to carry there, either.   Colocate the server in a secure datacenter, where it’s surrounded by people who are aware of security and under guard and camera.

However, for less-valuable data, instead of thinking about how to keep people out — a task that may be impossible — think about how to know they’re there and recover from the breach.  Methods like camera surveillance deter crime by making intruders believe themselves (rightly) more likely to be caught.  Use monitoring tools on computers to be able to determine if someone has gained physical access to them (an action which tends to result in the server going down for a short time) and investigate such alerts immediately.  Even procedural efforts like requiring people to sign in and out of server rooms can be helpful — if the sysadmin has to write down that he admitted three people to the server room and left them there, he’s more inclined to have security come to mind, and more likely to speak up later when you realize a theft has occurred.  In addition, do use encryption on valuable data — this ensures that if an intruder does walk off with the database file (or the hard drive it’s on), they’re less likely to be able to make use of it.  It may not be enough in the case of someone who breaks into your building and has all night to figure out where the key is, but it may be enough for the person who has 5 minutes to copy everything they can to a thumb drive before you come back with their cup of coffee.

At Crypty 2007 in August, Eli Beeham, et. al. presented a paper called “How to Steal Cars,” describing how they have bypassed the KeyLoq remote keyless entry system — the system used in the majority of the remote keyless entry key fobs. These systems are supposed to be secure — they use a 32-bit block cipher to transmit a 64-bit key from the key fob, which, if it matches, unlocks the car. The key consists of an XOR of a car identifier (not secret, can be eavesdropped on) and a manufacturer key (secret.) It should take 2⁶⁴ iterations to crack the key — not really practical.

However, these researchers found a flaw in the cryptosystem. Due to a flawed protocol, they can mounting a chosen-plaintext attack on 2¹⁶ keys (requires about 65 minutes access to the car.) And once they have that, there’s a cryptanalytic attack on the manufacturer key (that’s a bit more cryptographically strenuous; they took 2 days to do it using 50 dual-core Opterons), which makes unlocking any car by that manufacturer very easy.

But do we care? Car thieves aren’t going to run up to your car with a radio antenna, spend 65 minutes gathering data, run back to their PC and run a cracking app, then come back and steal your car. It’s easier to just pick the lock, use a slim jim, or break a window. (Actually, these things are frighteningly easy, much more so than most people imagine; key-based locks are not very secure.) However, the risk isn’t from single attackers — it’s that this turns cars from having a physical lock to a software lock. Now that this attack is known, someone could make an effort to gather manufacturer keys from many car manufacturers and model years, and create a simple piece of software which (when paired with an appropriate-frequency radio antenna) opens any car by those manufacturers. The bad thing about software hacks to things that aren’t general-purpose computers is that they’re really hard to fix. If someone does come out with Car Unlocker for Windows Mobile PCs (or even cell phones), what do you do about it? You can’t just download a patch to your car. Manufacturers will change the keys in future cars, but there’s nothing to be done about current ones. One guy isn’t going to do this to steal one car… but someone might do it for organized crime to steal many cars.

It’s dangerous to embed cryptographic keys. Key management and rotation is actually a much, much harder problem than strong cryptography — it’s one thing to make the key hard to break, it’s quite another to be able to change it when it’s broken. (And if the target is high-value enough, it’s a when, not an if — just ask the RIAA and MPAA’s DRM developers.)