Knowledge is NOT freedom!

What the hell is this so called "knowledge"? I searched around the net. All I'm finding is it is a skill that gathered from previous experience.

If that is the case, what is the advantage of knowledge? and what is the disadvantage? Hmm? Is there a disadvantage ? Oh yeah!

Here is how I look at it:
If you are in to technology, you must have came across the term "thinking out of the box". It is often heard when people hit a brand new problem with some similarities to an exiting solution. Everyone tries to think hard, and eventually someone will receive that "great job".

What exactly is the "box" in "thinking out of the box" ? What is inside?

The box is our knowledge! Our past experience creates a pseudo shell around us. We are proud of that shell it protects us and we protect it. Every moment we try hard to maintain it, make it harder and wider - the more the merrier!

What we don't realize is that here is an escape velocity associated with the shell. In other words it is very hard for us to understand/accept something that we have never come across earlier. Our shell blocks us from brand new ideas, unheard concepts, complex equations etc. We often has to go thru a painful process of correcting something that we learned in the last to adapt something new! - is it really useful ? I don't think so!

Here is another problem: Learning is like a ladder. You have to go thru every or most of the steps that every N-1 people in the world has gone thru several times. We are wasting 99% of the time learning things that are already known to may people. Take me for instance - an average person with X units of brain power. What is the probability of I inventing something? - answer is apparent. As the generations pass by, we have more and more new things to learn, which means less and less time for true innovation!

 
Last but not the least: No one knows how much they know, but everyone knows they know something. What does that mean? - unpredictability and  uncertainty.

To conclude, I feel for this species of humans, knowledge is a limitation rather than advantage!

Ideally:

• There shouldn't be a learning phase
• There must be quick a way to transfer the knowledge from one person to the other
• Humans should be able to understand a completely new object

Quality of art ?

"Quality of art is the quantity of original expressions it delivers" - Well, thats how I think one should evaluate a piece of art.

Every art comprise of a deep feeling that cannot be expressed with spoken languages.

A true artist tries his best to express that feeling at its fullest thru his work.

Look at the sky thru a piece of glass. If the glass is clear, the view will be better. Dirty glass blocks the view. Sky is the point of interest, not the glass. If the glass is transparent, the viewers will not even realize that they are looking thru the glass.

Art is like the piece of glass. Artist is the one who makes the glass. The more skilled he is the clearer the glass will be. Viewers will not see the art or the artist, but they will experience the original feeling depicted.

What is missing in today's mobile applications?

Mobile applications and Location Based Services (LBS) together have a whole new tech world to reveal. But they have been waiting for each other to come up. Besides, they both are waiting for the infrastructure to come up. LBS for instance, demand the handset to have an attached GPS device for geo-coding.

Can LBS work without GPS co-ordinates? Well, that depends on the type of application. If you are looking at a street navigator, yes you need a GPS. But plenty other common LBS applications such as payments, reservation, cataloging, you don’t really need the GPS. Look at your own day-to-day activities – most of the time you know where to go and what to do or buy. You don’t really need to know the exact locations of your friends. I am not saying these are unnecessary features, but you and everyone else should not have to buy an expensive handset to use these features.

Another important difference about mobile applications is its usefulness. Working on mobile handset will never be as friendly as a desktop or a laptop. That is definitely not because of the design of the application front-end. Handset cannot be larger than a limit. The screen is small, so is the keypad. Again when you sit with your lap/desk top, you are 200% more relaxed than when you are on handset. When you work on mobile, you have very specific need such as check your email, send SMS etc. The bottom line is you don’t want to spend a lot of time on it. So your mobile application should be designed in such a way that it is simple, useful and serves the purpose. For instance I have Acrobat reader, MSWord reader etc on my Nokia 6682 handset. But I have never used it!! A useful mobile application must be a personal assistant, not just another application.

I had a meeting with one of the oldest VC firms in the valley last year. He says he looked at over 200 mobile applications in 2006 and sadly none of them are really useful for common users.

In my opinion, the real power of mobile application is exposed only when:

1) It can represent the owner himself. The owner should be able to use all his existing ID’s like his credit cards, membership cards etc seamlessly
2) It is secure – at least like online transactions (PKI)
3) It should be multi-purpose and portable. A browser-like experience is preferred where it’sfront-end can reflect the server/service itself
4) It is capable of accessing Location Based Services (LBS)
5) It require minimum user interaction

