The Buzzwords

How often do you hear statements like “The traffic between the client and the database server is protected with TLS protocol, so I absolutely do not worry about the privacy of the data being transferred.”? Or, “Our password manager uses AES algorithm to encrypt password database – no one has succeeded in breaking AES yet”. TLS, SSL, SSH, PKI, AES, MAC, 3DES… It is believed that if a system utilizes some popular security technology named in good-looking and incomprehensible way, such system must be unbreakable by default.

In his “Nineteen Eighty-Four” novel, George Orwell aptly described this problem by the example of Newspeak language. Shortenings and abbreviations make us lose the real meaning of terms. Psychologists say that it is common for people to trust abbreviations more than the equivalent “expanded” phrases.

In the process of development of a system it is absolutely necessary to clearly understand the features provided by the chosen security technology. Good-looking name or just a buzz in press must not have an influence on your choice. The developer needs to know all about the technology – the way it works, the provided protection level, requirements for the operational environment, and especially the shortcomings of the technology. The lack of such knowledge can easily destroy the gains of the use of the technology down to the zero.

In future posts I will concern popular information protection technologies and try to reveal the hidden meanings of opaque buzzwords.

Don't hide your keys in the flower pot

“Encryption” word sounds like a spell for many people. “If my data is encrypted, no one can read it”. Thinking that way is a fatal flaw. No one can read it if the key is in safe place.

Many people believe that encryption itself guarantees the complete protection of the data. They say: “the data that is used by our application is encrypted with industry-standard AES algorithm with 256 bit key. Recent research show that in order to decrypt such data a hacker needs to spend a transcendental amount of time, and that’s why our customers should not worry about their secrets”.

It is not completely so.

Modern cryptosystems are designed in the way that the security of the system is delegated to the secret key being used. Although the internals of the underlying cryptographic algorithms are well known, the algorithms guarantee that it is impossible for an eavesdropper to decrypt the encrypted data unless he knows the secret key (to be exact, it is possible for him to decrypt the data, but only by trying all the possible keys one by one; such a big number of keys to try leads to the “transcendental amount of time” referenced by the people from the paragraph above).

So what's the obvious consequence? A hacker will do his best to avoid checking all the keys. In particular, he will try to get the key or some information about the key by other means. That’s why a lack of care about preserving the secrecy of the secret key can lead to a compromise of the entire system. And neither bit of 256 of AES key will help you.

We often face with situations where a secret key is simply hard-coded into the application’s source code. Naturally, such an approach is not suitable. Leaving aside the fact that different data are encrypted with the same key in this case, the key itself is easily accessible to the hacker. He just has to browse the application’s binary code and to extract all the constant values from it. An intermediate hacker will spent no more than five minutes to get the key.

Avoid hard-coding the secret key into the application. If your application needs to encrypt user-specific data, ask user to provide a password and then use this password to generate a strong secret key. To decrypt the data, ask user for a password and use the same procedure to obtain the decryption key. The secret key in this case is nowhere stored in explicit form (except the user’s head), and this fact seriously complicates retrieving it by a hacker.

If due to the certain reasons it is not possible to use password-based secret key generation approach, secret key protection should be implemented in the other ways. In particular, a task of key protection can be delegated to built-in functionality of an operating system. Windows provides several ways for secure storing secret data, such as DPAPI (Data Protection API), LSA, protected registry sections. Use these functions if you need to store a secret key inside an operating system. They have been built by gurus in the field of information security and provide much greater protection than the one you will be able to implement yourself. Besides, they are ready-to-use – and aren’t yours?

Even if OS functionality is not available for you (such cases are rare, but nevertheless possible), never store a secret key in plain form. Instead, generate it on the fly using complex and incomprehensible functions. Of course, this will not stop an inquisitive hacker (he will just use other instruments, such as debugger, in this case), but will prevent the secret key from being disclosed by script kiddies and beginner hackers.

The conclusion. The strongest cryptographic algorithm is useless if you do not care about the proper protection of the secret key. Don't hide your keys in the flower pot.

The general principle of information security

Implementation of any security-related function in any project should be done according to the following principle: the system is secure if the cost of hacking it is greater than the benefits of the result of the hacking.

The amendment. And the cost of implementing such function for the developer is cheaper than the worst consequences of the disclosure of secured information.

There’s no sense in building a multi-level data protection system if the data being protected is a high scores file of a computer game (unless it’s good old Digger game, of course ;) ). It is unwise to use 56 bit DES keys to protect the personal data of bank customers.

Any protection should be adequate to the data it protects.

Intro

Good evening,

My name is Innokentiy Ivanov, I am the manager of EldoS SecureBlackbox product – a comprehensive library of security-related software components. For six years we helped thousands of our customers all over the world to successfully integrate security features into their software products.

Unfortunately, in our work we faced with quite an unpleasant fact. It turned out that the heads of many companies and separate software projects have a kind of superficial understanding of data protection and information security problems. In particular, they suppose that adding third-party security components is enough to make their product secure. They delegate the task of implementing security features to the ordinary programmers, in the belief that this task is no more complex than any other basic subtask of the project. They are wrong. Integrating security features to a project requires a good understanding of this task and certain level of skills in information security field. The developer responsible for adding security to the project should clearly understand what exactly security problems he has to solve, and which ways of solving them are the optimal ones. If the person responsible for security in your project does not have such skills, you have a chance to get the illusion of security.

The purpose of this blog is the consideration of the most typical mistakes and misconceptions related to integration of security features to software products. I hope it will be useful to the managers of the products containing security modules, as well as to the developers responsible for implementing those modules in robust and safe way.

So, let's start building safe and secure world.