32C3: Towards Trustworthy X86 Laptops

December 28, 2015 by Brian Benchoff 38 Comments

Security assumes there is something we can trust; a computer encrypting something is assumed to be trustworthy, and the computer doing the decrypting is assumed to be trustworthy. This is the only logical mindset for anyone concerned about security – you don’t have to worry about all the routers handling your data on the Internet, eavesdroppers, or really anything else. Security breaks down when you can’t trust the computer doing the encryption. Such is the case today. We can’t trust our computers.

In a talk at this year’s Chaos Computer Congress, [Joanna Rutkowska] covered the last few decades of security on computers – Tor, OpenVPN, SSH, and the like. These are, by definition, meaningless if you cannot trust the operating system. Over the last few years, [Joanna] has been working on a solution to this in the Qubes OS pro ject, but everything is built on silicon, and if you can’t trust the hardware, you can’t trust anything.

And so we come to an oft-forgotten aspect of computer security: the BIOS, UEFI, Intel’s Management Engine, VT-d, Boot Guard, and the mess of overly complex firmware found in a modern x86 system. This is what starts the chain of trust for the entire computer, and if a computer’s firmware is compromised it is safe to assume the entire computer is compromised. Firmware is also devilishly hard to secure: attacks against write protecting a tiny Flash chip have been demonstrated. A Trusted Platform Module could compare the contents of a firmware, and unlock it if it is found to be secure. This has also been shown to be vulnerable to attack. Another method of securing a computer’s firmware is the Core Root of Trust for Measurement, which compares firmware to an immutable ROM-like memory. The specification for the CRTM doesn’t say where this memory is, though, and until recently it has been implemented in a tiny Flash chip soldered to the motherboard. We’re right back to where we started, then, with an attacker simply changing out the CRTM chip along with the chip containing the firmware.

But Intel has an answer to everything, and to the house of cards for firmware security, Intel introduced their Management Engine. This is a small microcontroller running on every Intel CPU all the time that has access to RAM, WiFi, and everything else in a computer. It is security through obscurity, though. Although the ME can elevate privileges of components in the computer, nobody knows how it works. No one has the source code for the operating system running on the Intel ME, and the ME is an ideal target for a rootkit.

Is there hope for a truly secure laptop? According to [Joanna], there is hope in simply not trusting the BIOS and other firmware. Trust therefore comes from a ‘trusted stick’ – a small memory stick that contains a Flash chip that verifies the firmware of a computer independently of the hardware in a computer.

This, with open source firmwares like coreboot are the beginnings of a computer that can be trusted. While the technology for a device like this could exist, it will be a while until something like this will be found in the wild. There’s still a lot of work to do, but at least one thing is certain: secure hardware doesn’t exist, but it can be built. Whether secure hardware comes to pass is another thing entirely.

You can watch [Joanna]’s talk on the 32C3 streaming site.

Capture The Flag With Lightsabers

December 15, 2015 by Bryan Cockfield 2 Comments

There’s a great game of capture-the-flag that takes place every year at HITCON. This isn’t your childhood neighborhood’s capture-the-flag in the woods with real flags, though. In this game the flags are on secured servers and it’s the other team’s mission to break into the servers in whatever way they can to capture the flag. This year, though, the creators of the game devised a new scoreboard for keeping track of the game: a lightsaber.

In this particular game, each team has a server that they have to defend. At the same time, each team attempts to gain access to the other’s server. This project uses a lightsaber stand that turns the lightsabers into scoreboards for the competition at the 2015 Hacks In Taiwan Conference. It uses a cheap OpenWRT Linux Wi-Fi/Ethernet development board, LinkIt Smart 7688 which communicates with a server. Whenever a point is scored, the lightsaber illuminates and a sound effect is played. The lightsabers themselves are sourced from a Taiwanese lightsabersmith and are impressive pieces of technology on their own. As a bonus the teams will get to take them home with them.

While we doubt that this is more forced product integration advertisement from Disney, it certainly fits in with the theme of the game. Capture-the-flag contests like this are great ways to learn about cyber security and how to defend your own equipment from real-world attacks. There are other games going on all around the world if you’re looking to get in on the action.

Continue reading “Capture The Flag With Lightsabers” →

Encryption For Arduino With Spritz

December 12, 2015 by Elliot Williams 4 Comments

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.

Biometric Bracelet Electrifies You To Unlock Your Tablet

December 8, 2015 by Elliot Williams 3 Comments

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” →

Hacker Uncovers Security Holes At CSL Dualcom

November 26, 2015 by Will Sweatman 14 Comments

