Entries Tagged "encryption"

Page 22 of 56

Companies Not Saving Your Data

There’s a new trend in Silicon Valley startups; companies are not collecting and saving data on their customers:

In Silicon Valley, there’s a new emphasis on putting up barriers to government requests for data. The Apple-FBI case and its aftermath have tech firms racing to employ a variety of tools that would place customer information beyond the reach of a government-ordered search.

The trend is a striking reversal of a long-standing article of faith in the data-hungry tech industry, where companies including Google and the latest start-ups have predicated success on the ability to hoover up as much information as possible about consumers.

Now, some large tech firms are increasingly offering services to consumers that rely far less on collecting data. The sea change is even becoming evident among early-stage companies that see holding so much data as more of a liability than an asset, given the risk that cybercriminals or government investigators might come knocking.

Start-ups that once hesitated to invest in security are now repurposing limited resources to build technical systems to shed data, even if it hinders immediate growth.

The article also talks about companies providing customers with end-to-end encryption.

I believe that all this data isn’t nearly as valuable as the big-data people are promising. Now that companies are recognizing that it is also a liability, I think we’re going to see more rational trade-offs about what to keep—and for how long—and what to discard.

Posted on May 25, 2016 at 2:37 PMView Comments

NIST Starts Planning for Post-Quantum Cryptography

Last year, the NSA announced its plans for transitioning to cryptography that is resistant to a quantum computer. Now, it’s NIST’s turn. Its just-released report talks about the importance of algorithm agility and quantum resistance. Sometime soon, it’s going to have a competition for quantum-resistant public-key algorithms:

Creating those newer, safer algorithms is the longer-term goal, Moody says. A key part of this effort will be an open collaboration with the public, which will be invited to devise and vet cryptographic methods that—to the best of experts’ knowledge—­will be resistant to quantum attack. NIST plans to launch this collaboration formally sometime in the next few months, but in general, Moody says it will resemble past competitions such as the one for developing the SHA-3 hash algorithm, used in part for authenticating digital messages.

“It will be a long process involving public vetting of quantum-resistant algorithms,” Moody said. “And we’re not expecting to have just one winner. There are several systems in use that could be broken by a quantum computer­—public-key encryption and digital signatures, to take two examples­—and we will need different solutions for each of those systems.”

The report rightly states that we’re okay in the symmetric cryptography world; the key lengths are long enough.

This is an excellent development. NIST has done an excellent job with their previous cryptographic standards, giving us a couple of good, strong, well-reviewed, and patent-free algorithms. I have no doubt this process will be equally excellent. (If NIST is keeping a list, aside from post-quantum public-key algorithms, I would like to see competitions for a larger-block-size block cipher and a super-fast stream cipher as well.)

Two news articles.

Posted on May 9, 2016 at 6:19 AMView Comments

Own a Pair of Clipper Chips

The AT&T TSD was an early 1990s telephone encryption device. It was digital. Voice quality was okay. And it was the device that contained the infamous Clipper Chip, the U.S. government’s first attempt to put a back door into everyone’s communications.

Marcus Ranum is selling a pair on eBay. He has the description wrong, though. The TSD-3600-E is the model with the Clipper Chip in it. The TSD-3600-F is the version with the insecure exportable algorithm.

Posted on May 5, 2016 at 6:31 AMView Comments

BlackBerry's Global Encryption Key

Last week, there was a big news story about the BlackBerry encryption key. The news was that all BlackBerry devices share a global encryption key, and that the Canadian RCMP has a copy of it. Stupid design, certainly, but it’s not news. As the Register points out, this has been repeatedly reported on since 2010.

And note that this only holds for individual users. If your organization uses a BlackBerry Enterprise Server (BES), you have your own unique key.

Posted on April 25, 2016 at 5:54 AMView Comments

CONIKS

CONIKS is an new easy-to-use transparent key-management system:

CONIKS is a key management system for end users capable of integration in end-to-end secure communication services. The main idea is that users should not have to worry about managing encryption keys when they want to communicate securely, but they also should not have to trust their secure communication service providers to act in their interest.

