[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.
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.
[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.
[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.
The concept of cryptography touches our lives many times per day, and that’s probably a conservative estimate. We have a pretty good idea of how it works, having dealt with public-key cryptography for things like remote git repositories or ssh tunneling without a password. But we still enjoyed reading [Tiberiu Barbu’s] primer on the subject which he calls From 0 to Cryptography.
He begins the discussion with a definition of terms but quickly moves to the topic of key distribution. If you’re using a key to decipher data, how can you make sure that key only makes it to the person whom you want reading the data? One way is to use a Diffie-Hellman key exchange. The diagram above illustrates the trade, which uses an agreed upon value (color in this example) as a common starting point, then goes from there. After working our way through the key exchange scenario [Tiberiu] then runs the gammut of other options, include Public-Key, RSA, Hash, Digital Certificate, and a few others. It’s not a long post considering how many topics it covers. If you don’t have time today, make sure to save it for the weekend.
The biggest benefit to using the BeagleBone is it’s 700 MHz ARM processor. If you’re just messing around with basic I/O that power is going unused, but [Nuno Alves] is taking advantage of its power. He built a PDF password cracker based on the $85 development board.
We recently saw how easy it is to perform basic I/O using the BeagleBone. Those techniques are in play here, used to drive a character LCD and sample a button input from the breadboard circuit. [Nuno] even published separate posts for each of these peripheral features.
The password protected PDF file is passed to the device on a thumb drive. Since the BeagleBone is running embedded Linux you don’t need to mess around with figuring out how to read from the device. A click of the button starts the process. Currently the code just uses a brute force attack which can test more than 6000 four-character passwords per second. This is quite slow for any password more than four or five characters long, but [Nuno] does mention the possibility of running several ARM processors in parallel, or using a dictionary (or rainbow table) to speed things up. Either way it’s an interesting project to try on the hardware. You can see his video demo of the device after the break.
Continue reading “Brute force a password protected PDF using the BeagleBone”
The Electronic Frontier Foundation, long-time defenders of the common man’s rights in the electronic realm, has published a guide to keeping your digital devices private when entering the United States. It seems the defenders of freedom and liberty (ICE, DHS, TSA, and CBP) are able to take a few freedoms with your liberty at a border crossing by seizing your devices and copies of the data they store for up to five days. This requires no suspicion of wrongdoing, and copies of this data may be shared with other agencies thereby negating the five day limit.
Do you have a reason to protect your digital property? This is discussed in the paper. It may be confidential information, by way of a business contract or professional relationship (Doctors, Lawyers, Journalists, etc.). Or you may just want to keep your privacy on principle. No matter what your stance, the EFF has covered all the bases in this intriguing read. We think the best advice they give is to make an encrypted backup of your data on the internet, blank your computer before the border crossing, and restore it when you get to your destination. If you don’t have the data with you, it can’t be compromised. It that’s not an option, they have plenty of guidelines on cryptographic techniques.
Continue reading “EFF on securing digital information when crossing the border”