Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Endpoint

12/30/2015
10:30 AM
Yehuda Lindell
Yehuda Lindell
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

The Changing Face Of Encryption: What You Need To Know Now

Encryption today is now an absolute must and the fact that it is difficult does not change the fact that you have to use it.

Encryption is a time-tested tool that can severely hinder attackers in their goal to steal confidential user and customer data, trade secrets, and more. However, many – if not most – organizations do not encrypt their data. (Just one very recent example is TalkTalk.)

Historically, encryption has mainly been deployed to protect data in transit, and many organizations are slow in shifting to also using it to protect data at rest. This is most likely due to the fact that organizations feel that their internal private network is safe. This is a real concern today since the massive theft of data we have seen over the past few years has actually been from data at rest.

When an organization wishes to deploy encryption, it typically faces two main challenges: how to encrypt, and how to protect the secret keys. It is an unfortunate fact that non-experts very often use encryption incorrectly. Unlike most other software engineering tasks, a badly deployed encryption method cannot be detected by quality assurance. Thus, a software engineer really has no way of testing what has been implemented.

To make things worse, the Internet is full of code examples and articles about how to encrypt that are misleading and incorrect. There is no real way to fix this other than becoming a cryptographer oneself, and this is an unrealistic solution, especially since, as we have mentioned, studying from the Internet is not necessarily reliable enough.

Nevertheless, the following five tips, based on current up-to-date best practices, can help:

Encryption TIP 1: Always use standard algorithms and never make up your own. As a rule of thumb, use AES (Advanced Encryption Standard) for symmetric encryption and RSA for asymmetric encryption.

Encryption TIP 2: Always use key sizes as mandated by standards bodies like NIST. As a rule of thumb, use AES-128 and RSA-2048 at least.

Encryption TIP 3: By default, use authenticated encryption modes of operation for AES (AES-GCM or AES-CCM) and use PCKS#11 v2.1 padding for RSA. When hash functions are needed (e.g., for signing), use SHA256 by default.

Encryption TIP 4: Make sure that your code is agile so that algorithms, key sizes, and modes of encryption can be easily replaced. The reality of encryption is that you will have to update your code over the years.

Encryption Tip 5: Given the difficulty of getting all of the above right, my best recommendation is to use a high-level API to encrypt (e.g., the EVP library in OpenSSL), or buy a solution.

Where do you store the secret keys?

In the example of application-layer database encryption, you could keep the key on the database with the encrypted data -- and this is often what is done. However, this means that an attacker will be able to steal the keys along with the encrypted data, and decrypt everything later. So, not much is actually gained by encrypting to start with.

Another option is to store the keys on the application server. However, this involves key synchronization issues; multiple application servers access the same database and so all need to have the same keys. More importantly, application servers are often among the most vulnerable places in your network. Since the application servers have permissions to read the database, an attacker breaching an application server can steal the keys and run a SELECT * to read the entire database. Once again, everything can then be decrypted later.

Attempts to hide the key via obfuscation and using multiple layers of protection on the application server are good ideas, but typically not sufficient against today’s sophisticated attackers.

The best option is therefore to allocate a dedicated hardened server that holds all secret keys and carries out all the operations for the application servers without ever handing over the keys. When configured correctly, this can be a good solution. However, you have to make sure that you deal with availability issues, and that only authorized application servers have access. It’s also critical that the dedicated server be very well-protected. This makes deploying such a solution rather challenging -- but still possible. Alternatively, as above, there are key protection solutions offered on the market that can be used.

In summary, encryption is now an absolute must, and the fact that it is difficult does not change the fact that you have to use it. The cost of a breach is too great and the chance of it occurring too high to ignore the problem. As a result, you must either develop sufficient in-house expertise, pay expert consultants to provide clear instructions for your developers, or buy off-the-shelf solutions. All of these options are possible, and choosing the right one depends on the needs of your organization and the investment that you wish to make.