Here’s the academic paper. And here’s a good discussion of the protocol and how it works. This is the problem they’re trying to solve:

One of the main challenges to building usable end-to-end encrypted communication tools is key management. Services such as Apple’s iMessage have made encrypted communication available to the masses with an excellent user experience because Apple manages a directory of public keys in a centralized server on behalf of their users. But this also means users have to trust that Apple’s key server won’t be compromised or compelled by hackers or nation-state actors to insert spurious keys to intercept and manipulate users’ encrypted messages. The alternative, and more secure, approach is to have the service provider delegate key management to the users so they aren’t vulnerable to a compromised centralized key server. This is how Google’s End-To-End works right now. But decentralized key management means users must “manually” verify each other’s keys to be sure that the keys they see for one another are valid, a process that several studies have shown to be cumbersome and error-prone for the vast majority of users. So users must make the choice between strong security and great usability.

And this is CONIKS:

In CONIKS, communication service providers (e.g. Google, Apple) run centralized key servers so that users don’t have to worry about encryption keys, but the main difference is CONIKS key servers store the public keys in a tamper-evident directory that is publicly auditable yet privacy-preserving. On a regular basis, CONIKS key servers publish directory summaries, which allow users in the system to verify they are seeing consistent information. To achieve this transparent key management, CONIKS uses various cryptographic mechanisms that leave undeniable evidence if any malicious outsider or insider were to tamper with any key in the directory and present different parties different views of the directory. These consistency checks can be automated and built into the communication apps to minimize user involvement.

Posted on April 6, 2016 at 10:27 AMView Comments

ISIS Encryption Opsec

Tidbits from the New York Times:

The final phase of Mr. Hame’s training took place at an Internet cafe in Raqqa, where an Islamic State computer specialist handed him a USB key. It contained CCleaner, a program used to erase a user’s online history on a given computer, as well as TrueCrypt, an encryption program that was widely available at the time and that experts say has not yet been cracked.

[…]

More than a year and a half earlier, the would-be Cannes bomber, Ibrahim Boudina, had tried to erase the previous three days of his search history, according to details in his court record, but the police were still able to recover it. They found that Mr. Boudina had been researching how to connect to the Internet via a secure tunnel and how to change his I.P. address.

Though he may have been aware of the risk of discovery, perhaps he was not worried enough.

Mr. Boudina had been sloppy enough to keep using his Facebook account, and his voluminous chat history allowed French officials to determine his allegiance to the Islamic State. Wiretaps of his friends and relatives, later detailed in French court records obtained by The Times and confirmed by security officials, further outlined his plot, which officials believe was going to target the annual carnival on the French Riviera.

Mr. Hame, in contrast, was given strict instructions on how to communicate. After he used TrueCrypt, he was to upload the encrypted message folder onto a Turkish commercial data storage site, from where it would be downloaded by his handler in Syria. He was told not to send it by email, most likely to avoid generating the metadata that records details like the point of origin and destination, even if the content of the missive is illegible. Mr. Hame described the website as “basically a dead inbox.”

The ISIS technician told Mr. Hame one more thing: As soon as he made it back to Europe, he needed to buy a second USB key, and transfer the encryption program to it. USB keys are encoded with serial numbers, so the process was not unlike a robber switching getaway cars.

“He told me to copy what was on the key and then throw it away,” Mr. Hame explained. “That’s what I did when I reached Prague.”

Mr. Abaaoud was also fixated on cellphone security. He jotted down the number of a Turkish phone that he said would be left in a building in Syria, but close enough to the border to catch the Turkish cell network, according to Mr. Hame’s account. Mr. Abaaoud apparently figured investigators would be more likely to track calls from Europe to Syrian phone numbers, and might overlook calls to a Turkish one.

Next to the number, Mr. Abaaoud scribbled “Dad.”

This seems like exactly the sort of opsec I would set up for an insurgent group.

EDITED TO ADD: Mistakes in the article. For example:

And now I’ve read one of the original French documents and confirmed my suspicion that the NYTimes article got details wrong.

