Motivation

I just spent some time cleaning up my SSH config files (such as combining a bunch of similar "Host" sections under one heading, so as to avoid duplicating config stanzas.)

I also decided to clean up known_hosts to only contain what is in my config file. I want it to be easy to securely seed new systems, I like the "clean" feeling of knowing there is no old cruft in there, and I think having cruft is a security hole anyway. Maybe I once accepted a certain host key, assessing that it was OK in one context, or for a temporary throwaway account – but if the host is not in my config file, I probably don't want its key permanently in my known_hosts. That's why I want to easily know what's in it, and manipulate its contents.

My Configuration

I keep an ssh config file with hostnames, some nonstandard ports, and pointers to encrypted authentication keys I load into an SSH authentication agent. I just put it into a local git repository today, because I have found that useful for other configuration files.

Why Use HashKnownHosts?

HashKnownHosts is supposed to be to prevent address-harvesting attacks. The address and (port number if non-standard) are hashed cryptographically with a salt, to make it more difficult for worms or crackers to slurp up targets.

Why Not Use HashKnownHosts?

HashKnownHosts makes it difficult to maintain a known_hosts file. Want to edit the file to remove a certain host? You can't do it by hand, you need the ssh-keygen tool to do it for you.

Want to filter out outdated entries? You'll either have to crack the hashes, or enumerate every entry you want to keep, and remove the ones you want to by elimination (which is like cracking the hashes with a dictionary attack.) This is what I had to do to recover the keys I wanted to keep, to check in a nice, clean file to git.

Want to merge hashed known_hosts files from different hosts or user accounts? You'll have to (or at least may want to, for file cleanliness) de-duplicate hashes of the same hostname but with a different salt.

Want to just know what's in your file? You'll have to dictionary-attack it.

After all that inconvenience, I'm not sure hiding the connection history is even all that valuable. In my configuration, I only use cryptographic keys for authentication, necessitating (AFAICT) a unique entry in my config file for every host, listing hostnames and what port to connect to and what key to use. That's right, machine-readable instructions on how to connect to every host I connect to, with potentially more information than known_hosts has (such as a username.) (The keys are encrypted though.) Pretty much the exact same situation as an unhashed known_hosts – connection information with just the last authentication factor (a password, or private key encryption passphrase) missing.

Maybe that means the names in the config file should be hashed, too. Besides the annoyance that would bring, this still just seems to obscure how bad having your config or known_hosts files accessible to an attacker are. You could just as well have a backdoored ssh in your PATH that logs everything you do, or another machine on the network sniffing for SSH packets and logging where they are going. Your shell history file may have connection details. If you're relying on unique hostnames or non-standard ports to bandaid over weak passwords or whatever, you've got worse problems.

And as I mentioned, an opaque, difficult-to-audit trusted key database could be a security liability of its own. This file isn't some MRU auto-completion nicety, it's a security mechanism to prevent man-in-the-middle attacks. You wouldn't want your browser keeping only the hashes of URLs you'd added SSL certificate exceptions for (such as for self-signed certs), would you?

Is it worth extra administrative burden to obscure connection information that will probably be obtainable from other sources anyway? I'm thinking not, so for now I've disabled HashKnownHosts (was enabled by default in Ubuntu.) Luckily it's easier to re-hash later if I want to, than it was to unhash.

I recently bought a digital download of a PC game from Amazon. I figured the download would take ages, but still probably faster and a bit cheaper than buying a DVD. So, I let the Amazon download manager do its thing all night, came back 12 hours later and tried to install the game. Failure: CRC error.

Some Googling suggests this is a common flaw with the Amazon download manager, NOT with the game itself. Silly me, I thought the whole point of a proprietary download manager program was to ensure the download went correctly! To be fair, I stopped and restarted the download program a few times, and also saw some messages about "Connection lost, retrying in 30 seconds..." Still, a decent download manager should handle this with no sweat. I later found that the middle of one file had a big run of zero bytes that weren't supposed to be there – so it wasn't even some random bit corruption, it was likely the download manager padding the filesize out for whatever reason, but it forgot to, you know, actually download the data in that part of the file.

I wanted to play the game right then, but it didn't seem like I had much of a choice. Since the last step of the download had been to drop a CD key file in the destination directory, I decided to import that CD key into the game publisher's own game download/social gaming/advertising/etc. platform (I was going to be forced to tie the CD key to this anyway) and download it straight from them and hope they were better at verifying the download. This started working, but the download time was estimated at 13 hours. I also started downloading a cracked copy of the game via BitTorrent (semi-successfully using the Amazon files as a "partial download" of the torrent), but ended up canceling that for fear the "crack" would include malware.

