Tag: Encryption

Categories
Links Writing

FFS SSL

FFS SSL:

I just set up SSLTLS on my web site. Everything can be had via https://wingolog.org/, and things appear to work. However the process of transitioning even a simple web site to SSL is so clownshoes bad that it’s amazing anyone ever does it. So here’s an incomplete list of things that can go wrong when you set up TLS on a web site.

…

Now you start to add secure features to your web app, safe with the idea you have SSL. But better not forget to mark your cookies as secure, otherwise they could be leaked in the clear, and better not forget that your website might also be served over HTTP. And better check up on when your cert expires, and better have a plan for embedded browsers that don’t have useful feedback to the user about certificate status, and what about your CA’s audit trail, and better stay on top of the new developments in security! Did you read it? Did you read it? Did you read it?

It’s a wonder anything works. Indeed I wonder if anything does.

Without any doubt this is one of the better(?) rants about SSL/TLS that I’ve read recently. And given my own recent experiences in setting up SSL/TLS on another site I entirely empathize: it was a horrible experience that involved tracking down what was causing things to break, when they were breaking, and how to remedy them. It was a non-trivial learning experience and that was a very simple site. Large sites….well, I shudder to consider the work entailed in securing them.

(As a sidenote: yes, SSL/TLS is broken. But it adds friction to mass surveillance processes and at little cost to the visitor of websites/users of web services. It’s a pain for those delivering content, but that’s a pain that it’s arguably appropriate for those content providers to bear.)

Categories
Links

Advancing Encryption for the Masses

Advancing Encryption for the Masses:

The work of WhatsApp, Facebook, Open Whisper Systems, the Electronic Frontier Foundation, and that other members of the ‘Let’s Encrypt’ initiative can massively reduce the challenges people face when trying to communicate more responsibly. And the initiatives demonstrate how the cryptographic and communications landscape is shifting in the wake of Snowden’s revelations concerning the reality of global-scale surveillance. While encryption was ultimately thrown out of the original design specifications for the Internet it’s great to see that cryptography is starting to get bolted onto the existing Internet in earnest.

 

Categories
Aside Links

Google is researching ways to make encryption easier to use in Gmail

Google is researching ways to make encryption easier to use in Gmail:

In response to Edward Snowden’s mass surveillance revelations, Google is working to make complex encryption tools, such as PGP, easier to use in Gmail.

PGP, or Pretty Good Privacy, is an encryption utility that historically has been difficult to break. But Google has “research underway to improve the usability of PGP with Gmail,” according to a person at the company familiar with the matter.

If Google is actually going to throw engineers and designers (most important: lots, and lots, and lots of UI and UX designers!) towards improving the basic usability of PGP that would be incredible. However, given people’s suspicion of the company given the NSA disclosures I have to wonder whether any public offering from Google will be regarded as some kind of a trojan horse by some civil liberties groups and the cynical public alike.

Categories
Quotations

2014.2.26

The NSA can’t break Tor and it [ticks] them off. Most crypto drives the NSA batty,” [Bruce Schneier] said. “Encryption works and it works at scale. The NSA may have a large budget than all of the other intelligence agencies combined, but they are not made of magic. Our goal should be to make eavesdropping more expensive. We should have the goal of limiting bulk collection and forcing targeted collection.

Bruce Schneier, quoted in Dennis Fisher, “The NSA is ‘not made of magic’”
Categories
Links Quotations

Potholes abound on the road to car-to-car communication

The security design of the system as implemented in tests so far will require a national certificate infrastructure much like that used for preventing domain spoofing and securing the Web. It will require a database of certificates—like the X.509 certificates used in public key infrastructure (PKI)—to verify that devices are legitimate and make it possible to rescind permissions to ensure that no one can send out spoofed messages. If a certificate were to become compromised or if a manufacturer misconfigured a batch of V2V systems, the certificate authority would be able to revoke the associated certificate. This prevents spoofing much in the way that DNS SEC prevents the “poisoning” of Internet domain address tables by a rogue Domain Name Service server.

The problem is that no one has ever developed a PKI system large enough to handle every vehicle in the United States—every car, truck, bus, and motorcycle. The revocation table for expired or compromised certificates would have to be distributed constantly to cars to make sure they weren’t victimized by recorded data attacks or other systems that used hacked hardware to spoof traffic.

So far, there hasn’t been any agreement yet on how this PKI would distribute its certificates. Proposals have included having roadside systems issue certificates as vehicles drive by and having certificates sent to vehicles out-of-band over cellular connections. The latter would mean that every car in the country would have to have its own integrated cellular phone or that drivers would have to connect their phones regularly to the systems to ensure they didn’t get shut out of the network.

Oh yes, please: let’s build a mass communications network dependent on a (largely) creaky Certificate system, deploy the devices to the attackers (i.e. car owners), and just trust that no one’s gonna hack a mass, nation-wide, Vehicle-to-Vehicle communications network.

Also: taking bets on it being an escrowed certificate system. For public safety and all that good stuff.

Categories
Links

The strange connection between the NSA and an Ontario tech firm

I’m not in corporate PR, but when it turns out your company (i.e. BlackBerry) holds the patent on a known-NSA-backdoored encryption standard I’m not sure shutting up and avoiding the press is the best of ideas. Especially if your product (*cough* BlackBerry *cough*) is predicated on strong security against all attackers.

Source: The strange connection between the NSA and an Ontario tech firm

Categories
Aside Links

Backdooring an ‘Encrypted’ Application

Persuant to my last post on cryptography and pixie dust, it’s helpful to read through Matt Green’s highly accessible article “How to ‘backdoor’ an encryption app.” You’ll find that companies have a host of ways of enabling third-party surveillance, ranging from overt deception to having access to communications metadata to compromising their product’s security if required by authorities. In effect, there are lots of ways that data custodians can undermine their promises to consumers, and it’s pretty rare that the public ever learns that the method(s) used to secure their communications have either been broken or are generally ineffective.

Categories
Writing

Pixie Dust and Data Encryption

CNet recently revealed that Google is encrypting some of their subscribers’ Google Drive data. Data has always been secured in transit, but Google is testing encrypting data at rest. This means that, without the private key, someone who got access to your data on Google’s Drive servers would just get reams of ciphertext. At issue, however, is that ‘encryption’ is only a significant barrier if the the third-party storing your data cannot decrypt the data when a government-backed actor comes knocking.

Encryption has become something like pixie dust, insofar as companies far and wide assure their end-users and subscribers that data is armoured in cryptographic shells. Don’t worry! You’re safe with us! Unfortunately, detailed audits of commercial encrypted products often reveal firms offering more snake oil than genuine protection. Just consider some of the following studies and reports that are, generally, damning[1]:

As noted in Bruce Schneier’s (still) excellent analysis of cryptographic snake oil, there are at least nine warning signs that the company you’re dealing with isn’t providing a working cryptographic solution:

  1. You come across a lot of “pseudo-mathematical goobledygook” that isn’t linked to referenced and reviewed third-party reviews of the cryptographic underpinnings.
  2. The company states that ‘new mathematics’ are used to secure your information.
  3. The cryptographic process is proprietary and neither you nor anyone else can examine how data is secured.
  4. Weird claims are made about the nature of the product, such that the claims or terms used could easily fit within the latest episode of a sci-fi show you’re watching.
  5. Excessive key lengths are trumpted as a demonstrated proof of cryptographic security.
  6. The company claims your data is secure because one-time pads are used.
  7. Claims are made that cannot be backed up in fact.
  8. Security proofs involve twists of linguistic logic, and lack demonstrations of mathematical logic.
  9. The product is somehow secure because it hasn’t been ‘cracked’. (Yet.)

Unfortunately, people have been conditioned by Hollywood and other media that as soon as something is ‘encrypted’ only super-duper hackers can subsequently ‘penetrate the codes and extract the meta-details to derive a data-intuition of the content’ (or some such similiar garbage). When you’re dealing with crappy ‘encryption’ – like showing private keys in plain text, or transmitting passphrases across the Internet in the clear – then the product is just providing consumers a false sense of security. You don’t need to be a hacker to ‘defeat’ particularly poor implementations of data encryption, you often just need to know how to read a file system.

Presently, however, there aren’t clear ways for consumers to know if a product is genuinely capable of securing their data in transit or at rest. There isn’t a clear solution to getting bad products off the market or generally improving product security, save for media shaming and/or the development of better cryptographic libraries that non-cryptographers (read: developers) can easily use when developing product. However, there are always going to be flaws and errors, and most consumers are never going to know that something has gone terribly awry until it’s far, far too late. So, despite there being a well-known problem, there isn’t a productive solution. And that has to change.

  1. The selection of studies were just chosen because they’re sitting on my computer now/I’ve referenced or written about them previously. If you spend a few minutes trawling Google Scholar using the search term ‘encryption broken’ you’re going to come across even more analyses of encryption ‘solutions’ that have been defeated.  ↩
Categories
Links Writing

How to Dispel the Confusion Around iMessage Security | Technology, Thoughts & Trinkets

There’s a lot of confusion about the actual versus rhetorical security integrated with Apple’s iMessage product. I’ve tried to suggest, in the linked article, how Canadians can use our federal privacy laws to figure out whether Apple is, or the company’s critics are, right about the company’s security posture.

Categories
Aside Quotations

2013.4.11

CryptDB, a project out of MIT’s Computer Science and Artificial Intelligence Lab, (CSAIL) may be a solution for this problem. In theory, it would let you glean insights from your data without letting even your own personnel “see” that data at all, said Dr. Sam Madden, CSAIL director, on Friday.

“The goal is to run SQL on encrypted data, you don’t even allow your admin to decrypt any of that data and that’s important in cloud storage, Madden said at an SAP-sponsored event at Hack/reduce in Cambridge, Mass.

Barb Darrow, “You want to crunch top-secret data securely? CryptDB may be the app for that”

This is super interesting work that, if successful, could open a lot of sensitive data to mining. However, it needs to be extensively tested.

One thing that is baked into this product, however, is the assumption that large-scale data mining is good or appropriate. I’m not taking a position that it’s wrong, but note that there isn’t any discussion – that I can find – where journalists are thinking through whether such sensitive information should even be mined in the first place. We (seemingly) are foreclosing this basic and very important question and, in the process, eliding a whole series of important social and normative questions.