The original French uses the word “boîte”, which matches the TrueCrypt term “container”. The original French didn’t use the words “fichier” (file), “dossier” (folder), or “répertoire” (directory). This makes so much more sense, and gives us more confidence we know what they were doing.

The original French uses the term “site de partage”, meaning a “sharing site”, which makes more sense than a “storage” site.

The document I saw says the slip of paper had login details for the file sharing site, not a TrueCrypt password. Thus, when the NYTimes article says “TrueCrypt login credentials”, we should correct it to “file sharing site login credentials”, not “TrueCrypt passphrase”.

MOST importantly, according the subject, the login details didn’t even work. It appears he never actually used this method—he was just taught how to use it. He no longer remembers the site’s name, other than it might have the word “share” in its name. We see this a lot: ISIS talks a lot about encryption, but the evidence of them actually using it is scant.

Posted on March 31, 2016 at 6:10 AMView Comments

1981 US Document on Encryption Policy

This was newly released under FOIA at my request: Victor C. Williams, Jr., Donn B. Parker, and Charles C. Wood, “Impacts of Federal Policy Options for Nonmilitary Cryptography,” NTIA-CR-81-10, National Telecommunications and Information Administration, US. Department of Commerce, June 1981. It argues that cryptography is an important enabling technology. At this point, it’s only of historical value.

Posted on March 23, 2016 at 6:20 AMView Comments

iMessage Encryption Flaw Found and Fixed

Matthew Green and team found and reported a significant iMessage encryption flaw last year.

Green suspected there might be a flaw in iMessage last year after he read an Apple security guide describing the encryption process and it struck him as weak. He said he alerted the firm’s engineers to his concern. When a few months passed and the flaw remained, he and his graduate students decided to mount an attack to show that they could pierce the encryption on photos or videos sent through iMessage.

It took a few months, but they succeeded, targeting phones that were not using the latest operating system on iMessage, which launched in 2011.

To intercept a file, the researchers wrote software to mimic an Apple server. The encrypted transmission they targeted contained a link to the photo stored in Apple’s iCloud server as well as a 64-digit key to decrypt the photo.

Although the students could not see the key’s digits, they guessed at them by a repetitive process of changing a digit or a letter in the key and sending it back to the target phone. Each time they guessed a digit correctly, the phone accepted it. They probed the phone in this way thousands of times.

“And we kept doing that,” Green said, “until we had the key.”

A modified version of the attack would also work on later operating systems, Green said, adding that it would likely have taken the hacking skills of a nation-state.

This flaw is fixed in iOS 9.3. (You should download and install it now.)

I wrote about this flaw in IEEE Security and Privacy earlier this year:

Going back to the new vulnerability that you’ll learn about in mid-February, the lead researcher wrote to me: “If anyone tells you that [the vendor] can just ‘tweak’ the system a little bit to add key escrow or to man-in-the-middle specific users, they need to spend a few days watching the authentication dance between [the client device/software] and the umpteen servers it talks to just to log into the network. I’m frankly amazed that any of it works at all, and you couldn’t pay me enough to tamper with any of it.” This is an important piece of wisdom.

The designers of this system aren’t novices. They’re an experienced team with some of the best security engineers in the field. If these guys can’t get the security right, just imagine how much worse it is for smaller companies without this team’s level of expertise and resources. Now imagine how much worse it would be if you add a government-mandated back door. There are more opportunities to get security wrong, and more engineering teams without the time and expertise necessary to get

Related: A different iOS flaw was reported last week. Called AceDeceiver, it is a Trojan that allows an attacker to install malicious software onto an iOS device, bypassing Apple’s DRM protections. I don’t believe that Apple has fixed this yet, although it seems as if Apple just has to add a certificate revocation list, or make the certs nonreplayable by having some mandatory interaction with the iTunes store.

EDITED (4/14): The paper describing the iMessage flaw.

Posted on March 21, 2016 at 1:45 PMView Comments

1 20 21 22 23 24 56

Sidebar photo of Bruce Schneier by Joe MacInnis.