Friday, November 23, 2012

Writing security applications for Apple App Store

I spent over two decades in the IT industry, significant portion of that was spent building security applications, including encryption software for EFTPOS terminals used in Australia.

For over a decade now I have been playing with the idea of writing a simple password manager for my own personal use. The idea evolved into a range of products, some of them were free in the public domain and some were commercial applications.

Most recently, since July 2011 I have been working on a product called MiniBluebox that allows users to define and keep their private data such as passwords in one or many secure documents stored on Mac, IOS devices or iCloud.

Unfortunately "security apps" category is a hard sell. Most people do not understand what is involved both in terms of risks, and in terms of technology. It is extremely difficult to communicate security in layman terms especially in an era of Internet-induced attention deficit disorder.

There are hundreds of similar password manager apps, and it is possible that some of these applications could have been developed by people with questionable credentials or intentions.

From my experience even though Apple tests your app for general fitness (eg. crash tests), they do not catch or test everything. It is true that IOS apps are sandboxed, and technically it helps, however sandboxing alone may not be sufficient to protect users' data against malware attacks. Ultimately the users' privacy depends on the type, application method and level of encryption used, among other factors.

We should also consider, the sheer volume of Apple App Store domain which is now staggering. At the time of this writing there are nearly or over 1 million apps on the App Store. The consumers are increasingly exposed to a massive online store with very little at their disposal to filter and check credibility of applications other than dubious star system that focuses on commercially motivated usability aspects.

During app submission Apple asks the developer if their app is using Encryption.

If you answer "Yes" then Apple channels you to a U.S. Government website for you to register your app and its encryption algorithm with Bureau of Industry and Security, U.S. Department of Commerce, Commodity Classification Automated Tracking System (CCATS). Note this is required by U.S. Law.

But my point is not everybody I believe answers this question candidly.

By the nature of my work I interact with other developers at websites such as StackOverflow. I have had the impression that some developers may be hiding the fact that their password management application uses encryption simply to be able to bypass tedious process of registering their apps with CCATS. I also do not think Apple checks whether the question is answered candidly.

So ultimately as a user you should do your homework and investigate thoroughly not only what the app does, but who developed it and how it is being developed.

Personally I try to explain every bit of information that might interest users on product website and in principle I maintain open and honest relationship between myself, Apple, users and everybody else.

The encryption algorithm I use is called Skein which is public domain and how I use it is explained on my website. MiniBluebox is officially registered with Bureau of Industry and Security, U.S. Department of Commerce, Commodity Classification Automated Tracking System (CCATS). MiniBluebox was given the encryption registration number ERN R103536.

There is absolutely no secret on what I am doing, and I strongly encourage my users to contact me for any questions they may have. But by the same token I can't help to think that Apple should provide users and developers a better, fairer and more transparent store environment for users to make informed decisions especially in the area of security.

No comments: