If you’re the kind of person who has friends, and/or leaves the confines of the basement from time to time, we hear that these “Escape Rooms” are all the rage. Basically you get locked into a room with a couple other people and have to solve various problems and puzzles until you’ve finally made enough progress that they let you out. Which actually sounds a lot like the working conditions here at Hackaday HQ, except they occasionally slip some pizza rolls under the door for us which is nice.
Whichever side you find yourself on in one of these lighthearted hostage situations, knowledge of this multi-tag RFID lock created by [Annaane] may come in handy. By connecting multiple MFRC522 RFID readers to an Arduino Uno, she’s come up with a method of triggering a device (like an electronic door lock) only when the appropriate combination of RFID tags have been arranged. With a little imagination, this allows for some very complex puzzle scenarios which are sure to keep your prisoners enthralled until you can lower the lotion down to them.
Her code allows you to configure the type and number of RFID cards required to trigger one of the Arduino’s digital pins, which usually would be connected to a relay to fire off whatever device you want. The Arduino sketch is also setup to give “hints” to the player by way of a status LED: fast blinking let’s you know the tag scanned is wrong, and slow blinking means you don’t have enough scanned in yet.
The video after the break shows some highlights of the build, as well as a quick demonstration of how both the RFID “combination” and manual override can be used to trigger the attached relay.
Hackers do love RFID. Using them for physical access control is a fairly common project around these parts, and we’ve even seen similar setups for the digital realm.
Continue reading “Held Captive by Arduino and Multiple RFID Readers”
It’s fair to say that fingerprints aren’t necessarily the best idea for device authentication, after all, they’re kind of everywhere. But in some cases, such as a device that never leaves your home, fingerprints are an appealing way to speed up repetitive logins. Unfortunately, fingerprint scanners aren’t exactly ubiquitous pieces of hardware yet. We wouldn’t hold out much hope for seeing a future Raspberry Pi with a fingerprint scanner sitting on top, for example.
Looking for a cheap way to add fingerprint scanning capabilities to his devices, [Nicholas] came up with a clever solution that is not only inexpensive, but multi-functional. By combining a cheap USB hub with a fingerprint scanner that was intended as a replacement part of a Thinkpad laptop, he was able to put together a biometric USB hub for around $5 USD.
After buying the Thinkpad fingerprint scanner, he wanted to make sure it would be detected by his computer as a standard USB device. The connector and pinout on the scanner aren’t standard, so he had to scrape off the plastic coating of the ribbon cable and do some probing with his multimeter to figure out what went where. Luckily, once he found the ground wire, the order of the rest of the connections were unchanged from normal USB.
When connected to up his Ubuntu machine, the Thinkpad scanner came up as a “STMicroelectronics Fingerprint Reader”, and could be configured with libpam-fprintd.
With the pintout and software configuration now known, all that was left was getting it integrated into the USB hub. One of the hub’s ports was removed and filled in with hot glue, and the fingerprint scanner connected in its place. A hole was then cut in the case of the hub for the scanner to peak out of. [Nicholas] mentions his Dremel is on loan to somebody else at the moment, and says he’ll probably try to clean the case and opening up a bit when he gets it back.
[Nicholas] was actually inspired to tackle this project based on a Hackaday post he read awhile back, so this one has truly come full circle. If you’d like to learn more about fingerprint scanning and the techniques being developed to improve it, we’ve got some excellent articles to get you started.
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”
Building a circuit from prototyping to printed circuit board assembly is within the reach of pretty much anyone with the will to get the job done. If that turns out to be something that everyone else wants, though, the job gets suddenly much more complex. This is what happened to [Conor], who started with an idea to create two-factor authentication tokens and ended up manufacturing an selling them on Amazon. He documented his trials and tribulations along the way, it’s both an interesting and perhaps cautionary tale.
[Conor]’s tokens themselves are interesting in their simplicity: they use an Atmel ATECC508A specifically designed for P-256 signatures and keys, a the cheapest USB-enabled microcontroller he could find: a Silicon Labs EFM8UB1. His original idea was to solder all of the tokens over the course of one night, which is of course overly optimistic. Instead, he had the tokens fabricated and assembled before being shipped to him for programming.
Normally the programming step would be straightforward, but using identical pieces of software for every token would compromise their security. He wrote a script based on the Atmel chip and creates a unique attestation certificate for each one. He was able to cut a significant amount of time off of the programming step by using the computed values with a programming jig he built to flash three units concurrently. This follows the same testing and programming path that [Bob Baddeley] advocated for in his Tools of the Trade series.
From there [Conor] just needed to get set up with Amazon. This was a process worthy of its own novel, with Amazon requiring an interesting amount of paperwork from [Conor] before he was able to proceed. Then there was an issue of an import tariff, but all-in-all everything seems to have gone pretty smoothly.
Creating a product from scratch like this can be an involved process. In this case it sounds like [Conor] extracted value from having gone through the entire process himself. But he also talks about a best-case-scenario margin of about 43%. That’s a tough bottom line but a good lesson anyone looking at building low-cost electronics.
Researchers [Christian Holz] and [Marius Knaust] have come up with a cool new way to authenticate you to virtually any touchscreen device. This clever idea couples a biometric sensor and low-data-rate transmitter in a wearable wrist strap that talks to the touch screen by electrifying you.
Specifically the strap has electrodes that couple a 50V, 150kHz signal through your finger, to the touchscreen. The touchscreen picks up both your finger’s location through normal capacitive-sensing methods and the background signal that’s transmitted by the “watch”. This background signal is modulated on and off, transmitting your biometric data.
The biometric data itself is the impedance through your wrist from one electrode to another. With multiple electrodes encircling your wrist, they end up with something like a CAT scan of your wrist’s resistance. Apparently this is unique enough to be used as a biometric identifier. (We’re surprised.)
Continue reading “Biometric Bracelet Electrifies You to Unlock Your Tablet”
[Christian Holz, Senaka Buthpitiya, and Marius Knaust] are researchers at Yahoo that have created a biometric solution for those unlucky folks that always forget their smartphone PIN codes. Bodyprint is an authentication system that allows a variety of body parts to act as the password. These range from ears to fists.
Bodyprint uses the phone’s touchscreen as an image scanner. In order to do so, the researchers rooted an LG Nexus 5 and modified the touchscreen module. When a user sets up Bodyprint, they hold the desired body part to the touchscreen. A series of images are taken, sorted into various intensity categories. These files are stored in a database that identifies them by body type and associates the user authentication with them. When the user wants to access their phone, they simply hold that body part on the touchscreen, and Bodyprint will do the rest. There is an interesting security option: the two person authentication process. In the example shown in the video below, two users can restrict file access on a phone. Both users must be present to unlock the files on the phone.
How does Bodyprint compare to capacitive fingerprint scanners? These scanners are available on the more expensive phone models, as they require a higher touchscreen resolution and quality sensor. Bodyprint makes do with a much lower resolution of approximately 6dpi while increasing the false rejection rate to help compensate. In a 12 participant study using the ears to authenticate, accuracy was over 99% with a false rejection rate of 1 out of 13.
Continue reading “Your Body is Your PIN with Bodyprint”
[HD Moore] recently posted an article on Rapid 7’s blog about an interesting security problem. They’ve been doing some research into the security of automated tank gauges (ATGs). These devices are used at gas stations and perform various functions including monitoring fuel levels, tracking deliveries, or raising alarms. [Moore] says that ATGs are used at nearly every fueling station in the United States, but they are also used internationally. It turns out these things are often not secured properly.
Many ATG’s have a built-in serial port for programming and monitoring. Some systems also have a TCP/IP card, or even a serial to TCP/IP adapter. These cards allow technicians to monitor the system remotely. The most common TCP port used in these systems is port 10001. Some of these systems have the ability to be password protected, but Rapid 7’s findings indicate that many of them are left wide open.
The vulnerability was initial reported to Rapid 7 by [Jack Chadowitz]. He discovered the problem due to his work within the industry and developed his own web portal to help people test their own systems. [Jack] approached Rapid 7 for assistance in investigating the issue on a much larger scale.
Rapid 7 then scanned every IPv4 address looking for systems with an open port 10001. Each live system discovered was then sent a “Get In-Tank Inventory Report” request. Any system vulnerable to attack would respond with the station name, address, number of tanks, and fuel types. The scan found approximately 5,800 systems online with no password set. Over 5,300 of these stations are in the United States.
Rapid 7 believes that attackers may be able to perform such functions as to reconfigure alarm thresholds, reset the system, or otherwise disrupt operation of the fuel tank. An attacker might be able to simulate false conditions that would shut down the fuel tank, making it unavailable for use. Rapid 7 does not believe this vulnerability is actively being exploited in the wild, but they caution that it would be difficult to tell the difference between an attack and a system failure. They recommend companies hide their systems behind a VPN for an additional layer of security.