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.
DRM has become a four-letter word of late, with even media companies themselves abandoning the practice because of how ineffective it was. DRM wasn’t invented in the early 2000s for music, though. It’s been a practice on virtually everything where software is involved, including arcade cabinets. This is a problem for people who restore arcade machines, and [mon] has taken a swing at unraveling the DRM for a specific type of Konami cabinet.
The game in question, Reflec Beat, is a rhythm-based game released in 2010, and the security is pretty modern. Since the game comes with a HDD, a replacement drive can be ordered with a security dongle which acts to decrypt some of the contents on the HDD, including the game file and some other information. It’s not over yet, though. [mon] still needs to fuss with Windows DLL files and a few levels of decryption and filename obfuscation before getting the cabinet functional again.
The writeup on this cabinet is very detailed, and if you’re used to restoring older games, it’s a bit of a different animal to deal with than the embedded hardware security that older cabinets typically have. If you’ve ever wanted to own one of these more modern games, or you’re interested in security, be sure to check out the documentation on the project page. If your tastes are more Capcom and less Konami, check out an article on their security system in general, or in de-suiciding boards with failing backup batteries.
[tomwimmenhove] has found a vulnerability in the cryptographic algorithm that is used by certain Subaru key fobs and he has open-sourced the software that drives this exploit. All you need to open your Subaru is a RasPi and a DVB-T dongle, so you could complain that sharing this software equates to giving out master keys to potential car thieves. On the other hand, this only works for a limited number of older models from a single manufacturer — it’s lacking in compatibility and affordability when compared to the proverbial brick.
This hack is much more useful as a case study than a brick is, however, and [tomwimmenhove]’s work points out some bad design on the manufacturer’s side and as such can help you to avoid these kind of mistakes. The problem of predictable keys got great treatment in the comments of our post about an encryption scheme for devices low in power and memory, for instance.
Those of you interested in digital signal processing may also want to take a look at his code, where he implements filtering, demodulation and decoding of the key fob’s signal. The transmission side is handled by rpitx and attacks against unencrypted communications with this kind of setup have been shown here before. There’s a lot going on here that’s much more interesting than stealing cars.
Encryption is one of the pillars of modern-day communications. You have devices that use encryption all the time, even if you are not aware of it. There are so many applications and systems using it that it’s hard to begin enumerating them. Ranging from satellite television to your mobile phone, from smart power meters to your car keys, from your wireless router to your browser, and from your Visa to your Bitcoins — the list is endless.
One of the great breakthroughs in the history of encryption was the invention of public key cryptography or asymmetrical cryptography in the 70’s. For centuries traditional cryptography methods were used, where some secret key or scheme had to be agreed and shared between the sender and the receiver of an encrypted message.
Asymmetric cryptography changed that. Today you can send an encrypted message to anyone. This is accomplished by the use of a pair of keys: one public key and one private key. The key properties are such that when something is encrypted with the public key, only the private key can decrypt it and vice-versa. In practice, this is usually implemented based on mathematical problems that admit no efficient solution like certain integer factorization, discrete logarithm and elliptic curve relationships.
But the game changer is that the public key doesn’t have to be kept secret. This allows cryptography to be used for authentication — proving who someone is — as well as for encryption, without requiring you to have previously exchanged secrets. In this article, I’ll get into the details of how to set yourself up so that anyone in the world is able to send you an e-mail that only you can read. Continue reading “Practical Public Key Cryptography”→
So, erm… good news everyone! A vulnerability has been found in a software library responsible for generating RSA key pairs used in hardware chips manufactured by Infineon Technologies AG. The vulnerability, dubbed ROCA, allows for an attacker, via a Coppersmith’s attack, to compute the private key starting with nothing more than the public key, which pretty much defeats the purpose of asymmetric encryption altogether.
Affected hardware includes cryptographic smart cards, security tokens, and other secure hardware chips produced by Infineon Technologies AG. The library with the vulnerability is also integrated in authentication, signature, and encryption tokens of other vendors and chips used for Trusted Boot of operating systems. Major vendors including Microsoft, Google, HP, Lenovo, and Fujitsu already released software updates and guidelines for mitigation.
The researchers found and analysed vulnerable keys in various domains including electronic citizen documents (750,000 Estonian identity cards), authentication tokens, trusted boot devices, software package signing, TLS/HTTPS keys and PGP. The currently confirmed number of vulnerable keys found is about 760,000 but could be up to two to three orders of magnitude higher.
Devices dating back to at least 2012 are affected, despite being NIST FIPS 140-2 and CC EAL 5+ certified.. The vulnerable chips were not necessarily sold directly by Infineon Technologies AG, as the chips can be embedded inside devices of other manufacturers.
It seems that new stories of insecure-by-design IoT devices surface weekly, as the uneasy boundary is explored between the appliance and the Internet-connected computer. Manufacturers like shifting physical items rather than software patches, and firmware developers may not always be from the frontline of Internet security.
An interesting aside on the security of IoT traffic comes from [boz], who has taken a look at encryption of very low data rate streams from underpowered devices. Imagine perhaps that you have an Internet-connected sensor which supplies only a few readings a day that you would like to keep private. Given that your sensor has to run on tiny power resources so a super-powerful processor is out of the question, how do you secure your data? Simple encryption schemes are too easily broken.
He makes the argument for encryption from a rather unexpected source: a one-time pad. We imagine a one-time pad as a book with pages of numbers, perhaps as used by spies in Cold-War-era East Berlin or something. Surely storing one of those would be a major undertaking! In fact a one-time pad is simply a sequence of random keys that are stepped through, one per message, and if your message is only relatively few bytes a day then you have no need to generate more than a few K of pad data to securely encrypt it for years. Given that even pretty meager modern microcontrollers have significant amounts of flash at their disposal, pad storage for sensor data of this type is no longer a hurdle.
Where some controversy might creep in is the suggestion that a pad could be recycled when its last entry has been used. You don’t have to be a cryptologist to know that reusing a one-time pad weakens the integrity of the cypher, but he has a valid answer there too, If the repeat cycle is five years, your opponent must have serious dedication to capture all packets, and at that point it’s worth asking yourself just how sensitive the sensor data in question really is.
There was a time that encryption was almost a dirty word; a concept that really only applied to people with something to hide. If you said you wanted to encrypt your hard drive, it may as well have been an admission to a crime. But now more than ever it’s clear that encryption, whether it’s on our personal devices or on the web, is a basic necessity in a digital society. The age of Big Data is upon us, and unless you’re particularly fond of being a row in a database, you need to do everything you can to limit the amount of plaintext data you have.
Of course, it’s sometimes easier said than done. Not everyone has the time or desire to learn how the different cryptographic packages work, others may be working on systems that simply don’t have the capability. What do you do when you want to encrypt some files, but the traditional methods are out of reach?
Enter the latest project from [Dimitris Platis]: Cryptopuck. By combining the ever-versatile Raspberry Pi Zero, some clever Python programs, and a few odds and ends in a 3D printed case, he has created a completely self-contained encryption device that anyone can use. Stick a USB flash drive in, wait for the LED to stop blinking, and all your files are now securely encrypted and only accessible by those who have the private key. [Dimitris] envisions a device like this could be invaluable for reporters and photographers on the front lines, protesters, or really anyone who needs a discreet way of quickly securing data but may not have access to a computer.
The hardware side is really just the Pi, a switch, a single LED for notifications, and a battery. The real magic comes from the software, where [Dimitris] has leveraged PyCrypto to perform the AES-256 encryption, and a combination of pyinotify and udiskie to detect new mounted volumes and act on them. The various Python scripts that make up the Cryptopuck suite are all available on the project’s GitHub page, but [Dimitris] makes it very clear the software is to be considered a proof of concept, and has not undergone any sort of security audit.