Entries Tagged "encryption"

Page 32 of 57

"Unbreakable" Encryption Almost Certainly Isn't

This headline is provocative: “Human biology inspires ‘unbreakable’ encryption.”

The article is similarly nonsensical:

Researchers at Lancaster University, UK have taken a hint from the way the human lungs and heart constantly communicate with each other, to devise an innovative, highly flexible encryption algorithm that they claim can’t be broken using the traditional methods of cyberattack.

Information can be encrypted with an array of different algorithms, but the question of which method is the most secure is far from trivial. Such algorithms need a “key” to encrypt and decrypt information; the algorithms typically generate their keys using a well-known set of rules that can only admit a very large, but nonetheless finite number of possible keys. This means that in principle, given enough time and computing power, prying eyes can always break the code eventually.

The researchers, led by Dr. Tomislav Stankovski, created an encryption mechanism that can generate a truly unlimited number of keys, which they say vastly increases the security of the communication. To do so, they took inspiration from the anatomy of the human body.

Regularly, someone from outside cryptography—who has no idea how crypto works—pops up and says “hey, I can solve their problems.” Invariably, they make some trivial encryption scheme because they don’t know better.

Remember: anyone can create a cryptosystem that he himself cannot break. And this advice from 15 years ago is still relevant.

Another article, and the paper.

Posted on April 8, 2014 at 6:16 AM • View Comments

PowerLocker uses Blowfish

There’s a new piece of ransomware out there, PowerLocker (also called PrisonLocker), that uses Blowfish:

PowerLocker could prove an even more potent threat because it would be sold in underground forums as a DIY malware kit to anyone who can afford the $100 for a license, Friday’s post warned. CryptoLocker, by contrast, was custom built for use by a single crime gang. What’s more, PowerLocker might also offer several advanced features, including the ability to disable the task manager, registry editor, and other administration functions built into the Windows operating system. Screen shots and online discussions also indicate the newer malware may contain protections that prevent it from being reverse engineered when run on virtual machines.

PowerLocker encrypts files using keys based on the Blowfish algorithm. Each key is then encrypted to a file that can only be unlocked by a 2048-bit private RSA key. The Malware Must Die researchers said they had been monitoring the discussions for the past few months. The possibility of a new crypto-based ransomware threat comes as developers continue to make improvements to the older CryptoLocker title. Late last month, for instance, researchers at antivirus provider Trend Micro said newer versions gave the CryptoLocker self-replicating abilities that allowed it to spread through USB thumb drives.

Posted on January 17, 2014 at 2:57 PM • View Comments

Operation Vula

“Talking to Vula” is the story of a 1980s secret communications channel between black South African leaders and others living in exile in the UK. The system used encrypted text encoded into DTMF “touch tones” and transmitted from pay phones.

Our next project was one that led to the breakthrough we had been waiting for. We had received a request, as members of the Technical Committee, to find a way for activists to contact each other safely in an urban environment. Ronnie had seen a paging device that could be used between users of walkie-talkies. A numeric keypad was attached to the front of each radio set and when a particular number was pressed a light would flash on the remote set that corresponded to the number. The recipient of the paging signal could then respond to the caller using a pre-determined frequency so that the other users would not know about it.

