Encryption of Data at rest [moved]

[lvca]

I would like to use OrientDB for a healthcare application in the U.S. One of the requirements is that the data be encrypted at rest. This could probably be done through writing drivers for a particular OS. We are currently using MySQL and have a third party driver to accomplish encryption at rest. It would be great if OrientDB had a built in capability to do this.

[lvca]

We already support SSL connections

[mandrachek]

@lvca this should probably be re-opened. This is not about encryption-on-the-wire (SSL), but rather storage encryption for data at rest. (e.g., on disk, or perhaps even in memory). See the mongodb docs @ http://docs.mongodb.org/manual/core/security-introduction/ - "To encrypt document or field level data, write custom encryption and decryption routines or use a commercial solutions such as the Vormetric Data Security Platform." I think that's more or less what this particular ticket is after.

[edwardkay]

@lvca I agree with @mandrachek - this issue should probably be reopened.

We're using Baasbox (http://www.baasbox.com/), which incorporates OrientDB, on a project. The ISMS requirements from our client stipulate that data are encrypted at rest.

This is different from either encryption on the wire (SSL) or filesystem encryption. See http://www.teamshatter.com/topics/general/team-shatter-exclusive/encrypting-data-at-rest/ for some further reasons why it's important.

What do you think?

[lvca]

Reopened. Guys, this is quite easy to support but we'd need a few days. Any chance to receive a sponsorship to develop it?

[edwardkay]

Thanks @lvca. Would love to offer sponsorship if we could but sadly there's no capacity in our project budget :(

[giastfader]

@lvca we are interested in this and depending by the necessary effort, we could develop it, if you will give us the right advices.
Please drop me an email....

[lvca]

@giastfader it would be great: a new feature by BaasBox ;-)
You can write an implementation of com.orientechnologies.orient.core.compression.OCompression interface and register into OCompressionFactory singleton. Example, you call your implementation as "encrypted". In order to activate it on a new cluster use:

ALTER CLUSTER MyCluster COMPRESSION encrypted

We store the database compression inside storage configuration, but we never exposed it on ALTER DATABASE command.

[giastfader]

Where do we read/store the key?

[edwardkay]

@giastfader Thanks for your reply. As @lvca says, direct BaasBox contributions to OrientDB would be great and is very encouraging from our point of view.

As we're using BaasBox as a product, please could DB encryption be enabled/disabled via arguments passed to the start script or similar, i.e. not needing us to recompile the Play project.

Could you store the key in a Java keystore?

[lvca]

We already have config/cert folder, what best place?

[giastfader]

Hi @lvca I'm working on this issue.
Since there are a lot of different kind of Exceptions that can be thrown during the crypt/decrypt process what do the methods of OCompression* classes are supposed to do?
I see that, for example, into the OZIPCompression.compress() method an IllegalStateException is raised if an IO operation goes wrong.
Is it fine to raise always that exception ?

[lvca]

You could also raise OSecurityException.

[lvca]

Hey @giastfader I was merging this in develop, but unfortunately you didn't sign the clahub agreement (for the Apache2 license). Please could you do that? Thanks in advance.

[lvca]

Waiting for you to electronic signing the CLA, I saw you use 2 new global settings:

STORAGE_ENCRYPTION_DES_KEY("encryption.des_key",
  "The simmetric key to use to encrypt/descript data at rest using the DES alghorithm, stored in BASE64. The key must be 64 bits long. Default is \"T1JJRU5UREI=\" (ORIENTDB).",String.class,"T1JJRU5UREI="),
STORAGE_ENCRYPTION_AES_KEY("encryption.aes_key",
  "The simmetric key to use to encrypt/descript data at rest using the AES alghorithm, stored in BASE64. The key must be 128 or 256 bits. Default is \"T1JJRU5UREJfSVNfQ09PTA==\" (ORIENTDB_IS_COOL).",String.class,"T1JJRU5UREJfSVNfQ09PTA=="),

I think it would be much better don't setting any password by default and check if password is null, an exception is raised. In this way the user can't do mistakes. WDYT?

[compensator]

Spelling: "simmetric" should be "symmetric"

[lvca]

