The Contrarian Response To Apple’s Need For Encryption

On December 2, 2015, [Syed Rizwan Farook] and [Tashfeen Malik] opened fire at a San Bernardino County Department of Public Health training event, killing 14 and injuring 22. This was the third deadliest mass shooting in the United States in recent memory, and began a large investigation by local, state, and federal agencies. One piece of evidence recovered by the FBI was an iPhone 5C belonging to one of the shooters. In the days and months after the shooting, the FBI turned to Apple to extract data from this phone.

A few days ago in an open letter to customers, [Tim Cook], CEO of Apple, stated they will not comply with FBI’s request to build a backdoor for the iPhone. While the issue at hand is extracting data from an iPhone recovered from the San Bernardino shooting, [Cook] says building a new version of iOS to extract this data would allow the FBI to unlock any iPhone. Needless to say, there are obvious security implications of this request.

Apple does not publish open letters to its customers often. Having one of the largest companies on the planet come out in support of privacy and encryption is nearly unprecedented. There is well-founded speculation this open letter to the public will be exhibit A in a supreme court case. Needless to say, the Internet has gone a little crazy after this letter was published, and rightly so: just imagine how better off we would be if AT&T said no to the NSA in 2002 – [Snowden] might just be another IT geek working for a government contractor.

CalvinThere is a peculiar aspect of public discourse that doesn’t make any sense. In the absence of being able to say anything interesting, some people have just decided to add a contrary viewpoint. Being right, having a valid argument, or even having evidence to support assertions doesn’t matter; being contrary is far more interesting. Look at any comment thread on the Internet, and you’ll find the longest comment chain is the one refuting the parent article. Look up the ratings for a cable news channel. You’ll find the highest rated show is the one with the most bickering. When is the last time you saw something from the New York Times, Washington Post, or LA Times on Facebook or your favorite news aggregator? Chances are, it wasn’t news. It was an op-ed, most likely one that was espousing a view contrary to either public opinion or public policy.

As with any headline event on the Internet, the contrarians have come out of the woodwork. These contrarians are technically correct and exceedingly myopic.

Continue reading “The Contrarian Response To Apple’s Need For Encryption”

This File Will Self-Destruct in 24 hours

[menkveldj] built a service that encrypts files which self destruct in 24 hours. The download link can only be used once. If the wrong people were to get the link and download the file, they’d need many years on a pretty powerful computer to crack the 256AES encryption.

The sender shares a file that is encrypted client side using a password generated Pbkdf2 key to encrypt the data before uploading it to the s3 storage service. The sender is then provided the one-time-use link to share with the recipient. After the first download, or 24 hours, the link and the encrypted file are both deleted. The receiver must enter the same password to decrypt and recover the file. No one but the sharer and receiver know what the actual file is.

It’s still work in progress, so chime in with your comments and suggestions. To dig into the code, check out his repository on Github, which also has instructions to build and run it if you’d like to do your own version.

Oh, and you’ll like this. If want to thumb your nose at the powers that be, the site has a redirect for the whimsical domain: NSAfu.com.

Encryption for Arduino with Spritz

Hackaday.io user [Abderraouf] has written an implementation of the new(ish) Spritz cipher and hash for Arduino. While we’re not big enough crypto-nerds to assess the security of the code, it looks like it’s going to be pretty handy.

Spritz itself is a neat cipher. Instead of taking in fixed blocks of data and operating on them, it allows you to process it in (almost) whatever chunks it comes in naturally, and then extract out the encrypted results piecewise. It works both as a two-way cipher and as a one-way hash function. It looks like Spritz is a one-stop-shop for all of your encryption needs, and now you can run it on your Arduino.

In case you are afraid of new implementations of new ciphers (and you should be), Spritz’s pedigree should help to put you at ease: it was developed by [Ron Rivest] to be a successor to his RC4 algorithm, and it incorporates a lot of the lessons learned about that algorithm over the past. This doesn’t exclude subtle flaws in the implementation of the library (no offence, [Abderraouf]!) or your work downstream, but at least the underlying algorithm seems to be the real deal.

[Abderraouf] links it in his writeup, but just for completeness, here’s the Spritz paper (PDF). What crypto libraries do you currently use for Arduino or microcontroller projects? We’ve been fans of XXTEA for ages, but more because it’s simple and small than because it’s secure. Spritz may be simple enough to implement easily, and still more secure. Sweet.

Saving an Alarm System Remote and $100

[Simon] has been using his home alarm system for over six years now. The system originally came with a small RF remote control, but after years of use and abuse it was finally falling apart. After searching for replacement parts online, he found that his alarm system is the “old” model and remotes are no longer available for purchase. The new system had similar RF remotes, but supposedly they were not compatible. He decided to dig in and fix his remote himself.

He cracked open the remote’s case and found an 8-pin chip labeled HCS300. This chip handles all of the remote’s functions, including reading the buttons, flashing the LED, and providing encoded output to the 433MHz transmitter. The HCS300 also uses KeeLoq technology to protect the data transmission with a rolling code. [Simon] did some research online and found the thew new alarm system’s remotes also use the same KeeLoq technology. On a hunch, he went ahead and ordered two of the newer model remotes.

He tried pairing them up with his receiver but of course it couldn’t be that simple. After opening up the new remote he found that it also used the HCS300 chip. That was a good sign. The manufacturer states that each remote is programmed with a secret 64-bit manufacturer’s code. This acts as the encryption key, so [Simon] would have to somehow crack the key on his original chip and re-program the new chip with the old key. Or he could take the simpler path and swap chips.