Well, I still hadn't given up on playing the game that night, so I was poking around in the game platform's directory and found a text file with a bunch of filenames, decimal numbers, and long hex numbers. Bingo, checksums! Cross-checking with the files I got from Amazon, I found the decimal numbers were the filesize, and the hex strings were md5sums. A few regexp replaces later and I had a GNU md5sum-compatible check file. Only one file from the Amazon download failed the vendor's checksum list. The aborted torrent-download had that entire file (either a blazing-fast download, or more likely seeding the torrent DL with the Amazon files worked and it quickly got patched with the rest of the contents.) What do you know, the torrent-sourced file matched the md5sum from the vendor! Popped that in, started the install again, and this time it finished.

So, those lazy, greedy, good-for-nothing pirates saved me from waiting 13 hours to use my paid-for product. They also saved the game vendor from paying for 8GB worth of bandwidth they would have needed to have me download the entire installer again because their distribution partner couldn't be bothered to run checksums. I'm disappointed, Amazon.

P.S. It's also possible the pirates made an md5-colliding infected file to fool people like me into installing their malware. You can never be too paranoid, right?!

Recent events related to the justice system in America have led me to ponder how we're doing as a country.

The first was the HSBC settlement, where the British banking corporation HSBC "admitted to laundering billions of dollars for Colombian and Mexican drug cartels (among others) and violating a host of important banking laws (from the Bank Secrecy Act to the Trading With the Enemy Act)." Also, "some of HSBC's Saudi and Bangladeshi clients had terrorist ties, according to a Senate investigation." The US Justice Department has elected not to prosecute. The settlement deal was a fine of $1.9 billion, some shuffling of the leadership, and a few slaps on the wrist in the form of partially deferred executive bonuses. One analyst says the fine is about five weeks' worth of profit.

