Cell Phone GSM Ciphers Dropping Like Flies

With news that the KASUMI cipher, used to encrypt 3G GSM communications, has been broken, I'm beginning to wonder if anything transmitted wirelessly can be secured appropriately.

KASUMI is also known as A5/3, and word of its defeat comes just weeks after we learned that another cipher, A5/1, was also broken. Once again, related key attacks have proven successful.

From Emerging Chaos:

KASUMI is a modified version of the MISTY cipher. The KASUMI designers made MISTY faster and more hardware friendly by changing the key schedule and modifying some internal parameters. However, they also made it vulnerable to related key attacks.

Of all the weaknesses that a cipher can have, related key attacks are the ones to worry about least. Operationally, crypto engineers know that they should never reuse keys and when in doubt just pull another one off of the random number generator. Consequently, this doesn't mean that the guys at Weizmann Institute of Science are listening to 3G calls.

Nonetheless, related key attacks are bad to have because implementers do screw up, and related key attacks indicate that the cipher designers didn't have as tight a handle on things as they thought they did. It is no cause for panic, but it is no cause for either warmness or fuzziness (particularly since the DKS team point out that the KASUMI designers wrote that they'd taken care of related-key issues when they simplified MISTY into KASUMI).

Bruce Schneier calls this "lazy cryptography", and as more communication is moved to cellular networks, the need for highly-secure encryption solutions will grow. And the attackers will go where the traffic flows.

Hopefully, back-to-back cipher breaks will be a wakeup call to the digital security community, and we'll see some serious efforts to upgrade the environment.

RSA Encryption 768-bit Keys Broken

Bad news if you're not using the 1024-bit keys for RSA cryptography - the 768-bit keys have been broken. And it's only a matter of time until 1024 bites the dust.

From The Register:

An international team of mathematicians, computer scientists and cryptographers broke the key though NFS, or number field sieve, which allowed them to deduce two prime numbers that when multiplied together generated a number with 768 bits. The discovery, which took about two-and-a-half years and hundreds of general-purpose computers, means RSA keys can no longer be counted on to encrypt or authenticate sensitive communications.

With the quantum increases in computer processing power, what took 2 1/2 years today might take a year in 2011, and 4 months in 2013, so it's only a matter of time before the RSA 1024-bit is also broken. While the article posits a decade, it's more likely to happen sooner.

The real issue is that there are quite a few devices using shorter key lengths than 1024 bits because of their limited processing ability. Keys of 300 characters or less can be broken within hours on a standard personal computer, and 512 bits is easily defeated in weeks on typical hardware configurations.

Current best practice is a key of 2048 bits, and using today's technology, breaking a 4096-bit key seems unlikely. But that only provides additional time to develop more secure algorithms, as processing advances makes this a math problem that will eventually be solved.

It will be interesting to see how vendors react, especially those who market products that rely on the shorter key lengths. RSA encryption is already slower than some other symmetric algorithms, and if the devices already choke on longer keys, moving to 2048 or 4096 will be impractical.

The Hotel Maid Can Defeat Your Full Disk Encryption

Corporate America is beginning to finally get their act together when it comes to full-disk encryption of laptop hard drives, nearly a decade after an avalanche of thefts and data breaches made CIOs and CTOs take notice.

So are you safe leaving your laptop or notebook in your hotel room when you travel? Even if you chain it to the desk, the answer is, "Not so much."

Over at InvisibleThings, founder Joanna Rutkowska details how she and Alex Tereshkin were able to successfully launch an Evil Maid attack using a bootable USB stick against TrueCrypt system disk encryption. The results were frightening, and not altogether surprising.

Here's the process they followed, reduced for clarity to a couple of small, easy steps: Somebody leaves a laptop unsupervised somewhere, like a hotel room or coffee shop. In a matter of minutes, an attacker posing as a maid, room service, or maintenance can enter, insert the USB drive, and boot the laptop using an Evil Maid tool, compromising the TrueCrypt loader while loading what's essentially a keylogger before they take their USB drive and depart.

When the user returns and boots the laptop again, TrueCrypt prompts for the password as normal, and the unsuspecting user enters the code or phrase. The Evil Maid attack has now captured this credential. The next time the user leaves their laptop unsupervised, the attacker returns, again boots the laptop with the USB drive, and now has possession of the TrueCrypt login credentials.

No more encryption. No more protection. Say goodbye to your data.

Now, the TrueCrypt folks mount the defense that if you can't ensure the security of the hardware, then that's your problem. If you can't know for certain that your device has been compromised, you shouldn't use it for sensitive data, they posit.

While technically true, it's something that encryption vendors don't typically highlight in their product literature. As Rutkowska points out when speaking to TrueCrypt reps, if she's locking her laptop in a safe or strongbox when it's not in use, why does she need full disk encryption?