A hot air gun made short work of the de-soldering and soon enough the chips were in place. Unfortunately, the chips have different pinouts, so [Simon] had to cut a few traces and fix them with jumper wire. With the case back together and the buttons in place, he gave it a test. It worked. Who needs to upgrade their entire alarm system when you can just hack the remote?

HDMI Splitter is also a Decrypter

It warms our hearts when the community gets together. [esar] needed to get a decrypted HDMI stream for his home theater system. A tip-off in the comments and a ton of good old-fashioned hacking resulted in a HDMI splitter converted into a full-featured HDMI decrypter. Here’s the story.

His amazing custom Ambilight clone got profiled here, and someone asked him in the comments if it worked when High-bandwidth Digital Content Protection (HDCP) is on. [esar] lamented that it didn’t. Hackaday readers to the rescue. [Alan Hightower] and [RoyTheReaper] pointed [esar] to the fact that HDMI splitters need to decrypt and re-encrypt the signal to pass it on, and pointed him to a trick to knock out the on-board microcontroller. [esar] took off from there.

Unfortunately, taking the micro out of the picture messed with a lot of other HDMI functionality. So [esar] started digging in the datasheets for the HDMI splitter chip, looking for registers relevant to the re-encryption. If he could get in between the microcontroller and the splitter chip on the I2C bus and disable the re-encryption, he’d be set.

If you’re at all interested in I2C hacking or abusing HDMI splitters, you need to read his post because he details all of the tribulations and triumphs. He first tries just brute-forcing the I2C by overwriting a 1 bit with a 0. This (correctly) signals the micro that there’s been a conflict on the bus, so it re-sends the command again. Dead end.

He then found another signal that the receiver could use say that it wasn’t decrypting. He tried sending this continuously to the splitter so that it would stop encrypting. That worked, but only for one channel, some of the time. It turns out that his code was taking too long in his bit-banged I2C code. He fixes this up and all is well? Well, 90% of the way there.

To hammer down the last 10% of the functionality, [esar] buys a couple more splitters, experiments around with another splitter chipset that works with 3D, and solders some more wires to enable the Audio Return Channel. And after a ton of well-documented hard work, he wins in the end.

Crypto Photography and Custom Firmware

Imagine a camera that took encrypted pictures. If your camera is stolen, the only thing on the memory card would be random data that can only be unlocked with a key. If you hire a photographer, those images cannot be copied without the key. At the very least, it’s an interesting idea made impressive because this actually exists.

[Doug] recently got his hands on a Samsung NX300, a nice camera for the price that conveniently runs Linux and is kinda open-sourced by Samsung. With special firmware, [Doug] created public/private key encryption for this camera, giving only the person with the private key the ability to unlock the pictures taken with this camera.

[Doug] started his build by looking at the firmware for this camera, figuring out how to take everything apart and put it back together. With a few modifications that included encryption for all images taken with this camera, [Doug] repackaged the firmware and upgraded the camera.

The encryption firmware is available on the site, but considering how easily [Doug] was able to make this hack happen, and a great walkthrough of how to actually do it raises some interesting possibilities. The NX300 is a pretty nice camera that’s a little bit above the Canon PowerShot cameras supported by CHDK. It also runs Linux, so if you’re looking for something cool to do with a nice camera, [Doug] has a very good resource.

Reverse Engineering Capcom’s Crypto CPU

There are a few old Capcom arcade titles – Pang, Cadillacs and Dinosaurs, and Block Block – that are unlike anything else ever seen in the world of coin-ops. They’re old, yes, but what makes these titles exceptional is the CPU they run on. The brains in the hardware of these games is a Kabuki, a Z80 CPU that had a few extra security features. why would Capcom produce such a thing? To combat bootleggers that would copy and reproduce arcade games without royalties going to the original publisher. It’s an interesting part of arcade history, but also a problem for curators: this security has killed a number of arcade machines, leading [Eduardo] to reverse engineering and document the Kabuki in full detail.

While the normal Z80 CPU had a pin specifically dedicated to refreshing DRAM, the Kabuki repurposed this pin for the security functions on the chip. With this pin low, the Kabuki was a standard Z80. When the pin was pulled high, it served as a power supply input for the security features. The security – just a few bits saved in memory – was battery backed, and once this battery was disconnected, the chip would fail, killing the game.

Plugging Kabuki into an old Amstrad CPC 6128 without the security pin pulled high allowed [Eduardo] to test all the Z80 instructions, and with that no surprises were found; the Kabuki is fully compatible with every other Z80 on the planet. Determining how Kabuki works with that special security pin pulled high is a more difficult task, but the Mame team has it nailed down.

The security system inside Kabuki works through a series of bitswaps, circular shifts, XORs, each translation different if the byte is an opcode or data. The process of encoding and decoding the security in Kabuki is well understood, but [Eduardo] had a few unanswered questions. What happens after Kabuki lost power and the memory contents – especially the bitswap, address, and XOR keys – vanished? How was the Kabuki programmed in the factory? Is it possible to reprogram these security keys, allowing one Kabuki to play games it wasn’t manufactured for?

[Eduardo] figured being able to encrypt new, valid code was the first step to running code encrypted with different keys. To test this theory, he wrote a simple ‘Hello World’ for the Capcom hardware that worked perfectly under Mame. While the demo worked perfectly under Mame, it didn’t work when burned onto a EPROM and put into real Capcom hardware.

That’s where this story ends, at least for the time being. The new, encrypted code is valid, Mame runs the encrypted code, but until [Eduardo] or someone else can figure out any additional configuration settings inside the Kabuki, this project is dead in the track. [Eduardo] will be back some time next week tearing the Kabuki apart again, trying to unravel the mysteries of what makes this processor work.