Since the numbers on the keypad actually generated the same tones as those of a touch-tone telephone it occurred to us that instead of merely having a flashing light at the recipient`s end you could have a number appear corresponding to the number pressed on the keypad. If you could have one number appear you could have all numbers appear and in this way send a coded message. If the enemy was monitoring the airwaves all they would hear was a series of tones that would mean nothing.

Taking this a step further we realised that if you could send the tones by radio then they could also be sent by telephone, especially as the tones were intended for use on telephone systems. Ronnie put together a little microphone device that – when held on the earpiece of the receiving telephone – could display whatever number was pressed at the sending end. Using touch-tone telephones or separate tone pads as used for telephone banking services two people could send each other coded messages over the telephone. This could be done from public telephones, thus ensuring the safety of the users.

To avoid having to key in the numbers while in a telephone booth the tones could be recorded on a tape recorder at home and then played into the telephone. Similarly, at the receiving end, the tones could be recorded on a tape recorder and then decoded later. Messages could even be sent to an answering machine and picked up from an answering machine if left as the outgoing message.

We gave a few of these devices, disguised as electronic calculators, to activists to take back to South Africa. They were not immensely successful as the coding still had to be done by hand and that remained the chief factor discouraging people from communicating.

The next step was an attempt to marry the tone communication system with computer encryption. Ronnie got one of the boffins at the polytechnic to construct a device that produced the telephone tones at very high speed. This was attached to a computer that did the encryption. The computer, through the device, output the encrypted message as a series of tones and these could be saved on a cassette tape recorder that could be taken to a public telephone. This seemed to solve the problem of underground communications as everything could be done from public telephones and the encryption was done by computer.

Lots more operational details in the article.

Posted on December 26, 2013 at 6:44 AM • View Comments

NSA Spying: Whom Do You Believe?

On Friday, Reuters reported that RSA entered into a secret contract to make DUAL_EC_PRNG the default random number generator in the BSAFE toolkit. DUA_EC_PRNG is now known to have been backdoored by the NSA.

Yesterday, RSA denied it:

Recent press coverage has asserted that RSA entered into a “secret contract” with the NSA to incorporate a known flawed random number generator into its BSAFE encryption libraries. We categorically deny this allegation.

[…]

We made the decision to use Dual EC DRBG as the default in BSAFE toolkits in 2004, in the context of an industry-wide effort to develop newer, stronger methods of encryption. At that time, the NSA had a trusted role in the community-wide effort to strengthen, not weaken, encryption.

We know from both Mark Klein and Edward Snowden—and pretty much everything else about the NSA—that the NSA directly taps the trunk lines of AT&T (and pretty much every other telcom carrier). On Friday, AT&T denied that:

In its statement, AT&T sought to push back against the notion that it provides the government with such access. “We do not allow any government agency to connect directly to our network to gather, review or retrieve our customers’ information,” said Watts.

I’ve written before about how the NSA has corroded our trust in the Internet and communications technologies. The debates over these companies’ statements, and about exactly how they are using and abusing individual words to lie while claiming they are not lying, is a manifestation of that.

Me again:

This sort of thing can destroy our country. Trust is essential in our society. And if we can’t trust either our government or the corporations that have intimate access into so much of our lives, society suffers. Study after study demonstrates the value of living in a high-trust society and the costs of living in a low-trust one.

Rebuilding trust is not easy, as anyone who has betrayed or been betrayed by a friend or lover knows, but the path involves transparency, oversight and accountability. Transparency first involves coming clean. Not a little bit at a time, not only when you have to, but complete disclosure about everything. Then it involves continuing disclosure. No more secret rulings by secret courts about secret laws. No more secret programs whose costs and benefits remain hidden.

Oversight involves meaningful constraints on the NSA, the FBI and others. This will be a combination of things: a court system that acts as a third-party advocate for the rule of law rather than a rubber-stamp organization, a legislature that understands what these organizations are doing and regularly debates requests for increased power, and vibrant public-sector watchdog groups that analyze and debate the government’s actions.

Accountability means that those who break the law, lie to Congress or deceive the American people are held accountable. The NSA has gone rogue, and while it’s probably not possible to prosecute people for what they did under the enormous veil of secrecy it currently enjoys, we need to make it clear that this behavior will not be tolerated in the future. Accountability also means voting, which means voters need to know what our leaders are doing in our name.

This is the only way we can restore trust. A market economy doesn’t work unless consumers can make intelligent buying decisions based on accurate product information. That’s why we have agencies like the FDA, truth-in-packaging laws and prohibitions against false advertising.

We no longer know whom to trust. This is the greatest damage the NSA has done to the Internet, and will be the hardest to fix.

EDITED TO ADD (12/23): The requested removal of an NSA employee from an IETF group co-chairmanship is another manifestation of this mistrust.

Posted on December 23, 2013 at 6:26 AM • View Comments

Defending Against Crypto Backdoors

We already know the NSA wants to eavesdrop on the Internet. It has secret agreements with telcos to get direct access to bulk Internet traffic. It has massive systems like TUMULT, TURMOIL, and TURBULENCE to sift through it all. And it can identify ciphertext—encrypted information—and figure out which programs could have created it.

But what the NSA wants is to be able to read that encrypted information in as close to real-time as possible. It wants backdoors, just like the cybercriminals and less benevolent governments do.

And we have to figure out how to make it harder for them, or anyone else, to insert those backdoors.

How the NSA Gets Its Backdoors

The FBI tried to get backdoor access embedded in an AT&T secure telephone system in the mid-1990s. The Clipper Chip included something called a LEAF: a Law Enforcement Access Field. It was the key used to encrypt the phone conversation, itself encrypted in a special key known to the FBI, and it was transmitted along with the phone conversation. An FBI eavesdropper could intercept the LEAF and decrypt it, then use the data to eavesdrop on the phone call.

But the Clipper Chip faced severe backlash, and became defunct a few years after being announced.

Having lost that public battle, the NSA decided to get its backdoors through subterfuge: by asking nicely, pressuring, threatening, bribing, or mandating through secret order. The general name for this program is BULLRUN.

Defending against these attacks is difficult. We know from subliminal channel and kleptography research that it’s pretty much impossible to guarantee that a complex piece of software isn’t leaking secret information. We know from Ken Thompson’s famous talk on “trusting trust” (first delivered in the ACM Turing Award Lectures) that you can never be totally sure if there’s a security flaw in your software.

Since BULLRUN became public last month, the security community has been examining security flaws discovered over the past several years, looking for signs of deliberate tampering. The Debian random number flaw was probably not deliberate, but the 2003 Linux security vulnerability probably was. The DUAL_EC_DRBG random number generator may or may not have been a backdoor. The SSL 2.0 flaw was probably an honest mistake. The GSM A5/1 encryption algorithm was almost certainly deliberately weakened. All the common RSA moduli out there in the wild: we don’t know. Microsoft’s _NSAKEY looks like a smoking gun, but honestly, we don’t know.

How the NSA Designs Backdoors

While a separate program that sends our data to some IP address somewhere is certainly how any hacker—from the lowliest script kiddie up to the NSA—spies on our computers, it’s too labor-intensive to work in the general case.

For government eavesdroppers like the NSA, subtlety is critical. In particular, three characteristics are important:

  • Low discoverability. The less the backdoor affects the normal operations of the program, the better. Ideally, it shouldn’t affect functionality at all. The smaller the backdoor is, the better. Ideally, it should just look like normal functional code. As a blatant example, an email encryption backdoor that appends a plaintext copy to the encrypted copy is much less desirable than a backdoor that reuses most of the key bits in a public IV (initialization vector).
  • High deniability. If discovered, the backdoor should look like a mistake. It could be a single opcode change. Or maybe a “mistyped” constant. Or “accidentally” reusing a single-use key multiple times. This is the main reason I am skeptical about _NSAKEY as a deliberate backdoor, and why so many people don’t believe the DUAL_EC_DRBG backdoor is real: they’re both too obvious.
  • Minimal conspiracy. The more people who know about the backdoor, the more likely the secret is to get out. So any good backdoor should be known to very few people. That’s why the recently described potential vulnerability in Intel’s random number generator worries me so much; one person could make this change during mask generation, and no one else would know.

These characteristics imply several things:

  • A closed-source system is safer to subvert, because an open-source system comes with a greater risk of that subversion being discovered. On the other hand, a big open-source system with a lot of developers and sloppy version control is easier to subvert.
  • If a software system only has to interoperate with itself, then it is easier to subvert. For example, a closed VPN encryption system only has to interoperate with other instances of that same proprietary system. This is easier to subvert than an industry-wide VPN standard that has to interoperate with equipment from other vendors.
  • A commercial software system is easier to subvert, because the profit motive provides a strong incentive for the company to go along with the NSA’s requests.
  • Protocols developed by large open standards bodies are harder to influence, because a lot of eyes are paying attention. Systems designed by closed standards bodies are easier to influence, especially if the people involved in the standards don’t really understand security.
  • Systems that send seemingly random information in the clear are easier to subvert. One of the most effective ways of subverting a system is by leaking key information—recall the LEAF—and modifying random nonces or header information is the easiest way to do that.

Design Strategies for Defending against Backdoors

With these principles in mind, we can list design strategies. None of them is foolproof, but they are all useful. I’m sure there’s more; this list isn’t meant to be exhaustive, nor the final word on the topic. It’s simply a starting place for discussion. But it won’t work unless customers start demanding software with this sort of transparency.

  • Vendors should make their encryption code public, including the protocol specifications. This will allow others to examine the code for vulnerabilities. It’s true we won’t know for sure if the code we’re seeing is the code that’s actually used in the application, but surreptitious substitution is hard to do, forces the company to outright lie, and increases the number of people required for the conspiracy to work.
  • The community should create independent compatible versions of encryption systems, to verify they are operating properly. I envision companies paying for these independent versions, and universities accepting this sort of work as good practice for their students. And yes, I know this can be very hard in practice.
  • There should be no master secrets. These are just too vulnerable.
  • All random number generators should conform to published and accepted standards. Breaking the random number generator is the easiest difficult-to-detect method of subverting an encryption system. A corollary: we need better published and accepted RNG standards.
  • Encryption protocols should be designed so as not to leak any random information. Nonces should be considered part of the key or public predictable counters if possible. Again, the goal is to make it harder to subtly leak key bits in this information.

This is a hard problem. We don’t have any technical controls that protect users from the authors of their software.

And the current state of software makes the problem even harder: Modern apps chatter endlessly on the Internet, providing noise and cover for covert communications. Feature bloat provides a greater “attack surface” for anyone wanting to install a backdoor.

In general, what we need is assurance: methodologies for ensuring that a piece of software does what it’s supposed to do and nothing more. Unfortunately, we’re terrible at this. Even worse, there’s not a lot of practical research in this area—and it’s hurting us badly right now.

Yes, we need legal prohibitions against the NSA trying to subvert authors and deliberately weaken cryptography. But this isn’t just about the NSA, and legal controls won’t protect against those who don’t follow the law and ignore international agreements. We need to make their job harder by increasing their risk of discovery. Against a risk-averse adversary, it might be good enough.

This essay previously appeared on Wired.com.

EDITED TO ADD: I am looking for other examples of known or plausible instances of intentional vulnerabilities for a paper I am writing on this topic. If you can think of an example, please post a description and reference in the comments below. Please explain why you think the vulnerability could be intentional. Thank you.

Posted on October 22, 2013 at 6:15 AM • View Comments

NSA Harvesting Contact Lists

A new Snowden document shows that the NSA is harvesting contact lists—e-mail address books, IM buddy lists, etc.—from Google, Yahoo, Microsoft, Facebook, and others.

Unlike PRISM, this unnamed program collects the data from the Internet . This is similar to how the NSA identifies Tor users. They get direct access to the Internet backbone, either through secret agreements with companies like AT&T, or surreptitiously, by doing things like tapping undersea cables. Once they have the data, they have powerful packet inspectors—code names include TUMULT, TURBULENCE, and TURMOIL—that run a bunch of different identification and copying systems. One of them, code name unknown, searches for these contact lists and copies them. Google, Yahoo, Microsoft, etc., have no idea that this is happening, nor have they consented to their data being harvested in this way.

These contact lists provide the NSA with the same sort of broad surveillance that the Verizon (and others) phone-record “metadata” collection programs provide: information about who are our friends, lovers, confidants, associates. This is incredibly intimate information, all collected without any warrant or due process. Metadata equals surveillance; always remember that.

The quantities are interesting:

During a single day last year, the NSA’s Special Source Operations branch collected 444,743 e-mail address books from Yahoo, 105,068 from Hotmail, 82,857 from Facebook, 33,697 from Gmail and 22,881 from unspecified other providers….

Note that Gmail, which uses SSL by default, provides the NSA with much less data than Yahoo, which doesn’t, despite the fact that Gmail has many more users than Yahoo does. (It’s actually kind of amazing how small that Gmail number is.) This implies that, despite BULLRUN, encryption works. Ubiquitous use of SSL can foil NSA eavesdropping. This is the same lesson we learned from the NSA’s attempts to break Tor: encryption works.

In response to this story, Yahoo has finally decided to enable SSL by default: by January 2014.

One more amusing bit: the NSA has a spam problem.

Spam has proven to be a significant problem for the NSA—clogging databases with information that holds no foreign intelligence value. The majority of all e-mails, one NSA document says, “are SPAM from ‘fake addresses and never ‘delivered’ to targets.”

The Washington Post published three NSA documents to support this article.

EDITED TO ADD: The New York Times makes this observation:

Spokesmen for the eavesdropping organizations reassured The Post that we shouldn’t bother our heads with all of this. They have “checks and balances built into our tools,” said one intelligence official.

Since the Snowden leaks began, the administration has adopted an interesting definition of that term. It used to be that “checks and balances” referred to one branch of the government checking and balancing the other branches—like the Supreme Court deciding whether laws are constitutional.

Now the N.S.A., the C.I.A. and the White House use the term to refer to a secret organization reviewing the actions it has taken and deciding in secret by itself whether they were legal and constitutional.

Posted on October 15, 2013 at 1:37 PM • View Comments

New Secure Smart Phone App

It’s hard not to poke fun at this press release for Safeslinger, a new cell phone security app from Carnegie Mellon.

“SafeSlinger provides you with the confidence that the person you are communicating with is actually the person they have represented themselves to be,” said Michael W. Farb, a research programmer at Carnegie Mellon CyLab. “The most important feature is that SafeSlinger provides secure messaging and file transfer without trusting the phone company or any device other than my own smartphone.”

Oddly, Farb believes that he can trust his smart phone.

This headline claims that “even [the] NSA can’t crack” it, but it’s unclear where that claim came from.

Still, it’s good to have encrypted chat programs. This one joins Cryptocat, Silent Circle, and my favorite: OTR.

Posted on October 15, 2013 at 12:37 PM • View Comments

Will Keccak = SHA-3?

Last year, NIST selected Keccak as the winner of the SHA-3 hash function competition. Yes, I would have rather my own Skein had won, but it was a good choice.

But last August, John Kelsey announced some changes to Keccak in a talk (slides 44-48 are relevant). Basically, the security levels were reduced and some internal changes to the algorithm were made, all in the name of software performance.

Normally, this wouldn’t be a big deal. But in light of the Snowden documents that reveal that the NSA has attempted to intentionally weaken cryptographic standards, this is a huge deal. There is too much mistrust in the air. NIST risks publishing an algorithm that no one will trust and no one (except those forced) will use.

At this point, they simply have to standardize on Keccak as submitted and as selected.

CDT has a great post about this.

Also this Slashdot thread.

EDITED TO ADD (10/5): It’s worth reading the response from the Keccak team on this issue.

I misspoke when I wrote that NIST made “internal changes” to the algorithm. That was sloppy of me. The Keccak permutation remains unchanged. What NIST proposed was reducing the hash function’s capacity in the name of performance. One of Keccak’s nice features is that it’s highly tunable.

I do not believe that the NIST changes were suggested by the NSA. Nor do I believe that the changes make the algorithm easier to break by the NSA. I believe NIST made the changes in good faith, and the result is a better security/performance trade-off. My problem with the changes isn’t cryptographic, it’s perceptual. There is so little trust in the NSA right now, and that mistrust is reflecting on NIST. I worry that the changed algorithm won’t be accepted by an understandably skeptical security community, and that no one will use SHA-3 as a result.

This is a lousy outcome. NIST has done a great job with cryptographic competitions: both a decade ago with AES and now with SHA-3. This is just another effect of the NSA’s actions draining the trust out of the Internet.

Posted on October 1, 2013 at 10:50 AM • View Comments

1 … 30 31 32 33 34 … 57

Sidebar photo of Bruce Schneier by Joe MacInnis.