It's easy for consumers and corporations to lapse into complacency once they implement full disk encryption. Physical security becomes less of a priority because of the mistaken belief that they only existing threat is device theft, and since theoretically the entire hard disk is protected by strong encryption, no data loss can occur.

As we've seen in the above scenario, device theft is just one attack vector. I'd be more worried about the attacker booting into the OS and loading a rootkit or other malware that would avoid detection and allow for remote data retrieval or monitoring. Why steal the device when you can access the contents whenever you'd like?

Further, what if the installed malware allows penetration of your network, perhaps spreading similar malicious code to other workstations, servers, and network devices? A lack of physical security focus on a single laptop could conceivably compromise your enterprise.

There's no easy answer here. You could implement two-factor authentication which would render capturing keystrokes ineffective, since a second component would be needed in addition to the passphrase or password. Another solution would be to utilize a secure boot loader process, but none of the current vendor solutions are configured to implement any sort of "root of trust" technologies.

The best solution is to continue a defense-in-depth strategy with hardware security as a key component. Don't leave your laptop unsecured in areas without controlled access that you trust - including hotel rooms, checked baggage, and your local Starbucks. Assuming you're not concerned with an NSA-level attack, the combination of full disk encryption and robust physical security should protect you against most threats, although nothing prevents 100% of attacks.

Rutkowska's article is an excellent expose' of this particular weakness in the security chain, and she even walks us through how to download and use Evil Maid.

Remember - it's for lab use only. We've sworn to use our powers only for good.












Image via Wikimedia Commons

Stick Figure Guide to AES Encryption

Well, this makes perfect sense now.

If you're really interested in AES encryption, be prepared to spend a few minutes scrolling through this. It's sort of lengthy. But good.

iPhone Encryption Easily Defeated

One of the digs against the use of an iPhone in a corporate environment is the lack of enterprise-level security on the device. With sensitive business and personal information contained within email and documents stored on the phone, it's imperative that there are effective, robust controls in place to keep the data from being breached.

Apple has been touting the encryption solution that's part of the new 3GS model as their answer to those who doubted an iPhone in the enterprise was ready for prime time. It's reported that Apple uses the 448-bit Blowfish encryption algorithm, which provides a measure of cryptographic protection. But does it really keep the bad guys out of your data?

Sadly, it doesn't appear to be very successful. Wired has a report that indicates data can be siphoned off of an encrypted iPhone in minutes using readily-available software, and a complete disk image can be created in less than an hour.

There seems to be a minor issue with the iPhone in that once data starts being extracted, the phone begins decrypting the data on its own. Wow.

This is particularly troubling in light of some recent legislation in Massachusetts and Nevada that requires personal information of state residents be encrypted on any device that is not within the confines of the corporate network. This includes Blackberry devices, smart phones, removable USB drives, and so on. Since it's difficult to discern the legal residence of the customer's data as it gets mixed and mashed with everyone else's data, corporations generally choose to protect all personal information in the same manner, regardless of the domicile.

As a security professional, I would never recommend using the iPhone on a corporate level until Apple matures their security configuration and control environment. It's up to each business to evaluate the level of risk they are willing to accept, and for some, use of the iPhone will fall within acceptable risk parameters. Sooner or later, however, a breach will occur - someone's information will be stolen or use inappropriately - and there will be statutory penalties in addition to the inevitable civil suit.

Apple has an uphill trek to achieve the same security posture as RIM with their series of Blackberry devices. Don't expect Cupertino to reach the peak anytime soon.

Rainbow Tables for Cracking WPA

If you're looking to play around for research purposes only with cracking some wireless access points that are using WPA for security purposes, you may want to check out the new rainbow tables posted at Offensive Security.

With 49 million records in the WPA-optimized password dictionary file, lots of low-hanging WPA fruit will be cracked in no time.

Cracking keys for fun and profit - it's a wonderful thing.

Credit Card PINs No Longer Secure

As technology advances make it easier for customers to access their accounts and perform money movement transactions with credit and debit cards, the bad guys are using technology to steal the Personal Identification Numbers (PINs) that are issued to customers to help protect their accounts.

Feeling less secure yet?

It doesn't even matter anymore if the PINs are encrypted. Conventional wisdom held that once a customer keyed their PIN into an ATM or at a point-of-sale terminal, the transaction was secure as it went through the processing cycle, due to the encryption algorithms. The transaction would be received by your financial institution, decrypted, and processed. Viola!