@compensator you're right, I copied the original piece of code with no paying attention to the names.

[lvca]

Hi guys, I'm merging this PR today.

[lvca]

After reviewing it, keys are global, so if you have 2 database you can't have different keys. This should be per-db/storage.

[jrspriggs]

@compensator what was the OS/JRE you were using? We've been talking internally about just jumping Orient onto a RedHat Server, which we could then use some of IBM's FIPS 140-2 certified cryptography modules to meet our needs.

[compensator]

@jrspriggs I'm going to do a data dump here.

You've stated that you want to make OrientDB FIPS 140-2 compliant. OrientDB runs on the JRE, so configuring the JRE to execute in FIPS compliant mode via a FIPS 140-2 certified library, one that is certified at the required level (1, 2, 3, or 4; in your case, HHS only states FIPS "140-2 certified" with no certification level and "NSA approved" both with no date range), achieves that goal since OrientDB is using the JRE for encryption which will subsequently use the FIPS 140-2 certified library. Red Hat's NIST FIPS 140-2 Certification was based upon...the Mozilla NSS Library. Here is a post by someone on configuring the JRE to be FIPS 140-2 compliant on a Linux server using NSS: Configure a FIPS 140-2 Compliant Java Provider on Red Hat/CentOS/Fedora.

Bear in mind that this list shows the last date of test for certification along with the configuration of the environment in which the test was performed at the time along with the Level of Certification AND that the certification only applies if the module is executed on the exact same configuration (likely not going to happen unless the certification occurred within the past year):
NIST 140-2 Certified Cryptographic Modules/Products

What does this mean to you in terms of IBM's Java JCE FIPS 140-2 Cryptographic Module
(Software Version: 1.71)? Well here is the certification environment:

-Operational Environment: Tested as meeting Level 1 with IBM AIX 7.1 on IBM JVM 1.6 running on IBM 9117-570, Windows 7 32-bit on IBM JVM 1.6 running on Dell Optiplex 755, Solaris 11.0 on IBM JVM 1.6 running on Dell Optiplex 755 (single-user mode)