Yehuda Lindell is a professor in the Department of Computer Science at Bar-Ilan University. Prior to Bar-Ilan in 2004, he was a Raviv Postdoctoral fellow in the Cryptographic Research Group at the IBM Thomas J. Watson Research Center. He received his Ph.D. in 2002 from the ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
RyanSepe
50%
50%
RyanSepe,
User Rank: Ninja
12/31/2015 | 8:53:47 AM
Encryption TIP 1
Encryption tip 1 is pivotal. The idea behind encryption is to protect the file integrity but also remember that availability of the data is another monumental piece of the CIA triad. If you encrypt data so that only a small subset can decrypt it, then you are going to run into a large level of effort and most likely reverting to a standard encryption methodology anyway.
SteveW415
50%
50%
SteveW415,
User Rank: Apprentice
12/31/2015 | 2:52:51 PM
"...dedicated hardened server that holds all secret keys." = Hardware Security Module
Worth noting that building a "dedicated hardened server that holds all secret keys" is nontrivial. A hardware security module (HSM) is that server. Simply put an HSM is a vault for keys with, if you need it, extreme access controls. See https://en.wikipedia.org/wiki/Hardware_security_module
DaveS074
50%
50%
DaveS074,
User Rank: Apprentice
1/5/2016 | 5:19:21 PM
Examples...
The article mentions the amount of poor examples. How about some examples that the reader could go to that follow the articles tips. Or perhaps a follow-up piece on the best books or websites out there.
trs2016
50%
50%
trs2016,
User Rank: Apprentice
1/11/2016 | 5:32:47 PM
Re: The need for encryption
The author correctly implies that strong data encryption is a double edged sword... Done correctly, it is the only proven way of securing data, even in the case where a breach occurs and the data is harvested... the bad guys won't be able to do anything with properly encrypted data. But given the expertise required, it is far too easy for the people building apps to either not encrypt anything, or to chose the wrong encryption method/strength, make an authentication mistake, or improperly generate, apply or store the Keys used for encryption. Many times the developer will include what they feel is strong encryption, only to discover much later that their customer data has been exposed the whole time. What is needed is encryption-as-service offered by trusted vendors who are proven crypto experts. That way developers can focus on contiuning to innovate, and simply plug in a RESTful API call to encrypt the data their apps are gathering and processing. Similar add-on services have been available for things such as credit card payment processing, subscription management, user authentication, etc. Today, it would be foolish for a developer to build any of those services from scratch, simply because there are readily available, cost effective (if not free), and easy to implement solutions available. The market needs the same for application encryption services.
10 Ways to Keep a Rogue RasPi From Wrecking Your Network
Curtis Franklin Jr., Senior Editor at Dark Reading,  7/10/2019
The Security of Cloud Applications
Hillel Solow, CTO and Co-founder, Protego,  7/11/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-0234
PUBLISHED: 2019-07-15
A Reflected Cross-site Scripting (XSS) vulnerability exists in Apache Roller. Roller's Math Comment Authenticator did not property sanitize user input and could be exploited to perform Reflected Cross Site Scripting (XSS). The mitigation for this vulnerability is to upgrade to the latest version of ...
CVE-2018-7838
PUBLISHED: 2019-07-15
A CWE-119 Buffer Errors vulnerability exists in Modicon M580 CPU - BMEP582040, all versions before V2.90, and Modicon Ethernet Module BMENOC0301, all versions before V2.16, which could cause denial of service on the FTP service of the controller or the Ethernet BMENOC module when it receives a FTP C...
CVE-2019-6822
PUBLISHED: 2019-07-15
A Use After Free: CWE-416 vulnerability exists in Zelio Soft 2, V5.2 and earlier, which could cause remote code execution when opening a specially crafted Zelio Soft 2 project file.
CVE-2019-6823
PUBLISHED: 2019-07-15
A CWE-94: Code Injection vulnerability exists in ProClima (all versions prior to version 8.0.0) which could allow an unauthenticated, remote attacker to execute arbitrary code on the targeted system in all versions of ProClima prior to version 8.0.0.
CVE-2019-6824
PUBLISHED: 2019-07-15
A CWE-119: Buffer Errors vulnerability exists in ProClima (all versions prior to version 8.0.0) which allows an unauthenticated, remote attacker to execute arbitrary code on the targeted system in all versions of ProClima prior to version 8.0.0.