The challenges are:
1) How to securely store and seamlessly retrieve owner’s personal information
2) How to locate and authenticate a LBS server
3) How to make the application portable like a browser
4) How to make it run on common handsets

Besides these there are server side challenges as well.
How to host a cheap non-GPS based LBS server

Not so easy – I know. But there are solutions. Fujitsu is one of the pioneers who entered the space. Companies like EzCheckout are coming up with inexpensive solutions. One of the major slow-down factors is that no one wants to take a major step and invest in this area.

Public Key Infrastructure (PKI) based security - Espresso!

Why (the hell) Am I Doing This ?
I was not new to PKI. But I never cared to know “what really happens inside” part of it. The best thing about PKI libraries is that it hides its rocket science form the programmer. So I was totally happy with such libraries. Ipso facto, I ended up taking the short cut by either following the steps provided or asking one of those FAQs.
Ever since I started working on MIDLets, data/application security had become an irritating reality that I must deal with. Unlike other software development, MIDLet development requires application signing and other security aspects in almost every step. After got involved a little bit in MIDLet development community, I had the privilege to answer some of FAQs. Then I thought may be it would be helpful if I put together a blog explaining some of the practical aspects of PKI security.

Disclaimer
The scope of PKI is way beyond this article. This blog has been written for readers with some security background. The main intention here is to present a big picture and highlight some key points rather than drilling down to specifics. As a result of my effort to make it simple, you may find it a little “wordy” if you are already familiar with PKI concepts. If you have suggestions or comments, please post it here or send it in my way.


The "Threat"
Every one who transmits data is exposed to some kind of data leak threat. It can be as simple as someone listening to your secret conversation to the complex cell phone frequency tapping. The Internet, being the most widely used data media, has become the most attack prone zone.

The “History”
Way back in time, the only possible way to secure the data-in-transit was to use a dedicated line. Leased lines are isolated, closed circuits and are totally secure. This is very similar to connecting two machines back-to-back – more like a media level security. This method works pretty well, but as you can imagine, it is very expensive and practically impossible to scale. The IP world where all packets share the same media, demands a different kind of security.

The “Requirements”
Any system that can accomplish the following can be qualified as an Internet security solution

1) Must be able to make sure that the data comes/goes from/to the right party
2) Only the indented recipient must be able to read the data
3) Must be able to protect (detect at least) data alteration in transit

The “New security”
PKI was introduced as an inexpensive substitute for leased line based security approach. PKI offers content level security. It is independent of the media or the data itself. It brings in new concepts like “digital trust” “authentication” etc (explained later). One of the hardest to stop attack is packet sniffing and man-in-the-middle attacks. In both these cases the attacker either intercepts or monitors network packets and examines their contents. This is very similar to someone standing outside your house with a powerful microphone, listening to all your private conversations. As you can imagine, the easiest way to protect yourself form this attack is to speak in a language only you can understand. Or, encrypt your conversation. “Encryption”, that is the back-bone of PKI security. In the digital world, when the data is in process’s memory, it is assumed safe. The digital security starts when the data leaves memory to a media – such as network or storage. PKI uses strong encryption mechanisms so that it is practically impossible for the attacker to decrypt the data-in-transit.

Summary so far
PKI protects data-in-transit by encrypting it.



The “Challenge”
Encryption can be as simple as adding a constant number to all bytes in the data to highly complex mathematical operations. No matter what method you use, there are 3 major components in encryption.
1) The encryption algorithm
2) The encryption key
3) The data itself
Apparently, stronger the encryption algorithm, better the security is. Bigger the encryption key, better the security is. But the down side is both demands high processing power. So the challenge is to use the right algorithm with an optimal key size. Decades ago mathematicians (human beings) developed several strong encryption algorithms - the good news is we still use them!!

"The best encryption is the one which can never be decrypted"
-me



The “Encrypted communication”
Following is the essence of PKI based communication. When A wants to send data to B,
1) A encrypts the data with a secret key
2) A “somehow” shares the secret key with B
3) B uses the shared secret key to decrypts the data

