Orientdb: 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.

[lvca]

Ok, done. The password now can be passed as "STORAGE_COMPRESSION_OPTIONS" setting before creating the database.

    final ODatabase db = new ODatabaseDocumentTx("plocal:target/testCreatedAESEncryptedDatabase");
    db.setProperty(OGlobalConfiguration.STORAGE_COMPRESSION_OPTIONS.getKey(), "T1JJRU5UREJfSVNfQ09PTA==");
    db.create();
    db.command(new OCommandSQL("create class TestEncryption")).execute();
    db.command(new OCommandSQL("alter cluster TestEncryption compression aes-encrypted")).execute();

And the same for opening it:

    db.setProperty(OGlobalConfiguration.STORAGE_COMPRESSION_OPTIONS.getKey(), "T1JJRU5UREJfSVNfQ09PTA==");
    db.open("admin", "admin");

[lvca]

But if not specified, global setting is taken. There are no 2 different settings for DES and AES, but just STORAGE_COMPRESSION_OPTIONS.

[lvca]

I'm updating the docs...

[lvca]

Done: http://orientdb.com/docs/last/Database-Encryption.html

[compensator]

Is there any impact to indexed searching to include Lucene?

[jrspriggs]

I've got a couple of quick questions for this, because we would love to use this instead of self-implementing hooks for an upcoming release.

1) If you encrypt at the cluster level and not the whole database, then will related indexes for those clusters also get encrypted at rest (or do indexes actually persist to disk?)?

2) We're scouring our security requirements because we currently have our code using CBC instead of the ECB mode Orient is using. Any chance you guys could add that as a third config option (DES, AES, AES-CBC)?

[lvca]

@compensator Good question, @maggiolo00 is not using encryption on Lucene because it's outside the OrientDB storage scope. @maggiolo00 do you have any idea?

@jrspriggs (1) indexes are not encrypted, but we could support it. (2) Please could you show the Java code you'd use for your encryption? For AES we do:

theKey = new SecretKeySpec(key, "AES");
cipher = Cipher.getInstance("AES/ECB/PKCS5Padding");

[lvca]

Ok, the idea of using the compression API and names is horrible. I prefer to refactor it to use ad-hoc names.

[jrspriggs]

Actually, dug through our requirements and found that the library I'm even using isn't compliant. It turns out our encryption requirements need to be Fips 140-2 compliant. There aren't a lot of libraries that do that, and I've not found anything to convince me that the base javax.crypto.cipher class is.

[lvca]

I can make this encryption pluggable if you can find a Java lib that can do what you need.

[jrspriggs]

Actually there is. RSA BSafe Crypto-J library is FIPS 140-2 certified. If you could make the encryption pluggable, it would probably make it very easy for us to pop this library in and just let it go at that. The downside for anyone using it in their application is going to end up being the cost. Usage licensing from what I've read for just 1-2 of their algorithms is around $58,500, but I am still waiting for a quote from them directly to confirm.

Given Orient is offered open-source, I'm doubting it's a cost Orient Technologies would be open to taking on to make Orient's encryption at rest meet the FIPS certification for using it in applications with the federal government, but would it be something you would possibly take on to add to the Enterprise edition since you charge licensing on that? It could widen your sales opportunities for devs writing software for use with government agencies and easily compliant for health care applications as well.

EDIT: Finally got a call back from RSA sales group about actual pricing for their BSafe library. Their web information is a bit misleading. Apparently they aren't selling it actively anymore as it's on a roadmap for end of life and will not be supported after about 2018. They are going to call me back after they talk among their other sales and tech groups to let me know what options they would have for FIPS certified Java libraries.

[lvca]

@jrspriggs cool, please keep us updated on this issue, so any further users could read it. About the pluggability I'm completing the API, they are almost done, in 3 hours documentation should be updated and the API should be final.

[compensator]

@jrspriggs, If any of what I state after this not relevant to your situation, my apologies in advance.

I was working on the FIPS 140-2 crypto compliance issue last month for a customer and where we arrived is that while you must use a certified implementation, the certification alone doesn't guarantee that you are implementing only the ciphers and protocols that you should. You'll need to modify the java.security properties file to disable anything you don't want to support. I tested OrientDB for SSLv3 denial using OpenSSL and it complied (it only responded successfully to TLS and denied renegotiation to SSLv3). You can download, compile, and install the Mozilla NSS lib into your JRE if you are using Java only as a FIPS 140-2 certified implementation for free. I haven't dug deeply into the NSS implementation, nor have I tested it yet since I've been focused on other items since then.

[jrspriggs]

@compensator I would love to see a tutorial or guide on that if you have a link to implement that. Our applications tend to be used by state and federal agencies, so the FIPS 140-2 is pretty important. We do have a contact for security at the federal level to run ideas by to make sure they will float well, so any guide or documentation you can point me to and I can pass along would be greatly appreciated!

One note though, our issue is less with TLS and SSL requirements, but with the data at rest on a disk because there is PII involved with a health care app. So, I'm wondering if the restrictions to the java.security properties will work the same for us or not, but it does give us another option to research.

[lvca]

Ok, refactoring done and documentation updated. encryption is apart than compression, so you could have both set. For more info look at: http://orientdb.com/docs/last/Database-Encryption.html

@compensator and @jrspriggs I think it would be cool adding at documentation the steps to have a "FIPS 140-2" working with OrientDB. If you have some material, please let me know.

[compensator]

@jrspriggs It sounds as though your organization should hire an InfoSec engineer who has hands-on experience. Since OrientDB executes on a JVM, you must get the JVM to a FIPS compliant state in terms of encryption. The issue is the use of a FIPS 140-2 certified module. Here is the statement by the NIH on the subject: https://ocio.nih.gov/aboutus/publicinfosecurity/Pages/encryption.aspx

You'll notice that they don't specify the Level of certification required.

This is the link to FIPS 140-2 JSSE enablement in Java 8 for the JRE at Oracle. You'll see at the bottom (I've inserted a hyperlink to an Intel site that contains instructions):

"When SunJSSE is configured in FIPS 140 compliant mode together with an appropriate FIPS 140 certified cryptographic provider, for example Network Security Services (NSS) in its FIPS mode, SunJSSE is FIPS 140 compliant."

While this primarily discusses encryption in transit, configuring the JRE to use the the FIPS certified cryptographic provider covers the requirement. Bear in mind that this is only addressing JRE-based cryptographic module compliance. In the spirit of actually securing access to and data within OrientDB, all avenues of access need to be assessed.

Mozilla NSS Project

This is a nice cheat sheet from OWASP Cryptographic Storage Cheat Sheet.

One enhancement that I'd like to see in OrientDB is the ability to load certificates/keys from a URL rather than the file system to enable vault integration. OrientDB would load the public key of the remote vault to enable HTTPS connectivity to the vault and retrieve its private certificates/keys.

[lvca]

@compensator loading the certificates from a URL sounds simple, what do you think about creating a specific issue or that?

[jrspriggs]

@compensator the FIPS compliance mode document for Java is a good resource, but I believe we are already doing that in regards to our SSL/TLS usage. That part hasn't been as concerning to us as much as the concern about encrypting data at rest so that the encryption package used is FIPS 140-2 certified.

[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. :)