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.
[Via Bleeping Computer]
Continue reading “Exploiting Weak Crypto on Car Key Fobs”
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.
Continue reading “Bad RSA Library Leaves Millions of Keys Vulnerable”
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.
For some background information on how the software used by the Cryptopuck works you may want to check out this excellent primer from a few years back; though if you’d like to read up on why encryption is so important, you don’t need to go nearly as far back in time.
Continue reading “Encrypt Data On the Fly On a Pi With Cryptopuck”
The Espressif ESP8266 chipset makes three-dollar ‘Internet of Things’ development boards an economic reality. According to the popular automatic firmware-building site nodeMCU-builds, in the last 60 days there have been 13,341 custom firmware builds for that platform. Of those, only 19% have SSL support, and 10% include the cryptography module.
We’re often critical of the lack of security in the IoT sector, and frequently cover botnets and other attacks, but will we hold our projects to the same standards we demand? Will we stop at identifying the problem, or can we be part of the solution?
This article will focus on applying AES encryption and hash authorization functions to the MQTT protocol using the popular ESP8266 chip running NodeMCU firmware. Our purpose is not to provide a copy/paste panacea, but to go through the process step by step, identifying challenges and solutions along the way. The result is a system that’s end-to-end encrypted and authenticated, preventing eavesdropping along the way, and spoofing of valid data, without relying on SSL.
We’re aware that there are also more powerful platforms that can easily support SSL (e.g. Raspberry Pi, Orange Pi, FriendlyARM), but let’s start with the cheapest hardware most of us have lying around, and a protocol suitable for many of our projects. AES is something you could implement on an AVR if you needed to.
Continue reading “Practical IoT Cryptography on the Espressif ESP8266”