Keeping the Key Safe -PKI

Many software systems today are strongly encrypted and there are various standards of encryption like AES, SHA and so on that makes the encryption so strong that it takes humongous computing power and time to crack them. Suffice to say that it is near to impossible.

However, we always see that some data was hacked here and some hacked there on a routine basis and sometimes gives the feel that no matter whatever is the technological progress, hacking is inevitable. This is partly true because of the human factor involved here.

Let me give an example, the most popular way of encrypting software systems is called asymmetric Public Key cryptography. This is basically achieved by generating a pair of asymmetric key(s). One is called the Public Key and the other is called the Private key.

When 2 software systems talk, the party that wants to accept messages will publish a public Key to everyone so that they can encrypt their message and send it to them. Then to decry pt the message, the recipient will have to use the Private Key.

This is conceptually explained be the below figure as communication between Alice and Bob as explained in greater detail here:

The process begins by having the two parties, Alice and Bob agree on an arbitrary starting colour that does not need to be kept secret (but should be different every time); in this example the colour is yellow. Each of them selects a secret colour that they keep to themselves. In this case, orange and blue-green. The crucial part of the process is that Alice and Bob now mix their secret colour together with their mutually shared colour, resulting in orange-tan and light-blue mixtures respectively, then publicly exchange the two mixed colours. Finally, each of the two mix together the colour they received from the partner with their own private colour. The result is a final colour mixture yellow-brown that is identical to the partner’s colour mixture.

If a third party listened to the exchange, it would be computationally difficult for them to determine the secret colours. In fact, when using large numbers rather than colours, this action is computationally expensive for modern supercomputers to do in a reasonable amount of time.

OK does this sound secure, yes, it is but the system is as secure as how safely you can store the secret colour.

While the public key (Yellow Colour) is distributed via a certificate authority, the private key is always stored in the desktops of developers and /or server administrators who need to develop, test and release the code to production.

This private key is usually stored as a key store file of P12 file format or a PEM file, depending on the Encryption method chosen, certificate authority and so on and so forth. This is the weak link in this overall encryption scheme, that allows hackers to get into systems. Careless handling, misplacement and not having proper controls in handling of this file can result in data leakages due to malefic intent.

All that the thief must do is locate the private key (the key store file), use the public key that is already been published and then look around there will be enough API publication available in how to write a program to steal the data from the so far secure system.

So that is it folks, the point here is it is back to legislation, processes and rules enforcement of all people handling sensitive data and encryption keys that can make things secure not the fact that something has been encrypted and hence it is safe forever.

After all, if you lock the door and keep the key under the mat, how long before the thief will find out where it is?

 

reference(s):

https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange