As far as hobbies go, auditing high security external hard drives is not terribly popular. But it’s what [Raphaël Rigo] is into, and truth be told, we’re glad it’s how he gets his kicks. Not only does it make for fascinating content for us to salivate over, but it’s nice to know there’s somebody with his particular skill set out there keeping an eye out for dodgy hardware.
The latest device to catch his watchful eye is the Aigo “Patriot” SK8671. In a series of posts on his blog, [Raphaël] tears down the drive and proceeds to launch several attacks against it until he finally stumbles upon the trick to dump the user’s encryption PIN. It’s not exactly easy, it did take him about a week of work to sort it all out, but it’s bad enough that you should probably take this particular item off the wishlist on your favorite overseas importer.
[Raphaël] treats us to a proper teardown, including gratuitous images of chips under the microscope. He’s able to identify a number of components on the board, including a PM25LD010 SPI flash chip, Jmicron JMS539 USB-SATA controller, and Cypress CY8C21434 microcontroller. By hooking his logic analyzer up to the SPI chip he was able to dump its contents, but didn’t find anything that seemed particularly useful.
The second post in the series has all the gory details on how he eventually gained access to the CY8C21434 microcontroller, including a description of the methods which didn’t work (something we always love to see). [Raphaël] goes into great detail about the attack that eventually busted the device open: “cold boot stepping”. This method allowed him to painstakingly copy the contents of the chip’s flash; pulling 8192 bytes from the microcontroller took approximately 48 hours. By comparing flash dumps he was able to eventually discover where the PIN was being stored, and as an added bonus, found it was in plaintext. A bit of Python later, and he had a tool to pull the PIN from the drive’s chip.
This isn’t the first time we’ve seen a “secure” hard drive that ended up being anything but. We’ve even been witness to a safe being opened over Bluetooth. Seems like this whole “Security by Obscurity” thing might not be such a hot idea after all…
So, I had an idea that seems like it’d be great, if not for all the security, and methods to prevent direct access, of using an old hard drive as an encoder. Basically, say every 10th of a mm, have it switch from all N to S or vice versa, for a really low speed 1rpd thing.
I can’t seem to find anyone doing anything similar, but a hard drive seems like it’d have everything needed for it, and would be amazingly high resolution compared to anything else I’ve come across.
I developed a security product that I sell on Tindie. It’s an open hardware – open firmware project, and I think being open in the crypto/security space makes all the difference.
The problem is that a lot of crypto hardware (things like i2c ECDSA chips and secure elements and the like) require an NDA to get the full datasheet. And even when you’re willing to sign one, since you’re not a Big Company(tm), they just tell you “no.”
Microchip has an application note that talks about the TRNG in the SAMS70 chips. Since I use that TRNG, I wanted to see that AN so that I could at least see how they evaluated its quality and perhaps learn something. Six weeks of trying to get them to let me see it and they finally told me to pound sand.
It’s all very discouraging.
If the only people who can prove your product is vulnerable are the people who have something to lose by doing so, you’re least likely to be found out. Anyone truly confident in the security of his product will invite the public to have a go, They obviously don’t, so we know what to conclude.
A very interesting read, the summary completely glances over the main fruit of this work–the ability to dump the firmware out of write a read-protected cypress 2000 series PSOC.
It reminds me of Dimitry’s successful efforts to dump the cypress SROM for the 4000 series chips http://dmitry.gr/index.php?r=05.Projects&proj=23.%20PSoC4
I wonder if the same techniques could be used to further exploit the SROM on this 2000 series chip, and for that matter if this timing attack would allow bypassing the read protection registers in the 4000 series as well.
In any case, it seems like there are a lot of interesting vulnerabilities in the cypress SROM code!
It doesn’t seem like there would be anything interesting in there beyond the PIN. Or are you saying more that this is a technique which might be useful on other devices?
PSoC4,6, and maybe 5 do NOT allow RAM access when protected, so this attack is not mounteable against PSoC4
it’s interesting that they even had the key stored in the one place, and had it plain text – sort of like it was in the 1970’s..
But even if you don’t do that the core problem is the above approach works, and if the data or program are stored off chip then something can sniff it, and even if it is on chip there are ways..
The issue I have with the stand alone ‘security chips’ is that you can just remove them and put something else there – that’s been done in my local community as a project recently for a particular piece of electronics… Replace on chip and you are good to go!
But for the hard disk above the approach it is particular stupid, as why was it storing the password at all? Surely you should have to enter it every time you power cycle the drive???
Last things first. Surely, yes you do have to enter the pin every time you power cycle the drive. That’s the idea.
In cases like this, they should use a chip with on-the-fly AES encryption in the datapath. And they should NOT store the pin and then enable access to the encrytped data on the drive. The best thing to do is to encrypt the data with something derived from the PIN. Or to make changing the PIN easier, encrypt the real (random) key with the pin.
But alas, the systems that do that are not too common.
I’m not sure I follow you but it does sound a bit like Playstation 1 disc protection. IIRC, there was a deliberate wobble in the track error correction marks which was used to both protect and region lock the disc.
… does it sound like that? This is just finding a way to dump the flash contents of a chip, not really related to the physical aspects of the drive at all.
I would never rely on such device’s “security” features, they’re usually advertised as “military grade AES256” or something like that, but implementation is terrible and easily beatable. I prefer normal hard drive with VeraCrypt, LUKS or some other open-source based encryption software that passed many audits and is thoroughly tested.
This depends on the computer have the necessary software though, while a hardware solution is obviously completely software independent.
Why hasn’t anyone done this with Josh Powell’s hard drive?