encryption

84 Articles

EFF On Securing Digital Information When Crossing The Border

December 21, 2011 by 47 Comments

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

Reverse Engineering The Nike+ Hardware

October 14, 2011 by 31 Comments

The Nike+ hardware is obviously an interesting device.  We haven’t heard a whole lot about hacking one until now, but [Dimitry] has decided to change that. Many would assume that the data transmitted off of these sensors is quite simple, however there’s a bit more than meets the eye. Amongst other challenges, all the data packets coming out of the transceiver are encrypted. [Dimitry] claims to have decoded this data stream and made use of it.

This hack also outlines how one can use this without the stock iPod receiver using a 2.4 GHz chip from Sparkfun. A lot of work has been done to figure out how these packets are decoded and the process one goes through to do this is well outlined in this post. This could serve as a good example for those wanting to figure out similar devices.

One thing [Dimitry] hasn’t done yet is release the source code for this hack. He cites some ethical issues that might not seem obvious on first glance, including the ability to follow someone in a crowd or simply jamming their data. He does add though that if you have a good reason for wanting it, to simply email him. We’re looking forward to what [Dimitry] comes up with in the future using this setup!

Intel: High-bandwidth Digital Content Protection Cracked

September 18, 2010 by 54 Comments

Intel says that HDCP has been cracked, but they also say that it’s unlikely this information will be used to unlock the copying of anything. Their reasoning for the second statement is that for someone to make this work they would need to produce a computer chip, not something that is worth the effort.

We question that logic. Not so much for Blu-Ray, which is the commonly associated media format that uses HDCP, but for HD digital cable programming. There are folks out there who would like to have the option of recording their HD television shows without renting a DVR from the cable company. CableCard tuners have been mostly absent from the market, making this type of recording difficult or impossible. Now that there’s a proven way to get the encryption key for HDCP how hard would it really be to create a man-in-the-middle device that uses that key to authenticate, decrypt, and funnel the audio and video to another encoder card? We know next-to-nothing about the protocol but why couldn’t any powerful processor, like an ARM, or even an FPGA (both rather inexpensive and readily available) be programmed for this task?

Leave a comment to let us know what you think about HDCP, and what the availability of the master-key really means.

[Thanks Dave]

TV Hack Bypasses HDCP

October 1, 2009 by 64 Comments

hdmi

Reader [GRitchie] wrote in with an interesting find in his new TV set: with just some minor soldering it was possible to tap into an unencrypted hi-def video stream.

HDCP (High-bandwidth Digital Content Protection), used by Blu-Ray players and cable or satellite receivers, normally ensures a DRM-protected link between the device and a compatible display. Any properly-licensed device that forwards HDCP content (such as an HDMI switch box) is expected to provide encrypted output; those that don’t may get blacklisted by the system and become expensive paperweights. It’s something of an annoyance for users who feel this oversteps fair use applications such as time-shifting.

[GRitchie] found that his new TV with “InstaPort” Fast HDMI Switching didn’t perform this re-encryption step between the set’s internal switcher and the next stage in decoding. Soldering just eight wires directly from the switching chip’s output to an HDMI cable provided an unencrypted output that could then be received by a PC for later replay.

What’s not clear at this point is whether the capability is peculiar to just this one make and model, or applies to anything with the new Fast HDMI Switching. If the latter, it will be interesting to see how this plays out…nearly all of the major HDTV manufacturers are evaluating InstaPort for new sets, which would make any attempt at HDCP blacklisting awkward, to say the least.

TEMPEST: A Signal Problem

January 25, 2009 by 12 Comments

TEMPEST is the covername used by the NSA and other agencies to talk about emissions from computing machinery that can divulge what the equipment is processing. We’ve covered a few projects in the past that specifically intercept EM radiation. TEMPEST for Eliza can transmit via AM using a CRT monitor, and just last Fall a group showed how to monitor USB keyboards remotely. Through the Freedom of Information Act, an interesting article from 1972 has been released. TEMPEST: A Signal Problem (PDF link dead, try Internet Archive version) covers the early history of how this phenomenon was discovered. Uncovered by Bell Labs in WWII, it affected a piece of encryption gear they were supplying to the military. The plaintext could be read over that air and also by monitoring spikes on the powerlines. Their new, heavily shielded and line filtered version of the device was rejected by the military who simply told commanders to monitor a 100 feet around their post to prevent eavesdropping. It’s an interesting read and also covers acoustic monitoring. This is just the US history of TEMPEST though, but from the anecdotes it sounds like their enemies were not just keeping pace but were also better informed.

[via Schneier]

Use The CPU Cache To Prevent Cold Boot? No.

January 18, 2009 by 21 Comments

coldboot

Frozen Cache is a blog dedicated to a novel way to prevent cold boot attacks. Last year the cold boot team demonstrated that they could extract encryption keys from a machine’s RAM by placing it in another system (or the same machine by doing a quick reboot). Frozen Cache aims to prevent this by storing the encryption key in the CPU’s cache. It copies the key out of RAM into the CPU’s registers and then zeroes it in RAM. It then freezes the cache and attempts to write the key back to RAM. The key is pushed into the cache, but isn’t written back to RAM.

The first major issue with this is the performance hit. You end up kneecapping the processor when you freeze the cache and the author suggests that you’d only do this when the screen is locked. We asked cold boot team member [Jacob Appelbaum] what he thought of the approach. He pointed out that the current cold boot attack reconstructs the key from the full keyschedule, which according to the Frozen Cache blog, still remains in RAM. They aren’t grabbing the specific key bits, but recreating it from all this redundant information in memory. At best, Frozen Cache is attempting to build a ‘ghetto crypto co-processor’.

We stand by our initial response to the cold boot attacks: It’s going to take a fundamental redesign of RAM before this is solved.

[via Slashdot]