Speeding Up IOTA Proof Of Work Using FPGAs

Blockchain has existed as a concept since the early 1990s, but keeping a distributed ledger for IoT transactions wasn’t widely implemented until IOTA developed Tangle. The blockchain company was initially founded as a hardware startup and pivoted to work on transactional settlement for IoT. The Tangle, their distributed ledger architecture based on a directed acyclic graph (DAG) works as a “blockchain without the blocks and the chain”.

As its name implies, the Tangle is a web of transactions that references its past two transactions and a subsection of other transactions. Rather than miners and stakers being responsible for overall consensus, all active participants are involved in the approval of transactions. The transaction process requires the client to sign with their private keys, select two random unconfirmed transactions to be referenced, and perform proof-of-work.

The proof-of-work has an unfortunately high difficulty as you might expect. The process is similar to finding a nonce in Bitcoin mining, although the difficulty is set at a lower threshold due to the transactions running on lower-power nodes. Even so, since IOTA transactions commonly occur on small embedded platforms this can take several minutes to complete, a relatively long time considering these are mere transactions.

Since Curl-P81 hashes should be computed in parallel, they can’t be computed efficiently on general purpose CPUs. The PiDiver 1.3, [Thomas Pototschnig]’s port of the IOTA Reference Implementation (IRI) PearlDiver, performs searches for nonces. Because it runs on FPGAs, it is able to speed up the proof-of-work by a factor of more than 140 when compared to a Raspberry Pi. The FPGA is able to calculate one round of the hash in a single clock cycle, and a complete hash in 85 cycles (as well as testing for a valid nonce). Seven parallel hashes can be calculated at once, giving 15.8MHash/s at a frequency of 188MHz. The proof-of-work takes ~300ms on the FPGA when compared to 90s on a Raspberry Pi, so this is a significant improvement in speed.

Since the project is open source, the core can be used by IRI for creating a modified version of their PearlDiver.  The board can be used as a Raspberry Pi HAT, although it can also be connected via USB to work without the Pi.

While this doesn’t address the security concerns of using IOTA with personal IoT devices, it is certainly a significant improvement on the speed of their proof-of-work process, and the software speedup is incredibly satisfying to watch.

Continue reading “Speeding Up IOTA Proof Of Work Using FPGAs”

Side-Channel Attack Shows Vulnerabilities Of Cryptocurrency Wallets

What’s in your crypto wallet? The simple answer should be fat stacks of Bitcoin or Ethereum and little more. But if you use a hardware cryptocurrency wallet, you may be carrying around a bit fat vulnerability, too.

At the 35C3 conference last year, [Thomas Roth], [Josh Datko], and [Dmitry Nedospasov] presented a side-channel attack on a hardware crypto wallet. The wallet in question is a Ledger Blue, a smartphone-sized device which seems to be discontinued by the manufacturer but is still available in the secondary market. The wallet sports a touch-screen interface for managing your crypto empire, and therein lies the weakness that these researchers exploited.

By using a HackRF SDR and a simple whip antenna, they found that the wallet radiated a distinctive and relatively strong signal at 169 MHz every time a virtual key was pressed to enter a PIN. Each burst started with a distinctive 11-bit data pattern; with the help of a logic analyzer, they determined that each packet contained the location of the key icon on the screen.

Next step: put together a training set. They rigged up a simple automatic button-masher using a servo and some 3D-printed parts, and captured signals from the SDR for 100 presses of each key. The raw data was massaged a bit to prepare it for TensorFlow, and the trained network proved accurate enough to give any hardware wallet user pause – especially since they captured the data from two meters away with relatively simple and concealable gear.

Every lock contains the information needed to defeat it, requiring only a motivated attacker with the right tools and knowledge. We’ve covered other side-channel attacks before; sadly, they’ll probably only get easier as technologies like SDR and machine learning rapidly advance.

[via RTL-SDR.com]

PaperLedger: An E-Ink Cryptocurrency Ticker

For a long time it seemed like e-ink displays were outside the reach of us lowly hackers, as beyond the handful of repurposed Kindles that graced these pages, we saw precious few projects utilizing this relatively exotic display. But that’s changed over the last couple of years, and we’re thrilled to start seeing hackers bend this incredible technology to their will.

A perfect example is PaperLedger, an entry into the 2019 Hackaday Prize by [AIFanatic]. This wireless device is designed to display the current price of various cryptocurrencies on its 2.9-inch e-ink screen and provide audible price alerts with its built-in speaker. It even has a web portal where users can configure the hardware or view more in-depth price information.

The PaperLedger is based on the TTGO T5 V2.2 ESP32, but it looks like [AIFanatic] is in the process of spinning up a new board for the MIT licensed project to address some nagging issues for this particular application. Unfortunately, it doesn’t look like there are any pictures of the new board yet, but a description of the changes on the Hackaday.IO page shows that most of the work seems to be going into improving support for running on batteries.

Even if you’re not interested in cryptocurrency, the PaperLedger looks like a fantastic little e-ink monitor for pretty much anything else you’d like to keep a close eye on. The GPLv3 licensed firmware is available on the project’s GitHub page, so expanding or completely changing the device’s functionality shouldn’t be too tricky for anyone with a desire to do so and a working knowledge of C++.

We’ve seen several projects using the various TTGO boards that mate an ESP32 with a display at this point, and it looks like a great platform to check out if you want to push some data to a little WiFi screen with the minimum amount of hassle.

Space Age Bitcoin Mining On An Apollo AGC

Imagine you’ve got an Apollo Guidance Computer, the machine that took men to the Moon 50 years ago. You’ve spent ages restoring it, and now it’s the only working AGC on the planet. It’s not as though you’re going to fly to the Moon with it, so what do you do with it? Easy – turn it into a perfectly awful Bitcoin mining rig.

The AGC that [Ken Shirriff] and others have been restoring barely resembles a modern computer. The AGC could only do about 40,000 operations per second, but raw speed was far less important than overall reliability and the abundant IO needed to run a crewed spacecraft. It was a spectacular success on the Apollo missions, but [Ken] wanted to know if turning it into a Bitcoin mining rig was possible.

[Ken] gives a great overview of how Bitcoin mining works, with one of the best explanations of the hashing algorithm we’ve seen. Getting that to run on the AGC was no mean feat, especially with limits imposed by the memory addressing scheme and the lack of machine instructions for manipulating words. He eventually got it working, though, clocking in at a screaming 10.3 seconds per Bitcoin hash. [Ken] estimates that the first coin will be successfully mined in a mere 400 zettaseconds, which is about a billion times older than the universe. With about 13 quadrillion years to the first ka-ching, you have plenty of time to watch a block mined in the video below; alas, it was an old block, so no coins were awarded to compensate the team for their efforts.

This isn’t the first time [Ken] has implemented a useless Bitcoin mine. The Xerox Alto mine was actually fast compared to the AGC, but it sure beats the IBM mainframe and punchcards.

Continue reading “Space Age Bitcoin Mining On An Apollo AGC”

This Week In Security: Use Emacs, Crash A Windows Server, And A Cryptocurrency Heist

It looks like Al was right, we should all be using Emacs. On the 4th of June, [Armin Razmjou] announced a flaw in Vim that allowed a malicious text file to trigger arbitrary code execution. It’s not every day we come across a malicious text file, and the proof of concept makes use of a clever technique — escape sequences hide the actual payload. Printing the file with cat returns “Nothing here.” Cat has a “-v” flag, and that flag spills the secrets of our malicious text file. For simplicity, we’ll look at the PoC that doesn’t include the control characters. The vulnerability is Vim’s modeline function. This is the ability to include editor options in a text file. If a text file only works with 80 character columns, a modeline might set “textwidth=80”. Modeline already makes use of a sandbox to prevent the most obvious exploits, but [Armin] realized that the “:source!” command could run the contents of a file outside that sandbox. “:source! %” runs the contents of the current file — the malicious text file.

:!uname -a||" vi:fen:fdm=expr:fde=assert_fails("source\!\ \%"):fdl=0:fdt="

Taking this apart one element at a time, the “:!” is the normal mode command to run something in the shell, so the rest of the line is what gets run. “uname -a” is the arbitrary command, benign in this case. Up next is the OR operator, “||” which fully evaluates the first term first, and only evaluates what comes after the operator if the first term returns false. In this case, it’s a simple way to get the payload to run even though the rest of the line is garbage, as far as bash is concerned. “vi:” informs Vim that we have a modeline string. “:fen” enables folding, and “:fdm=expr” sets the folding method to use an expression. This feature is usually used to automatically hide lines matching a regular expression. “:fde=” is the command to set the folding expression. Here’s the exploit, the folding expression can be a function like “execute()” or “assert_fails()”, which allows calling the :source! command. This pops execution out of the sandbox, and begins executing the text file inside vim, just as if a user were typing it in from the keyboard. Continue reading “This Week In Security: Use Emacs, Crash A Windows Server, And A Cryptocurrency Heist”

Radio Free Blockchain: Bitcoin From Space

Cryptocurrencies: love them, hate them, or be baffled by them, but don’t think you can escape them. That’s the way it seems these days at least, with news media filled with breathless stories about Bitcoin and the other cryptocurrencies, and everyone from Amazon to content creators on YouTube now accepting the digital currency for payments. And now, almost everyone on the planet is literally bathed in Bitcoin, or at least the distributed ledger that makes it work, thanks to a new network that streams the Bitcoin blockchain over a constellation of geosynchronous satellites.

Continue reading “Radio Free Blockchain: Bitcoin From Space”

Mining Bitcoin On The ESP32 For Fun, Definitely Not Profit

Bitcoin’s great, if you sold at the end of 2017. If you’re still holding, your opinion might be a little more sour. The cost to compete in the great hashing race continues to rise while cryptocurrency values remain underwhelming. While getting involved at the top end is prohibitively expensive, you can still have some fun with the basic concepts – as [Jake] did, by calculating Bitcoin hashes on the ESP32.

It’s a project that is very much done for fun, rather than profit. [Jake] notes that even maxing out both cores, it would take 31 billion years to mine one block at current difficulty levels. Regardless, the underlying maths is nothing too crazy. Double-hashing the right data with the SHA256 algorithm is all that’s required, a task that is well within the ESP32’s capabilities. There’s hardware acceleration available, too – though this is weirdly slower than doing it in software.

Overall, you’re not going to get rich hashing Bitcoin on a cheap microcontroller platform. You might just learn something useful, though. If this isn’t weird enough though, you could always try the same thing on a 1970s Xerox Alto.