PCI standards supported by the banks and credit card industry (which are ineffective as I've written about here and here) were supposed to prevent this kind of attack. Forcing encryption of the transactions and PINs was seen as a panacea. But as Bruce Schneier posited in his book Beyond Fear, when you think about implementing security controls into a system, you also need to contemplate what new weaknesses or gaps are created at the same time.

In this case of these encrypted transactions, the gap introduced is pretty clear - the hardware security module (HSM), a security appliance that resides on bank networks and switches to help encrypt and decrypt traffic as it passes through transaction processing.

Problem is, there are multiple HSMs among the various banking networks that the transaction passes through on the way from its origin to the customer's bank. Each of the HSMs might be different, and are managed by different firms or even contractors in some cases. The traffic needs to be decrypted as it passes through the HSM, then re-encrypted as it's sent on to the next HSM.

It's at these switching points that the crooks often trick the HSM into revealing the encryption details, PIN blocks, or keys, either because of configuration problems, vulnerabilities, or weaknesses in the HSM or its operating software. Once a PIN block is compromised, it's off to the races.

The HSM is but one attack vector - other methods of compromising transactions are old-school but equally effective, and there's always phishing attacks and compromising servers that contain the information, like the Hannaford breach. But the utter collapse of PIN numbers as an effective control is causing the industry to scramble as losses soar into the hundreds of millions of dollars.

It's time to look at integrated security solutions and secure networks for transaction processing, and a deep assessment is needed of all controls associated with financial dealings. With the large volumes of data gushing through the system, even a small leak can have catastrophic results.

PIN Crackers Nab Holy Grail of Bank Card Security

Stupid Security

I've been preaching for a long time about the benefits of encrypting removable USB flash drives, since they are easily lost and it's a breeze to suck your data off of them.

So if you're encrypting your USB keys, you're smart. Very smart. If you attach your encryption key to the device, you're dumb. Very dumb.

Such was the case with prisoner health information from Preston Prison in Lancashire, UK. More than 6300 prisoner's data was on the USB stick.

Workers from NHS Central Lancashire involved in the incident have been suspended while the investigation takes place.

It is believed a member of NHS Central Lancashire staff had uploaded the information using the memory stick then returned to the administration office and lost the device somewhere on route.

There's that data-in-transit and human error thing again, as I pointed out in my posting yesterday on the rise of data breaches. How many of these incidents need to occur before people dummy up and start doing the right thing?

Round 1 Candidates for SHA-3

NIST announced the round 1 candidates for the SHA-3 competition, and crypto experts and math geeks everywhere had a SHA-gasm.

As background, National Institute of Standards & Technology decided to open a public competition for the development of SHA-3, the latest incarnation of the Secure Hash Algorithm.

NIST decided that a new version was needed due to the increase in attacks against SHA-1, and the fact that both SHA-1 and SHA-2 share a common framework. If SHA-1 goes down, SHA-2 won't be far behind.

The competition is supposed to run through 2012, and first round entrants needed to have their submissions in by October 31, 2008. Sixty-four submissions were received, and 51 of these were accepted. A couple of those accepted have already been broken, so it's looking like it won't take nearly as long to trim the field as originally expected.

SHA was developed as a set of cryptographic hash functions by the NSA, and a great many security protocols and applications employ SHA. Since SHA is essentially really hard math, it's not unbreakable, and over the last several years, concerns have been raised about potential mathematical weaknesses in the existing algorithms.

SHA-1 attacks in 2005 pointed out some security flaws, and everyone agreed that a stronger hash function would be needed. As of today, there haven't been any reported SHA-2 attacks or associated flaws.

The SHA-3 competition is similar to the efforts to develop Advanced Encryption Standard (AES), a block cipher adopted as an encrypted standard by the US government. Development of AES was needed after it became apparent that neither DES or 3DES were secure in this age of more powerful computing. AES is now used extensively in symmetric key encryption.

A hash function takes binary data (1s and 0s for you non-binary types) called the message, and condenses it down into the smaller message digest. To make that easier to understand, think about the Readers Digest magazine - taking longer versions and squishing them down for presentation - even though the whole story wasn't there, you got the gist of what the writer was saying.

A cryptographic hash function is a deterministic procedure (the algorithm, or really hard math) that takes a chunk of data and returns a fixed-length bit string, known as the hash value. If I go back and change any of the original chunk of data, either accidently or on purpose, then the hash value will also change. From a security perspective, I would know that the original data has been tampered with.

In this case, I would call the chunk of data the message, and the hash value the message digest. I can use the hash value as part of a digital signature (such as signing email or data transmissions to ensure integrity), for authentication purposes (proving you are who you say you are before granting access), or for any number of information security reasons.

Hopefully, the SHA-3 competition will provide a foundationally-secure algorithm that will buy us 5-10 years of grace before SHA-3 itself is broken. Letting crypto experts worldwide submit their own entries while trying their best to crack the submissions of others is a good start. It takes a special mind to be able to understand this stuff, and an incredible mind to create it.