Kenneth van Wyk: Why mobile apps beat Web apps for privacy

Internet communications are prey to surveillance, but you can better shield them

By Kenneth van Wyk, Computerworld |  Security

Yet another excellent resource, Groklaw, is shuttering its services as a consequence of what I'll call the ongoing "Surveillance Wars." Rather than debate the politics of surveillance, I want to again make a case for making our software tools harder and more resilient to attack, regardless of where that attack is coming from.

One thing to consider is making more use of mobile apps as opposed to Web apps. Here's the thing: Surveillance typically targets data in transit, which is something that mobile devices and their apps can do a very decent job of protecting.

In my June column, I talked about safeguarding privacy through email security, stressing key management above all -- specifically, doing our own key management and not trusting any external service from doing it for us.

But we have many other means of communication beyond email. With all of them, it's still vital to consider key management, but things can be slightly different.

Most Internet communications rely on Transport Layer Security (TLS) or its predecessor, Secure Sockets Layer (SSL). In either case, the actual key used to encrypt data in transit is generated by the SSL subsystem. Unless you write your own SSL library, you're probably going to use an SSL that is open and respected among the crypto community -- OpenSSL, Bouncy Castle and the like.

Now, you certainly can use OpenSSL in an iOS or Android application, and you certainly can use Bouncy Castle to build an Android application.

But that's not enough.

When an SSL/TLS session is initiated, the server presents to the client its SSL certificate. In traditional SSL, that certificate is checked for two things: Does the name in the certificate match the name and IP number we can derive via a DNS lookup, and is the certificate signed by a trusted root certificate authority (CA)?

There are a couple of problems with doing only that. First, DNS is not trustworthy, so at least part of the trust validation in the above is placing trust in something that can't support it. Second, if the certificate is signed by any CA, that's good enough for SSL, but it shouldn't be good enough for us.

That's where certificate pinning comes in -- a topic I've mentioned here before. And that's where the mobile part of the argument creeps in.


Originally published on Computerworld |  Click here to read the original story.
Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Answers - Powered by ITworld

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Ask a Question