Amit Ranjan, Senior Consultant
Cryptography is the practice and study of techniques for secure communication in the presence of third parties (called adversaries) . When I got the opportunity to work on it, it was very difficult to understand the terminologies, equally mundane to remember algorithm names and very tough to design a solution using cryptography. It needed significant amount of time to spend at search engines, still it did not match with the understanding acquired by resolving production issues, Understanding existing designs and making others understand how does it ensure security.
Implementing cryptographic solution needs hands-on experience about the algorithms, APIs available for different programming languages, cryptographic concepts at implementation level whereas it can be designed with high level concepts. The typical list of the elements in a cryptographic solution goes like this symmetric/asymmetric cryptography, private key, public key, key length, hashing, digital certificate, digital signature, Certificate issuing authority, Hardware Security model, Software security model. Of course if we are implementing a solution, list may grow further but we will concentrate only on the elements which are necessary to design a solution. We will define each of these elements as and when it comes up in a solution for any specific problem.
Let’s start with the types of cryptographic algorithms i.e. symmetric and asymmetric. The basic difference between a symmetric and an asymmetric algorithm is symmetric algorithm needs a single key to encrypt/decrypt a data where as a pair of key (private key, public key) is used in asymmetric algorithm. Advance Encryption Standard (AES) is an example of symmetric algorithm which is approved by NIST whereas RSA (Ron Rivest, Adi Shamir and Leonard Adleman) is a well-known asymmetric algorithm.
Symmetric Algorithm
Asymmetric Algorithm
Without going into details it can be stated that the symmetric algorithms are fast but asymmetric algorithm are secure. So where do they fit, well when we want to communicate some data while maintaining its confidentiality we want the solution to be fast as well as secure. We can make the solution fast by using a symmetric algorithm for encrypting the data and asymmetric algorithm for encrypting the symmetric key used.
Let’s understand it in detail. When we generate a key pair using an asymmetric algorithm we get a private key which is a private property and a public key which can be shared to public. A data encrypted with the public key can only be decrypted with the corresponding private key. So we can fit these into a solution as if party ‘A’ wants to send data to the party ‘B’ and does not want an intruder to understand it, ‘B’ will generate a key pair using asymmetric algorithm and share the public key to ‘A’. ‘A’ will generate a symmetric key ‘S1’ encrypt it with the public key of ‘B’ to generate ‘encS1’ and send it to ‘B’, since it can only be decrypted by B's private key so it's confidentiality depends upon how safe the B's private key is. Now ‘A’ can use ‘S1’ to encrypt data and send it to ‘B’. ‘B’ will decrypt ‘encS1’ with its private key to get ‘S1’ which can be used to decrypt the data shared by ‘A’. Now any encrypted data coming from ‘A’ can be only be decrypted by ‘B’ since ‘B’s private key is the first in the chain of further decryption till we get actual data.
‘B’ generates asymmetric key pair, share public key to ‘A’ and keep private key safe
‘A’ generates symmetric key ‘S1’ and encrypt with the public key of ‘B’ to generate ‘encS1’ and share it with ‘B’
‘A’ encrypts the data with ‘S1’ and sends it to ‘B’
‘B’ decrypts ‘encS1’ with the private key to get ‘S1’ and decrypts the data sent by ‘A’
Random selection of keys (symmetric, asymmetric) at regular intervals further strengthens the security. We can generate some large number of asymmetric key pairs at the receiver’s end, private keys will be kept secure and corresponding public keys will be shared with the sending end, each time the sending end choose a new public key it has to communicate to the receiver to choose the corresponding private key to decrypt the symmetric key. Symmetric keys can be generated at intervals which can be as short as practically possible for secure communication.
The authenticity of a message from a sender is the sender's liability. Let’s understand this with an example if an organization sends a request to a bank to credit certain amount to the employee's account as salary, the organization should not be able to later deny having requested to credit different amount than the bank has credited, in which case it will become bank's responsibility for the mistake. Non-repudiation refers to a state of affairs where the maker of a statement should not be able to challenge the validity of it. To address non repudiation we need a fool proof solution. We can solve the problem of non-repudiation by signing the message with sender's private key which can be verified by the receiver with the corresponding digital certificate shared by the sender.
Let’s understand this in detail. A hash value of a message is unique and fixed size data which cannot be reversed back to get the original message. Different implementations of one algorithm generate the same hash value for same message. If we want to verify the integrity of a message we can generate the hash value at both the ends and compare to verify that the message has not been changed during transition.
When we encrypt the hash value of a message with the private key of the key pair procured through valid certifying authority it becomes the digital signature of the message which can be verified by anybody who have the corresponding public key in the form of a digital certificate. A digital certificate contains public key, details of the owner of that key and the digital signature of the certificate's content done by different Certificate Authority’s.
Typically there's a hierarchy of CAs certificate can be seen in a digital certificate which indicates that the certificate is procured by a CA which is one level up in the hierarchy. Digital Signatures are legally admissible in a Court of Law to prove that the message is generated by the party whose digital certificate can verify the digital signature. So if party 'A' want to send some data to party 'B' and if 'B' wants a way to hold 'A' liable for any data sent then 'B' can request 'A' to procure a digital certificate from a valid CA. 'A' will receive a pair of keys, private key will be kept secure whereas public key in the form of a digital certificate can be shared with 'B'. Now whenever 'A' sends some data it will sign it with the private key, 'B' can verify the digital signature using the certificate shared by 'A' and reject the data if the verification fail.
‘A’ generates the hash value of data, encrypts it with its private key to create the digital signature of the data and sends it along with the encrypted data to ‘B’
‘B’ decrypts the digital signature with the public key in the certificate shared by ‘A’ to get the hash value of the data at ‘A’
‘B again calculates the hash value of the decrypted data. If the hash value matches with the above value then accepts else rejects the data coming from ‘A’
Digital certificates are the most versatile entity in cryptography, we can use it for encryption, digital signature verification, SSL enablement, authentication, the basic thing to understand is that it contains a public key which is verified by legal entities called CA and there is an associated private key, so we can get more creative and use digital certificates extensively across the solution.
Digital certificates if procured through a CA it will incur time and money so there is a concept of self-signed certificates. A self-signed certificate is an identity certificate that is signed by the same entity whose identity it certifies, what it means is issuer of the certificate itself is using it. Self-signed certificates are as secure as any other certificate except the fact that there are some risks involved in using it.
In a cryptographic solution the security of the private key are most important. As long as we are protecting the keys involved in a cryptographic solution and we have provision to update the key size and algorithms involved according to some known industry’s standard like FIPS 140-2 our solution is secure. There are two approaches for securing private keys, Software Security Model and Hardware Security Model.
In software security model the private key is kept in file, database, environment variable or some other software component. Software security model is relatively less secure as whoever has access to the software component which stores the key can get hold of that. So there will be at least one person who can access the key which will prove to be a single point of failure. We can break and distribute the private key across multiple software components with different owners which will be relatively more secure as it may need more personnel to be compromised to steal the key, but this will make the solution design more complicated to use, update or revoke a private key. The private key broken into multiple pieces needs to be assembled together in the memory for processing; this may still prove to be a single point of failure if somebody can compromise the memory of processing computer.
An HSM (Hardware Security Model) can be a savior for ensuring the security of a private key. An HSM is a physical computing device with very minimal interfaces and minimal set of commands that can be executed on it. These commands can only be used to configure it, there cannot be any command which will give us the key configured in it. A private key can be encrypted using the HSM master key and kept in a software component like database. To use this private we need to decrypt it using HSM's master key, when HSM identifies that the key provided to it for decryption is a private key it does not give it back in decrypted format to the requestor instead it provides a handle to it which can be used for any processing which needs that private key. HSM servers are designed to be completely hack proof even if somebody gets physical access to it. This ensures a fool proof security of keys as the guardian of the key can never be compromised.
The strength of a cryptographic solution lies in the computational power required to break its keys. A good design should always be flexible enough to incorporate any changes in the key strength and algorithms.