The other was the suicide of Aaron Swartz, a decision possibly swayed by what some are calling predatory, disproportional prosecution for his alleged crimes of downloading copyrighted academic papers with an intent to distribute them for free. The disturbing thing about this case is that the victim of this crime (JSTOR) were not interested in pressing charges, but the same US DOJ decided to prosecute, and we get the feeling it was to "make an example" of Aaron. He faced up to 35 years in prison (more according to some sources) and $1 million in fines if convicted, more than the maximum sentence for some heinous crimes like bank robbery, selling child pornography, selling slaves, or giving nuclear weapons aid to terrorists. (Granted, there are many charges stacked to get such a high sentence, but consider his actual actions compared to the actions of someone who committed just one count of those crimes. And yes, there was a potential plea deal, but it doesn't sound all that great.)

In both cases, real crimes were committed (I'm trying not to hero-worship Mr. Swartz as some are doing), but the contrast between the punishments is chilling. The messages are that if you're the little guy challenging entrenched institutions and their intellectual-property-based revenue streams, you will be crushed like a bug with no mercy and at the prosecutor's initiative; if you're a powerful institution and you monetarily aid drug dealers and terrorists, you get a slap on the wrist and America gets a little pocket change from your fine. Crime does literally pay: if you can make enough in a decade of laundering the money of criminals and enemies of the state to pay the fines when you get caught, it's worth it, and nobody even goes to court, let alone prison.

There are people powerful enough to be above the law, but anyone who challenges those types of elites will be obliterated. There is no "justice for all" in America. There is no sign that this will be changing soon, either.

P.S. If you still need convincing, look at the difference between a bank's punishment for helping drug dealers to the tune of millions, verses the punishments given to random people on the street for carrying drugs.

When download finished, follow the steps in this forum post to make a USB stick that rEFIt will boot. It was a little scary downloading a random tarball from a forum and using it to patch the ISO you're using to install a new operating system (rootkit anyone?) But, after glancing at the files inside, I did it. Looks like a lot comes from the syslinux package and stuff, which I've already trusted, and I guess I can trust this guy in the forum not to mess with it. Follow the instructions, use rEFIt to boot off the USB stick. For me rEFIt identified the USB stick as a legacy OS on a hard drive, but it booted OK. Installation process goes like how you usually do a dual-boot install (if you want to keep Mac OS, that is.)

For me, GRUB failed to install to a partition (as opposed to MBR, the usual way to intall GRUB), crashing the installer. I manually did grub-install with the --force flag, which causes it to use an unreliable blocklist method to install to the partition. Even with this, I originally got an error something like "cannot read /grub/core.img" I found somebody in a bug report suggesting to use ext3 on the boot partition instead of ext2, and it worked for me. I suppose the blocklist may break if files moves around, but it's working for now.

I've set up full-disk encryption on my Google Nexus One running CynanogenMod 7 using LUKS, and I've been wondering if it is vulnerable to a cold-boot attack (CITP research). My phone, with its open bootloader and USB “fastboot” mode, is roughly comparable to a PC that can be reset and then booted from an attacker-controlled PXE image.

I prepared an Android boot image with the LiME forensics module configured to acquire the RAM image to the PC over TCP/IP tunneled through adb. I'll call this boot image the Image Acquisition Program (IAP). I usually had my system waiting for the phone to appear on USB in fastboot mode, ready to push out an image to boot from. (I messed up a few times and the phone sat idle in fastboot mode for a few seconds longer, but this probably doesn't affect memory retention.) I used my hacked up version of Torbjörn Pettersson's keysearch program (original) to look for keys. I didn't try CITP's AESKeyFinder or AESFix because the key was longer than they supported. The key I was searching for was the LUKS master key, which I believe is just the raw lower-level dm-crypto key. I'm not trained in experiments like this, so these results should be taken with a grain of salt.

The target system was not taking any precautions to flush the key on shutdown or reboot. In all experiments, the phone started booted and decrypted, at the lockscreen. adb was enabled except as noted.

With the phone plugged in to USB, use adb to reboot into fastboot mode, boot IAP: Full key recovered.

Disconnected from USB, adb disabled, use the reboot menu to do normal reboot while holding fastboot key, boot into IAP: Full key recovered.

With the phone plugged in to USB, use the reboot menu to reboot straight into fastboot, boot into IAP: Full key recovered.

With the phone plugged in to USB, use the reboot menu to do normal reboot while holding fastboot key, boot into IAP: Full key recovered.

Disconnected from USB, use the reboot menu to reboot, boot into IAP: Full key recovered.

Soft reset (Trackball + Volume down + Power), hold fastboot key, boot into IAP: Inconclusive. In one out of 3 tries, the full key was recovered. It seems this reset isn't as soft as a normal reboot, but it may not be consistent in that either.

With the phone plugged in to USB, use the shutdown menu to turn off, turn back on, boot into IAP: Key not found. (Tried twice.)

With the phone plugged in to USB, pull the battery momentarily (long enough for screen to turn off), turn back on, boot into IAP: Inconclusive. On first try, two garbled copies of key found. One had about 8 bits corrupted (from 1 to 0). Tried 3 more times, and nothing looking like the key was found. I may have accidentally changed a variable when I tried again the next day, or perhaps some speed or just "luck" (in uncontrollable variables in the state of the electronics) is needed to get the result I got the first time.

Disconnected from USB, pull the battery momentarily (long enough for screen to turn off), turn back on, boot into IAP: Key not found.

Conclusions: The key is fully recoverable if the phone reboots itself. It may be recoverable if the soft reset keychord is used. It may be partially recoverable if rebooted by power-pull (there may be an error in the experiments here.) It appears to not be recoverable if the phone powers itself off. Variables such as rebooting directly to fastboot or doing a normal reboot while holding the fastboot key, or leaving it connected to USB or not, appear to be irrelevant.

Recommendations: Make the phone unable to reboot itself when the phone is locked. If possible disable soft reset keychord. Attempt to flush key by luksClose'ing (or perhaps wiping all RAM) in case of software reboot. Even with these precautions, it may be possible to force a reboot anyway (the soft reset keychord may not be software-based, exploits at the lockscreen or over USB connection), and the key may still be in RAM. The only defenses that come to mind involve patching the early boot firmware: to either wipe all RAM before any boot image takes control, and/or only accept cryptographically trusted images. Even these would probably be insufficient against a determined, resourceful attacker, so the best scenario would be to pull the battery (and perhaps boot again and wipe RAM) long before they have a chance at it.

Edit 6 Dec 2012: I realized a couple of problems with my tests. I was using my "IAP" to boot the system normally after acquiring the image. Since I didn't take any precautions to wipe RAM between tests, each acquisition potentially had remnants of several instantiations in it. This might explain some of the inconsistent results. Even if my exact conclusions are potentially flawed from this, I think the general point, that a coldboot attack is plausible, still stands.

I had an interesting thought about distributing digitized, DRM-less versions of non-digital or DRM-restricted copyrighted works: What if you distributed an encrypted digital copy of the work, and the decryption key was derived from the contents of the work itself? For a book: “take the SHA512 hash of words 7, 35, and and 79 from page 67, appended together with a space in between. Use the resulting hash to as the key to decrypt the file.” (Of course a longer, more complicated key would probably be advisable in practice.)

I'm not a lawyer… but it seems like distributing an encrypted copy of something (without outright including the key) can’t be illegal – without the key they're just random bits! And since the key has to be derived from the original content, the receiver/decrypter is proving they have an original, and thus under fair use laws are allowed to have personal, decrypted copies for backup/convenience (I think; MAFIAA is working hard to erode those rights.) The person might not legally have full rights to it (e.g., they just grabbed a copy from the library to decrypt the digital copy), but if we're nitpicking about that, they could just as well make an illegal copy of the borrowed copy, without bothering with downloading and decryption.

I imagine this is not an original idea from me, so I'll have to see if anyone has written further on it or tested it in courts.

I've seen this break several sites. Users have the choice to override the block, but most won't notice the little shield in the address bar, which allows them to override the blocking and reload the page with all content intact. All they'll see is a site that looks plain (no CSS) or is missing content or that doesn't respond when they try to interact (no JavaScript.)

They say quietly blocking requests is "less intrusive" than throwing up an infobar warning at the top of the browser frame (apparently breaking pages is not intrusive at all.) It's ironic that they praise the infobar approach for "high visibility", something the new approach lacks. The infobar ultimately had to go because it violated a principle, "Don’t get in the way" -- as if totally breaking perfectly valid pages is not getting in the way.

I understand why mixed-content pages are dangerous, but I'm frustrated by the condescending "Google knows best" attitude to pushing this out. Also, they act like everything should be fine because they've extensively tested with Google, Facebook, and Twitter, as if those are the only sites on the Internet. But hey, they said "We’re sorry for any temporary disruption."

When asked if the more technophobic mainstream would easily adopt the novel technology, [Eric] Schmidt responded, “Depends on how drunk they are.” Schmidt brought up the sad statistic of 35k people killed each year in drunk driving accidents in the United States, and the even sadder fact that that is considered a good statistic because it’s remained constant over two to three decades.

“It’s a terrible tragedy,” Schmidt said, “The sooner we can get cars to drive for us the more lives we can save … self-driving cars should become the predominant mode of transportation in our lifetime.”

Yeah, we wouldn't want to, like, invest in affordable, ubiquitous public transportation or anything like every other modernized country! Anyway, there will always be people traveling in small groups, and most accidents are probably caused by preventable human error (whether inebriated or not), so this is still a pretty good argument.

But the safety consideration got me thinking: how long until, say, the TSA decides they should be in charge of monitoring these cars to make sure the self-driving ability isn't abused? They've already been spreading to buses. Transportation Security Administration: it's such a nice, broad name for a federal agency — why let that go to waste? When will we see the first instance of a car being seized to dump records of where it has driven? (I'm no expert on the case law, but from my understanding, sometimes this is an easy thing to legally/warrentlessly(?) do, since vehicle location information is just showing where a person has been in public, where they had no reasonable expectation of privacy.) Or easier, cloud navigation providers, cell network operators, etc., will probably be subpoenaed and/or "requested" to turn over the information without consumers even knowing.

How long until not having a smart car, or electing to drive one "manually", is considered suspicious behavior, as if the person is trying to circumvent limits built into the self-driving software, or leave less records about where they've been? When will the NSA start gobbling up all the navigation data en masse to compile profiles of peoples' behavior and build social networks by finding overlaps between different peoples' locations?

The cars will likely have Bluetooth and similar technologies for tethering mobile devices. Records created in this manner can be used to know more about who was in the car at what times. When will biometric authentication hardware be required installed in the cars, making it even easier to tie people to locations?

BYU's The Universe printed my Letter to the Editor (PDF of the newspaper.) I'll quote it here, then go into some more detail I didn't have space for in the letter.

The article “BYU’s crime rate sets it apart from other universities” (6/26) opens by quoting several frivolous Police Beat reports, quipping, “The amusing reports above are just a sample from BYU’s popular Police Beat, found in every Tuesday edition of The Universe with an extended version online. The crimes, for the most part, range from mysterious figures on campus to bike thefts.”

The self-righteous and self-aggrandizing tone of the article as a whole is offensive and unjustified, but I felt this light-hearted characterization of crime at BYU was especially insensitive in light of serious, damaging crimes that have been reported in the Police Beat. When I read it, I thought of a January 21, 2012 report: “A male student living in on-campus housing was arrested for sexual abuse. The individual had been fondling his roommate while he was sleeping. The case was transferred to the court office.”

Lest anyone think the situation couldn’t possibly be as grave as it sounds: The Daily Herald recently reported that former BYU student Antonio Rubalcaba Lacy, almost certainly the unnamed suspect in the Police Beat report, was convicted of six counts of forcible sexual abuse of two of his roommates.

I praise The Universe for reporting in February on the charges in this difficult case. I also agree with the gist of the crime article, which is that we are blessed to live in a community where crime rates are relatively low. However I would ask that all Universe journalists writing about crime at BYU, or even wider communities, respect the victims of actual, serious crimes by remembering that real crime is much more than silly anecdotes about mistakenly suspicious persons or stolen cookies.

I felt like I needed to speak out against the tone of the article and couldn't focus on anything else until I did, so I cranked this letter out (fairly meticulously, but in basically one sitting) and emailed it in. I hope doing it so quickly wasn't a mistake. I had misgivings about delving into a lurid crime, but I felt the best way to fight "Police Beat jokes" was to seriously examine a Police Beat report that was not funny. (I don't blame anyone for laughing at some of the stories in the Police Beat, but I took issue with a serious article about crime starting off that way.) I also didn't want to drag a name into it, but I wanted the information to be verifiable. I hoped the Universe would reject or edit the letter if anything was totally inappropriate. (I didn't notice any edits.) I recognize that citing this case could be construed as "using" it to make a point, something not unlike what I condemn – I apologize if anyone feels I have done so, or otherwise been tactless.

If you're wondering what I meant by "self-righteous and self-aggrandizing tone," you'll have to read the original article to judge the tone for yourself, but here's a sentence that got to me:

According to the FBI’s “Offenses Known to Law Enforcement” 2009 table, though BYU’s enrollment is just over 6,000 more than the University of Utah’s, the Utes take the cake in crime report statistics: U of U’s 604 property crimes to BYU’s 283; their 540 larceny-thefts compared to the Cougars’ 270; and two forcible rapes to BYU’s zero.

Read: "We're better than those heathen Utes. Property crimes, larceny, blah blah, and best for last: nobody reported a rape here, but two were reported there!" They "take the cake" – how disgusting! Fellow human being(s) at another school were raped at least twice, but that puts BYU up a few points on this writer's rivalry scorecard.

Underlying the distasteful back-patting in that sentence are more problems: Why cite old stats from 2009? The FBI has released Offenses Known to Law Enforcement, by State by University and College, 2010 and preliminary data for 2011. How is someone who was raped after 2009, or who was raped and didn't report it or didn't win a conviction, supposed to feel? Someone who was sexually assaulted in a way other than the FBI's "forcible rape"? At the time of the statistics cited, it was defined narrowly as "the carnal knowledge of a female, forcibly and against her will" (source; see for more graphic description of what this really means.) To be clear, other sexual crimes will be prosecuted locally, but this comparison hinges on the FBI's reports on "forcible rape."

Sensitivity, definitions, and timelines aside, are these stats even a meaningful comparison? No! Don't take my word for it; here's what the FBI, the publisher of the report cited in the article, says: "UCR data are sometimes used to compile rankings of individual jurisdictions and institutions of higher learning. These incomplete analyses have often created misleading perceptions which adversely affect geographic entities and their residents... Data users should not rank locales because there are many factors that cause the nature and type of crime to vary from place to place" ("Uniform Crime Reporting Statistics: Their Proper Use"). Admittedly, the article does note, "Taking into account the downtown area and high volume of tourists [in Salt Lake City], it seems more justifiable that the U of U has a larger amount of crime," but in context it still seems to be only so that Provo and BYU can be called "a breath of fresh air" by comparison.

Today, the Supreme Court issued a historic ruling: They upheld the Affordable Care Act and ensured that millions of American families will have access to health care and protection from the worst abuses of the insurance industry.

We're protected from the "worst abuses" of the insurance industry! But only the very worst; I guess they have to let the lesser abuses continue so Big Insurance/Medical campaign money will keep rolling in.