CSL Dualcom, a popular maker of security systems in England, is disputing claims from [Cybergibbons] that their CS2300-R model is riddled with holes. The particular device in question is a communications link that sits in between an alarm system and their monitoring facility. Its job is to allow the two systems to talk to each other via internet, POT lines or cell towers. Needless to say, it has some heavy security features built in to prevent tampering. It appears, however, that the security is not very secure. [Cybergibbons] methodically poked and prodded the bits and bytes of the CS2300-R until it gave up its secrets. It turns out that the encryption it uses is just a few baby steps beyond a basic Caesar Cipher.

A Caesar Cipher just shifts data by a numeric value. The value is the cipher key. For example, the code IBDLBEBZ is encrypted with a Caesar Cipher. It doesn’t take very much to see that a shift of “1” would reveal HACKADAY. This…is not security, and is equivalent to a TSA lock, if that. The CS2300-R takes the Caesar Cipher and modifies it so that the cipher key changes as you move down the data string. [Cybergibbons] was able to figure out how the key changed, which revealed, as he put it – ‘the keys to the kingdom’.

There’s a lot more to the story. Be sure to read his detailed report (pdf) and let us know what you think in the comments below.

We mentioned that CSL Dualcom is disputing the findings. Their response can be read here.

Defeating Chip And PIN With Bits Of Wire

November 25, 2015 by Brian Benchoff 120 Comments

One of many ways that Americans are ridiculed by the rest of the world is that they don’t have chip and PIN on their credit cards yet; US credit card companies have been slow to bring this technology to millions of POS terminals across the country. Making the transition isn’t easy because until the transition is complete, the machines have to accept both magnetic stripes and chip and PIN.

This device can disable chip and PIN, wirelessly, by forcing the downgrade to magstripe. [Samy Kamkar] created the MagSpoof to explore the binary patterns on the magnetic stripe of his AmEx card, and in the process also created a device that works with drivers licenses, hotel room keys, and parking meters.

The electronics for the MagSpoof are incredibly simple. Of course a small microcontroller is necessary for this build, and for the MagSpoof, [Samy] used the ATtiny85 for the ‘larger’ version (still less than an inch square). A smaller, credit card-sized version used an ATtiny10. The rest of the schematic is just an H-bridge and a coil of magnet wire – easy enough for anyone with a soldering iron to put together on some perfboard.
By pulsing the H-bridge and energizing the coil of wire, the MagSpoof emulates the swipe of a credit card – it’s all just magnetic fields reversing direction in a very particular pattern. Since the magnetic pattern on any credit card can be easily read, and [Samy] demonstrates that this is possible with some rust and the naked eye anyway, it’s a simple matter to clone a card by building some electronics.

[Samy] didn’t stop there, though. By turning off the bits that state that the card has a chip onboard, his device can bypass the chip and PIN protection. If you’re very careful with a magnetized needle, you could disable the chip and PIN protection on any credit card. [Samy]’s device doesn’t need that degree of dexterity – he can just flip a bit in the firmware for the MagSpoof. It’s all brilliant work, and although the code for the chip and PIN defeat isn’t included in the repo, the documents that show how that can be done exist.

[Samy]’s implementation is very neat, but it stands on the shoulders of giants. In particular, we’ve covered similar devices before (here and here, for instance) and everything that you’ll need for this hack except for the chip-and-PIN-downgrade attack are covered in [Count Zero]’s classic 1992 “A Day in the Life of a Flux Reversal“.

Thanks [toru] for sending this one in. [Samy]’s video is available below.

Continue reading “Defeating Chip And PIN With Bits Of Wire” →

Turning A Teensy Into A Better U2F Key

November 14, 2015 by Brian Benchoff 11 Comments

A few days ago, we saw a project that used a Teensy to build a Universal 2nd Factor (U2F) key. While this project was just an experiment in how to implement U2F on any ‘ol microcontroller, and the creator admitted it wasn’t very secure, the comments for that post said otherwise: “making your own thing is the ONLY way to be secure,” read the comments.

In a stunning turn of events, writing comments on a blog post doesn’t mean you know what you’re talking about. It turns out, to perform a security analysis of a system, you need to look at the code. Shocking, yes, but [makomk] took a good, hard look at the code and found it was horribly broken.

The critical error of the Teensy U2F key crypto is simply how U2F is performed. During authentication, the device sends the U2F key handle to whatever service is trying to authenticating it. Because the key in the Teensy implementation is only ‘encrypted’ with XOR, it only takes 256 signing requests to recover the private key.

The original experimentation with using the Teensy as a U2F key was an educational endeavor, and it was never meant to be used by anyone. The attack on this small lesson in security is interesting, though, and [makomk] wrote a proof of concept that demonstrates his attack. This could be used to perform attacks from a remote server, but hopefully that won’t happen, because the original code should never be used in the wild.