The “somehow” is the next challenge. How do you securely share the secret key? If we can share the key why don’t we use the same mechanism to share the data itself? Well, it doesn’t work that way! One way to do is to use another media (say telephone) - but that breaks the continuity of the data flow. We need a sharing method which works more “smoothly”. PKI has solutions for this problem as well. Before proceeding further I should introduce an important PKI terminology.

The “Key Pairs”

Like I said the PKI internals are real mathematical rocket science. Fortunately that’s not a requirement here. Now pay attention. The simplest way to look at it is this. There are two numbers, two large... too large to memorize. Those numbers are mathematically related in a single unique way. It is relatively easy to generate such a pair. But it is practically impossible to find the pairing number when you have only one available - because it is computationally extremely heavy. In PKI world, these numbers are known as the key pairs. One of them is called the private key and the other one the public key. It doesn't really matter which is which.

Sharing the Secret
Utilizing this unique mathematical relation between the keys in the key pair, mathematicians developed special encryption algorithms which can do a one way encryption. Meaning - if you encrypt the data using one of these keys, you absolutely require the other PKI key to decrypt it.

The core of the "secret" in PKI is the isolation of the encryption key from the decryption key

Typically, private keys are stored in a secret location and the public key is published to the world. Anyone who wishes to send PKI encrypted data to a target uses the target’s public key to encrypt the data. Now the data can be decrypted only with the private key of the target. (Even the encrypting party cannot decrypt it). Given that it is practically impossible to calculate the pair key, it is assumed that the data is secure. This type of "one way" encryption is known as "asymmetric encryption". Popular algorithms used for this are RSA, DSA etc.

If you read upon PKI basics on the Internet you will definitely come across two people "Alice" and "Bob" (A and B). They've been tortured almost every day, ever since people started to learn PKI concepts :)

Summary so far
PKI protects data by encrypting it. PKI protects the encryption keys by using asymmetric encryption algorithms where the encryption key itself doesn’t have to be shared at all.

The "Trust"
So far I've been trying to introduce how the data is protected by encrypting it and how the encrypted data is shared. Now I should move to the next concept - the trust. The idea is simple, when you have a secret, you will share it only with some whom you really trust. When it comes to PKI, it is still simple, but not very straight forward. The reason being, you are communicating with someone you probably never known before. So you need a third person whom you always trust, who can introduce the second party to you. So there are two sub categories in this.
1) An authorized party (like passport office)
2) A friend whom you trust in real life
Both methods are popular in PKI world. The first method is known as "X509 standard" and the second one is the "web of trust" (aka Pretty Good Privacy - PGP). In X509, there is a trusted root CA (Certificate Authority) (like Verisign, RSA, Thawte etc) whom everyone trusts. In PGP, you pick your own trusted parties.

Trusting the Trust
Back to the basics: everything has to be mathematics modeled to run on computers. How do you mathematically trust? PKI has the answer. Say you trust your friend (in real life). He gives his public key to you in a disk or so and you save it. When you receive encrypted data from him, you can “verify” it by trying to decrypt the data with his public key. If the decryption is successful, it is assures that the data came from your friend and you can trust it. The same way your friend can distribute his public key to everyone thus everyone can verify the legitimacy of the data using his public key. The reverse works as well. This is the base of PKI’s mathematical trust.

The “Certificate”
To make it more appealing, the public keys are distributed as “certificates”. Besides the public key, it contains the following important fields.
1) The issuer’s public key
2) Hash(SHA/MD5) of subject’s public key, encrypted with issuer’s private key (the signature)
3) Date of issue and the expiry,
4) Algorithms used for hashing and encryption (MD5/RSA)

Think about it as a set of key-value pairs. Please note that you can issue a certificate for yourself (self-signed) or you can have a second person (like a CA) issue a certificate for you. There is a syntax in which certificate data should be formatted. X509 and PGP has different syntax. Certificate syntax itself is typically written and available in ASN.1 format.
If you receive a certificate from someone, the first thing you do would be to verify it. The verification process typically involves the following.

1) Whether the certificate is syntactically correct
2) Whether the date of issue and expiry are currently valid
3) Whether you trust the party who issued the certificate
4) Whether the signature is valid

