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.

Quantum Computing Kills Encryption

September 29, 2015 by Elliot Williams 79 Comments

Imagine a world where the most widely-used cryptographic methods turn out to be broken: quantum computers allow encrypted Internet data transactions to become readable by anyone who happened to be listening. No more HTTPS, no more PGP. It sounds a little bit sci-fi, but that’s exactly the scenario that cryptographers interested in post-quantum crypto are working to save us from. And although the (potential) threat of quantum computing to cryptography is already well-known, this summer has seen a flurry of activity in the field, so we felt it was time for a recap.

How Bad Is It?

If you take the development of serious quantum computing power as a given, all of the encryption methods based on factoring primes or doing modular exponentials, most notably RSA, elliptic curve cryptography, and Diffie-Hellman are all in trouble. Specifically, Shor’s algorithm, when applied on a quantum computer, will render the previously difficult math problems that underlie these methods trivially easy almost irrespective of chosen key length. That covers most currently used public-key crypto and the key exchange that’s used in negotiating an SSL connection. That is (or will be) bad news as those are what’s used for nearly every important encrypted transaction that touches your daily life.

Continue reading “Quantum Computing Kills Encryption” →

Hackaday 10th Anniversary: [1o57] And The Art Of Encryption

October 6, 2014 by Brian Benchoff 35 Comments

[Ryan] a.k.a. [1o57] comes from an age before anyone could ask a question, pull out their smartphone, and instantly receive an answer from the great Google mind. He thinks there’s something we have lost with our new portable cybernetic brains – the opportunity to ask a question, think about it, review what we already know, and reason out a solution. There’s a lot to be said about solving a problem all by yourself, and there’s nothing to compare to the ‘ah-ha’ moment that comes with it.

[1o57] started his Mystery Challenges at DEFCON purely by accident; he had won the TCP/IP embedded device competition one year, and the next year was looking to claim his title again. The head of the TCP/IP embedded competition had resigned from his role, and through a few emails, [1o57] took on the role himself. There was a miscommunication, though, and [1o57] was scheduled to run the TCP/IP drinking competition. This eventually morphed into a not-totally-official ‘Mystery Challenge’ that caught fire in email threads and IRC channels. Everyone wanted to beat the mystery challenge, and it was up to [1o57] to pull something out of his bag of tricks.

The first Mystery Challenge was a mechanical device with three locks ready to be picked (one was already unlocked), magnets to grab ferrous picks, and only slightly bomb-like in appearance. The next few years featured similar devices with more locks, better puzzles, and were heavy enough to make a few security officials believe [1o57] was going to blow up the Hoover dam.

With a few years of practice, [1o57] is turning crypto puzzles into an art. His DEFCON 22 badge had different lanyards that needed to be arranged to spell out a code. To solve the puzzle, you’ll need to talk to other people, a great way to meet one of [1o57]’s goals of getting all the natural introverts working together.

Oh. This talk has its own crypto challenge, something [1o57] just can’t get out of his blood:

So far nobody has solved the @hackaday 10 year anniversary in-talk-mini-crypto-puzzle-of-doom…("it's only a model")

— LosT/李智上 (@1o57) October 5, 2014

We talked for a little bit, and 0x06 0x0a1 MFY YWXDWE MEOYOIB ASAE WBXLU BC S BLOQ ZTAO KUBDR HG SK YTTZSLBIMHB

Reverse Engineering A Bank’s Security Token

February 7, 2014 by Brian Benchoff 20 Comments

app

[Thiago]’s bank uses a few methods besides passwords and PINs to verify accounts online and at ATMs. One of these is a ‘security card’ with 70 single use codes, while another is an Android app that generates a security token. [Thiago] changes phones and ROMs often enough that activating this app became a chore. This left only one thing to do: reverse engineer his bank’s security token and build a hardware device to replicate the app’s functionality.

After downloading the bank’s app off his phone and turning the .APK into a .JAR, [Thiago] needed to generate an authentication code for himself. He found a method that generates a timestamp which is the number of 36-second intervals since April 1st, 2007. The 36-second interval is how long each token lasts, and the 2007 date means this part of the code was probably developed in late 2007 or 2008. Reverse engineering this code allowed [Thiago] to glean the token generation process: it required a key, and the current timestamp.

[Thiago] found another class that reads his phone’s android_id, and derives the key from that. With the key and timestamp in hand, he figured out the generateToken method and found it was remarkably similar to Google Authenticator’s implementation; the only difference was the timestamp epoch and the period each token lasts.

With the generation of the security token complete, [Thiago] set out to put this code into a hardware device. He used a Stellaris Launchpad with the Criptosuite and RTClib libraries. The hardware doesn’t include a real-time clock, meaning the date and time needs to be reset at each startup. Still, with a few additions, [Thiago] can have a portable device that generates security tokens for his bank account. Great work, and great example of how seriously his bank takes account security.

Google Security Certificates Forged

December 9, 2013 by Eric Evenchick 23 Comments

Recently, Google discovered that a certificate authority (CA) issued forged certificates for Google domains. This compromises the trust provided by Transport Layer Security (TLS) and Secure HTTP (HTTPS), allowing the holder of the forged certificates to perform a man-in-the-middle attack.

To validate that the website you’re visiting is actually who they claim to be, your browser ensures that the certificate presented by the server you’re accessing was signed by a trusted CA. When someone requests a certificate from a CA, they should verify the identity of the person making the request. Your browser, and operating system, have a set of ultimately trusted CAs (called root CAs). If the certificate was issued by one of them, or a intermediate CA that they trust, you will trust the connection. This whole structure of trust is called a Chain of Trust.

With a forged certificate, you can convince a client that your server is actually http://www.google.com. You can use this to sit between a client’s connection and the actual Google server, eavesdropping their session.

In this case, an intermediate CA did just that. This is scary, because it undermines the security that we all rely on daily for all secure transactions on the internet. Certificate pinning is one tool that can be used to resist this type of attack. It works by associating a host with a specific certificate. If it changes, the connection will not be trusted.

The centralized nature of TLS doesn’t work if you can’t trust the authorities. Unfortunately, we can’t.

Cracking A SAM7XC Cryptographic Coprocessor

February 11, 2013 by Mike Szczys 13 Comments

attacking-RFID-crypto-coprocessor

[Adam Laurie] spent time tearing into the security of the SAM7XC chip produced by Atmel. Even if he hadn’t found some glaring security holes just reading about his methodology is worth it.

The chip is used in a secure RFID system. The chip is added to the mix to do the heavy lifting required when using encryption. [Adam] grabbed a couple of open source libraries to put it to the test. The firmware is locked down pretty tight, but his explorations into the content of the RAM yield a treasure trove of bits. After investigating the sample code for the chip he’s shocked to learn that it uses RAM to store the keys at one point. The rest of his journey has him dumping the data and sifting through it until he gets to the “Master Diversification Key”. That’s the big daddy which will let him decrypt any of the tags used.

He reported his findings to Atmel in September of 2011. Their response is that they have no way of protecting RAM from exploit. [Adam] asserts that the problem is that the sample software wasn’t designed with the vulnerability of RAM in mind. The keys should never be stored there specifically because it is vulnerable to being dumped from a running system.

Building A Hardware Security Module

December 31, 2012 by Brian Benchoff 32 Comments

[Stefan] was nervous about putting the secret key for his Amazon Web Services account in his config file. In the security world, storing passwords in plain text is considered a very bad thing. but luckily there are ways around it. [Stefan]’s solution was to make a hardware security module out of the newest ARM-powered Arduino Due.

The build puts the secret key for [Stefan]’s AWS account right in the firmware of the Arduino Due (with the security bit on the Arduino flipped, of course). A Python web service then receives sign requests and talks to the Due over a serial port. The Due then signs the request and sends it off to another bit of Python code that handles the AWS API.

Hardware security modules are frequently used by three-letter government agencies to manage cryptography keys and ensure their data are encrypted properly. Instead of a hardware module costing tens of thousands of dollars, [Stefan]’s only cost the price of an Arduino Due; not too shabby for a hardware security module that can sign more than 2000 requests per second.