-FIPS Approved algorithms: AES (Cert. #2107); DRBG (Cert. #228); DSA (Cert. #657); ECDSA (Cert. #314); HMAC (Cert. #1281); RNG (Cert. #1082); RSA (Cert. #1081); SHS (Cert. #1830); Triple-DES (Cert. #1342)

Are you able to run on any of those configurations?

What the certification does provide is the checkbox on NSA approved algorithms, but that list is broad and you should configure the JRE to disable algorithms that are not the strongest where possible. You'll also want to install the Unlimited Strength Jurisdiction Policy Files

Also of note for IBM's JCE is that it is listed in 2013, but not in 2015; however, on the 2013 page, they enter a 2015 date. I'd send NIST question on that. The JCE doesn't list AES-NI if that is desired.

As you peruse the NIST FIPS 140-2 site, you'll note that products/modules generally don't go through the certification process every year. The last year that Mozilla NSS went through the process is 2012. You can see this in the chart. You'll also see that Red Hat, Sun, and Mozilla all contributed in the 2010 listing.

If you want the host operating system to also be FIPS 140-2 compliant, then you have to execute whatever steps are required to set the operating system to use a FIPS 140-2 certified encryption module.

You'll also notice in Red Hat's own documentation for JBoss FIPS compliance, that they reference the use of the Mozilla NSS library:
Red Hat JBoss FIPS Configuration

On that same page, they reference this Knowledge Base article:

How can I make RHEL 6 FIPS compliant?

In the RHEL 7 Security Guide, you'll see that they reference Libreswan. Libreswan merely calls the Mozilla NSS crypto library.
RHEL 7 Security Guide

[compensator]

@lvca I will create an issue for the URL loading. Before I do that, I would like to download and test a key management product to verify the requirements. I will initially use Hashicorp's Vault since it's free.

[jrspriggs]

@lvca is there a timeline for when 2.2 will be released? I know you're in alpha right now, but is there a date you are shooting for to have the GA out?

[lvca]

Take a look at our roadmap: http://orientdb.com/docs/last/Roadmap.html: we're quite good and on time. We're waiting for incremental backup to freeze features, then start with the Release Candidates.

[jrspriggs]

Thanks @lvca! also, @lvca or @compensator do either of you know if there are any EU specific standards like FIPS 140-2 certification? Or does EU try to just piggy back on that?

[compensator]

@jrspriggs I've been busy on other items for the past few weeks. Check into the following link.

http://www.privacytrust.org/guidance/safe_harbor.html

[obi1kenobi]

I read the encryption code, and here are my thoughts:

• DES is a outdated and broken algorithm where one can brute-force all possible keys to decrypt the data: https://en.wikipedia.org/wiki/Data_Encryption_Standard#Brute_force_attack
• ECB mode is not safe for any cipher -- see the famous penguin encryption example and note how one can still trivially tell that it's a penguin despite the "encryption": https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_Codebook_.28ECB.29
• Ideally, the database should use an authenticated encryption mode like GCM to confirm the authenticity of data as well as its confidentiality.
• Indexes and all other data in the DB should be encrypted -- otherwise, there would be an encrypted and an unencrypted copy of the same data on the same machine, which is confusing and doesn't sound desirable.

See www.cryptopals.com for some crypto exercises that show why not to use ECB mode and how quickly and easily it can be broken.

[lvca]

So instead of AES encryption what do you would suggest?

[obi1kenobi]

The AES part is great, but the cipher mode (AES-ECB) is the problem.

AES-GCM would be ideal if possible, with a 128-bit authentication tag and at least a 96-bit initialization vector (IV) as recommended by NIST. The IV must be securely randomly generated and different for each record being encrypted -- if the IV is ever reused, all sorts of attacks become trivially doable.

[compensator]

I agree that the choice of ECB mode was incorrect. As stated document at the OWASP URL in my post above which includes references to NIST, ECB should not be used. If for some reason you are not able to implement AES-GCM, CTR mode should be the minimum.

As for encrypted indexes, this is a different, more difficult problem and, in my opinion, a user of OrientDB can opt to not index if they have such security requirements until Orient has a feasible solution in that area.

[lvca]

Hi guys, I'd like to return on this to ask if you have a clear solution for the management of the key. Right now the key has to be entered in the server's console at startup. I see MongoDB, MariaDB and other DBMS asks for the key to an external server. Is there any standard we can rely on for this?

[compensator]

This is why I mentioned Hashicorp Vault as a test case. It's on Github [https://github.com/hashicorp/vault].

[compensator]

For users of the Lucene index, they might want to look at the Credeon SDK. I haven't dug into it deeply.

[obi1kenobi]

Asking an external server is a good idea, similarly to MariaDB / MongoDB and others. It's better than entering the key manually into the console, as then it would be difficult to build e.g. an auto-restarting docker container with OrientDB in it.

[finid]

So going by the status of this thread, is it safe to encrypt an OrientDB database using this guide?

Also, can one encrypt an existing OrientDB database?

[lvca]

It's safe, but you can't encrypt an existing database unless you export and reimport into an encrypted one.

[obi1kenobi]

@finid Unless I am very much mistaken, most of the concerns I raised in my above posts (like the use of AES-ECB, or the fact that indexes are not encrypted) have not yet been resolved. So if "safe" means "secure against a knowledgeable attacker stealing your raw data", my answer would be "no".

In line with that, I think this issue shouldn't be closed.

[finid]

Thanks @lvca and @obi1kenobi

[compensator]

If the encryption mode is not sufficient, just change it and rebuild.

[obi1kenobi]

@compensator it's not nearly that simple. For example, AES-ECB does not use an IV nor an authentication tag, whereas AES-GCM requires both of these things. Each encrypted record requires its own IV and auth tag, but OrientDB lacks the support for these additional fields in every encrypted record.

These are just some of the problems that need to be solved before OrientDB can implement a stronger encryption mode.

[compensator]

I didn't mean to gloss over those details. But it's good to point that out for those who haven't implemented encryption before and I appreciate having a wingman on this thread. Perhaps I'll have time to work on some of this someday amid everything on my plate. Unfortunately, I don't work for free. :)