1 and 2 are straightforward. But how do you know whether/if you trust the issuer? Well, you store all trusted issuers. In other words you will have a “certificate store”. If the incoming party’s issuer’s public key is in your trusted certificate store, you trust it.

Side note: Once you fill all the required fields in the right ASN syntax, you get a block of data, probably not very human readable. This will typically will be converted to a Base64(PEM) format, which (still can’t make sense of contents) is readable.

There are a bunch of standard formats (PKCSxx) to store and transfer certificates and private keys. Some times these are confusing, but hey.. “my way or highway”!. As a developer sometimes you need to deal with this, as some software accept or don’t accept some format or the other. OpenSSL is one of the most popular tools to generate and convert formats. Take a look at http://www.rsa.com/rsalabs/node.asp?id=2124 for further PKCSxx details.

Digital signature and signature verification
You must have come across this term hundred of times. Digital signature is the PKI way to ensure the integrity of the data. It allows the receiver of the data to check whether the data contents were altered since it was signed. This process works as follows.
1) Sender calculates the hash value of the data
2) Sender encrypts the hash value with his private key
3) Sender sends the original data along with the encrypted hash to the receiver
4) Sender can also include his public key
5) Recipient authenticates (explained below) sender’s public key
6) Recipient uses sender’s public key to decrypt the hash
7) Recipient uses the same algorithm and calculates the data’s hash value
If hash value in (7) matches with the one in included in the message from (3) the message is OK. If any of these steps fail, the data will not be trusted

The “Chain of trust”
PKI is based on simple concepts, but very powerful features have been derived from it. The chain of trust is one of them. Chain of trust is the simple “Transitive Property” of trust: if A trust B and B trusts C then A trusts C. In PKI world, it works like this. The root CA generates a self-signed certificate for itself. Then the root CA issues a certificate to another intermediate-CA and intermediate-CA uses that certificate to issue more certificates – and this chain can go on. Note that you always trust the root CA not the intermediate one. Also note that the intermediate CA does NOT have a self-signed certificate. In other words, ONLY root CA’s can have self-signed certificate. When you receive a chain of certificate, you will verify that the chain winds up all the way to a root CA that you trust. This way the root CA can have distributor chains and keep the trust unchanged.

The PKI overhead and the workaround
Encryption is a complicated math procedure and it consumes lots of cpu cycles. As the key size increases it becomes even heavier. PKI keys (public/private) are typically 1024 bits so it is not efficient to use them for every encryption. So the solution is to use a shorter session key (32 or 64 bit) and exchange this key one time using the PKI keys.

Some Protocols Built Over PKI
Several different protocols have been built on top of PKI. I would like to give an overview of two of them - TLS and S/MIME. The reason why I picked those is because they are two important, but different ways using PKI for different purposes. TLS is a generic term for connection based security. It is used in HTTP/S, SSH, SMTP, LDAP etc. SMIME is connectionless. It is used in MIME – which is a data format (not a n/w protocol)

Typical TLS protocol flow is like this:
1) A and B are connected over standard unencrypted network connection
2) A sends StartTLS request to B over existing connection
3) A and B exchanges certificates (typically B sends first)
4) A and B verifies certificates against their local certificate store
5) A and B exchanges the session key and encryption algorithm
6) A and B uses the session key for further communication
As you can see after step 6, every bit of data passes thru the connection will be encrypted. From there on it will be called a “TLS connection”. Usually there is no going back from TLS to un-encrypted mode.

Unlike TLS, SMIME is a connection-less, data-based protocol. This is useful when you are communicating with someone whom you already know. It works as follows.
1) A generates a short key for encryption
2) A encrypts the data with that key
3) A encrypts the key with B’s public key
4) A packs the data from step 2, 3 and together to form an encrypted message
5) A signs the encrypted message with A’s private key to form a signed/encrypted message
6) A sends the message over unencrypted connection
7) B verifies the message signature against its key store
8) B uses its private key to decrypt the encryption key
9) B uses the decrypted key from step(8) to decrypt the message body


For further reading:

http://luca.ntop.org/Teaching/Appunti/asn1.html
http://www.x5.net/faqs/crypto/q166.html
http://people.cs.uchicago.edu/~cbarnard/pgptalk/index.html
http://technet.microsoft.com/en-us/library/aa995740.aspx