This blog is about technology, programming, video games, books and other related topics. It is published by Mark Papadakis.

iPhone CSRs, Digital Certificates, Encryption and Cryptography

I have been reading about cryptography, digital certificates and signatures, symmetric and asymmetric keys based encryption lately(well, yesterday). Developing iPhone applications (and even more so deploying them to devices or the AppStore) involves dealing with certificate signing requests(CSRs), digital certificates, provision profiles, and more.

Apple went into great lengths to simplify the processes involved - for the most part its trivial and they guide you through every step. (alas, it wasn't always so; back in the day, code signing and other related processes were the cause of much pain among iPhone Developers ).

Nevertheless, whenever I come across something I haven't been familiar enough with, I can't help not 'wasting' time to learn it(how it works, why it works, etc). This practice has deprived me of many hours I could have spent elsewhere (working on other stuff, spending time with loved ones, whatever) but I just can't help it; I "need" to learn how things work.

So here is simplified, basics mostly, overview of those concepts, in case someone needs to get started with them.

The fundamental problems encryption solve are those of data integrity validation and identity authentication. That is to say, to verify that data(messages, anything) sent from Alice to Bob (Alice and Bob) can be verified by Bob that indeed came from Alice and that the data were not tempered with/modified in any way while they were in 'transit'. That's about it.

Encryption is the process of generating new data from the original data. The new data is usually unintelligible to anyone but the intended recipient. Decryption is the process of transforming that data back to the original data.

Those processes are facilitated by a cryptographic algorithm(a cipher). Mostly, this involves the use of a key(a number) which is used with the algorithm to perform the encryption and decryption. The same key is used for both encryption and decryption. With symmetric-key encryption, the encryption key has to be kept secret by both parties. If someone else gains access to the key, he can not only decrypt the data but also encrypt new data and send them to Bob and Bob would assume they came from Alice. That clearly is not desirable. Enter Public-Key Encryption.

Public Key Encryption(asymmetric encryption) involves a pair of keys. The public and the private key. The public key is published and is freely available. The private key is kept secret. Alice never reveals the private key. Ever.

The fundamental idea is that data encrypted using the public key can only be decrypted using the private key. Bob, who has access to the public key much like everyone else, can encrypt his message using Alice's public key, send it over to Alice and only Alice can decrypt it, for it is only one who has the private key.

PKE is computational expensive though and not always suitable for large amounts of data. Often enough, a hybrid approach is employed. PKE is used to send a symmetric key, which then can be used(since both parties will know that secret key) to encrypt additional data using symmetric encryption. Using a symmetric key to encrypt and decrypt data is far less computational expensive. SSL and other protocols rely on this hybrid approach.

It is also possible to encrypt a piece of data using a private key which can only be decrypted using the public key. Given that Alice shared her public key with anyone interested, that wouldn't make much sense if Alice was to send data to Bob encrypted with her private key. Anyone could read it

Well, it does make sense, thanks to digital signatures. A digital signature can be used to verify that data sent from Alice - encrypted or not - were not modified in any way by the time Bob received them. In other words, it validates the authenticity of the data. It deals with tampering and impersonation.

Alice will use a hashing algorithm to generate a signature out of the message she wishes to send to Bob. That signature will then be encrypted with her secret private key. Then, she will send both the data she wishes to send to bob and the encrypted signature she generated from that data. It will also send Bob information about the hashing algorithm Alice used to generate the signature of her message.

Bob will use Alice's public key to decrypt the signature. Then, he will use the same hashing algorithm to generate a signature from the message he received. If the signature matches the signature Alice provided him with, it means the message is authentic. That is so because only Alice knows the private key and only Alice could have encrypted the signature like that.
Unless Alice lost her private key, it is 'impossible' for Alice to deny that she signed the data she sent to Bob, or for anyone to 'sign' anything, send it over to Bob and claim she is Alice.

A hashing function converts data into a single value (often a big integer). Hash functions are fundamental in the design and implementation of some of the most important data structures.

There is one last issue that needs to be addressed. Confirming identities. Digital Certificates solve this problem.

A certificate is an electronic document that is used to identify an entity(individual, company, anything) and associate that entity with a unique public key. Your passport identifies you and associates bits of information with you (your name, etc).
Public Key cryptography uses certificates to address impersonation problems.

Much like one would go about obtaining a driving license, by providing the authorities with whatever information and credentials required, so that they can verify the identity of the applicant and then issue her the driving license, Certificate Authorities(CAs) serve a similar purpose.
They will get Alice's application for a certificate (which includes her public key and information about her), they will validate the information she provided is correct and indeed represent her, and then issue her a Digital Certificate.
In essence, the Digital Certificate binds a public key to an entity. They help prevent the use of fake public keys. So, the digital certificate contains the public key of the entity, its name and other information (key/value pairs, e.g name=Steve, organization=Apple, Inc.) It also includes the digital signature of the CA. It is that digital signature that allows the certificate to function as a verified and trusted certificate, by users who know and trust CA (in other words, have the CA's public key and know that that public key belongs to that CA) and trust the CA but do not know the entity identified by the certificate.

Apple is a Certificate Authority. Before deploying your iPhone application to a device, you need to obtain a certificate and a provision profile. So you prepare a Certificate Signing Request(CSR). This contains information about you. It is the information you want Apple to verify. When you create the CSR, the public and private keys pair is also created. The public keys is included in the CSR. The private key is never sent to Apple. The private key is used for signing your binary.
Apple will get your CSR, create a digital certificate based on it. Then, you need to create a provisioning profile. The provisioning profile holds application IDs, device IDs and certificates.

You will need to submit CSRs and install Digital Certificates if you need to deploy and distribute iPhone applications, use Apple iPhone Notifications and In-App purchases. Hopefully this helps understanding why those are needed and what they are about.

Saturday, 27 March 2010 11:01 am

on Apple's iPad launch : the Aftermath

The iPad was launched yesterday. What was, perhaps, the most hyped and anticipated product of this eon, finally became known as Steve Jobs held it proudly in his hands. These kind of products usually wind up being the recipients of all kinds of crazy expectations. Everyone wants the next-big-thing to do everything, better, in new radical ways and, if that is not enough, they expect even more in the end (in the case of Apple, that comes after Job's "one more thing" statement). All in all, most people are not pleased with the iPad. I am not one of those people. Here is my take on (some of) the 'issues' raised so far.

The name
'iPad' indeed feels wrong. I was expecting it to be called 'tablet' or 'Applet tablet' or something along those lines. Of course, I failed to consider the fact that this would not be a tablet, according to Apple at least. This is not a netbook either. In fact, this is a product that carves a new niche and defines it. So Apple didn't use tablet in the title. I remember when the first Macbook came out. People didn't like the name. They don't mind about it now - in fact they may even come to like it.

Multitasking
The iPad does not allow multiple apps to run at the same time. This made much sense on the iPhone, but would make little to no sense to a laptop or netbook. Well, again, this is neither of those. My gut feeling tells me the reason Apple chose to go with this is threefold.

The existing iPhone apps are built and executed in a way that just doesn't translate well to a multitasking environment. It is not impossible of course. Apple decided to play safe with this one.
The RAM on this thing would not allow for a multiple applications to run in parallel efficiently. Lets just say that Apple, again, decided to play safe with this one too.
Apple's vision for the iPad is very specific. A consumption device that does some things extremely well, one thing at a time.

Cameras
I would have loved it if iPad had a front-facing camera so that I could video chat with my brother. Well, actually, I never use video chat, but that need is valid for enough folks to make it an important omission. Apple has been keen on adding an iSight camera on just about every Mac product it has released. iMacs, Macbooks, the cinema displays, you name it. They love it when people video chat over iChat, use PhotoBooth to go silly and whatnot. What became apparent with the iPhone and even more apparent with the iPad is that Apple, presumably, has a very good set of reasons that led it to (at least for now) make it impossible (one way or another) to do so on this class of devices. It is likely that AT&T and other carriers are to blame here. Apple is giving up some features in exchange for others(better deals with the carriers?). Win some, lose some.

Adobe Flash support
Apple doesn't like Flash. It can't be more obvious than that. They could list a number of technical and semi-valid reasons as to why this is a bad thing, but none of that would matter. I personally couldn't care less about Flash support on Safari, but the vast majority of potential users would, especially the folks in the US where, I hear, Hulu has become the go-to site for all things entertainment there. Unless things go way south for Apple, I don't see it changing its stance on the subject.

On screen keyboard
When the iPhone came out, naysayers and pessimists sure had lots to say about the onscreen virtual keyboard. Nowadays though, people seem to actually prefer those kind of keyboards to the traditional physical ones, me included. Why waste device physical space, weight and looks for a 'real' keyboard, which is there even if you don't want it, when this new virtual keyboard works for you? I have been trying to type using both hands for the past few days. I can type now at least x2 many words/minute than I was able to do so in the past, when I was using just my thumb and I hope, expect, to get better at it. On the iPad, which features even bigger keys, things should be even better for me.

Books and magazines
I wanted an ebooks reader for quite some time now. I was hoping for an ebooks store tightly integrated to iTunes and the iTunes store, the ability to subscribe to magazines (Wired, Edge, ..) and have them delivered to my 'subscriptions inbox' ( with a nice badge indicating new subscriptions count; me and Stelios would sure love that ) and a reader that would provide all benefits PDF readers come with, but with even more thrown in. Well, it won't really work like that on the iPad, at least for now, but this iBooks application sure looks sweet and well done. Apparently, each magazine, newspaper or other content provider will come up with its own solution to the digital content challenge ( NYTimes app demoed was pretty impressive ), which is one way to do it. Apple is playing safe there, again. There is no subscriptions aggregation place/app, or anything like that. Wired will need to build its own app and same will be true for everyone else. I can't wait to see what they will come up with.

All in all, this is v1.0 of a new product that, again, occupies and defines a new category on its own. Recall v1.0 of OS X, the iMac, the iPod, or any other product, produced by any company. Most v1.0 products are there to establish a baseline. Evolution bless them with more feature in later releases. This will certainly be the case with the iPad too. I never needed a tablet device ( my MBP 17" is everything I would 'ever' need ), but I am so buying one for me and Dora ( and for my brother and Dimitris if they themselves wont get one ). Exciting times (ahead).

Thursday, 28 January 2010 8:14 pm

Ideas for iPhone applications

I thought of two ideas for iPhone applications yesterday and I thought I would share it with anyone interested in pursuing the tasks. I may do it myself if time and motivation allows it, but do feel free to try your luck with them. So here goes nothing.

Life-tracker

The main principle idea is that you could use your iphone to keep track of your life through time, specifically where you have been, what have you been doing and what your thoughts on any given date. The said application would be really simple to use. You launch it, two buttons will make it possible to record your existing location (geolocation coordinates) and/or record thoughts or, say, what it is that you are doing at the moment. You can do that as many times as you wish, whenever you wish. Sometime later, you can sync all that with a web-based service. You could access your life activities through that service ( what have been thinking a year ago this very day? where have I been last week when I was on vacation in London? you want that on a google map - there you go) and so on, so forth. A more or less trivial application to build.

Javascript driven native iPhone applications

This is a no brainer, in fact I wonder why someone ( Apple even ) hasn't thought of it yet. One can expose the iPhone functionality(framework facilities) through Javascript (Javascript objects), have a simple runtime application that 'all' it does is act as the VM/runtime for javascript code. 'Everyone' knows Javascript, everyone(?) likes Javascript, why not make it possible to build real (i.e not hosted on Safari, web-apps ), native applications using the language? A developer would still submit an iPhone application ( the Javascript VM/runtime, with the javascript files and resources in the bundle ) to Apple, Apple, nor the users, would be able to tell the difference. Hey presto, a gazillion apps flood the App store - most will be crappy ( the nature of things ) some will turn out to be gems. If I could make it possible for my brother and my fellow javascript gurus at work to build any app they want as easy as they build our web-apps, that would be kinda cool. Here is what it could look like:

var myButton = new UButton();
myButton.text = "Hello World";
myButton.addListener('click', function(event) 
{ 
alert('Your geolocation is:"+(new ULocation()).toString(); 
}));
thisWindow.containerView.addView(myButton);

or something.

Tuesday, 11 August 2009 10:30 pm