caume / caumedse Goto Github PK

While new authenticated encryption modes (e.g. GCM, CCM) are being pushed to the new versions of openssl (>=1.0.1), it will take a while until these versions become widely adopted.

It is recommended then to standardize in the mean time to an encryption algorithm such as "aes-256-cbc" and ensure authenticated integrity with an Encrypt-Then-MAC procedure. We should replace the Hash fields for files with MACs with this scheme. Namely HMAC with one hash algorithm from the SHA family, and use the organization key for the MAC as well.

We would then verify the MAC before attempting decryption.

Standardize all values to be 16 bytes long (the same as the random filenames for protected files).

Also, increase the PRNG seed to 16 bytes long (/dev/random should have no problem in providing these many bytes).

The current (static) makefile has some issues with some systems. Providing a configure script with proper autoconf and automake templates is required in order to ensure a minimum degree of portability.

This will also reduce the time that testers/users spend dealing with compiling and library issues, and allow them to focus on testing the functionality, security and performance of the software.

By the way we designed the protection mechanisms for documents and registers within internal databases, each element is encrypted with a key derived from pbkdf2 using the organization key (treated as a password that is expanded using the full key range with pbkdf2) and the random salt corresponding to the element.

From a security point of view this is good since attackers may take advantage of a known, short plain text in order to brute force the key. The iterations on PBKDF2 restrict the computations of brute force and dictionary attacks. However, it also imposes a performance penalty since we need to calculate ourselves the corresponding key with pbkdf2 for every element.

One way to improve on the performance is to eliminate unnecessary rounds. This can be done in situations where we can safely assume that the organization key was generated with a pseudo random generator and the range includes the whole key-space of the encryption algorithm. If this is the case, pbkdf2 would act as a permutation function on the keyspace K, rather than an expansion function from password space P to keyspace K an therefore adding iterations does not increase the security of the organization key.

We may assume the organization key is a pseudorandom key in keypsace K if it is provided as a string representation of an hexadecimal byte array whose length is >= the length of the keyspace of K in bytes (one example of such keys is the default EngineOrg key generated randomly on the first run). In this case we would only run 1 iteration of pbkdf2 instead of the default number of iterations. With this we would promote the use of pseudorandom keys by means of an increased performance; applications are likely to use them.

Many checks after decryption use strcmp and strncmp to verify that a documentId , a role or other resource matches a resource request with the corresponding organization key.

Common implementations of these functions compare one-by-one characters of both strings until a difference is found, until a \0 is found or, in the case of strncmp, until the maximum size is reached. This means that a no or few matches will take less time to execute than an exact match (especially in a long string).

It is unclear in CaumeDSE's implementation if this poses a significant risk since we don't store or compare keys, but rather decrypt all records and then match against those decrypted successfully. However, since in our case incorrect decryption results in empty strings, it may be possible to estimate the number of records that decrypt correctly to a certain key with a timing attack.

So it seems a good idea to replace these functions with another that keeps comparing (e.g. against the last character of the shortest string) until the end of the largest string and just flag the mismatch. See PyCrypto 2.4 for an example of a solution to a similar problem: https://www.dlitz.net/blog/2011/10/pycrypto-2-4-released/ .

Types have been made opaque (see openssl/openssl#962):

"One of the primary differences between master (OpenSSL 1.1.0) and the 1.0.2 version is that many types have been made opaque, i.e. applications are no longer allowed to look inside the internals of the structures. The biggest impact on applications is that:

1. You cannot instantiate these structures directly on the stack. So instead of:

**EVP_CIPHER_CTX ctx;**

you must instead do:

**EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new();**
....
**EVP_CIPHER_CTX_free(ctx);**

2. You must only use the provided accessor functions to access the internals of the structure."

Even though it is still alpha code and the idea is to test. It may be easier to execute the predefined set of tests outside the main program.

Also, this will make it easier to include test verification in the configure script in the future. Eventually, when the code reaches beta or stable, it won't make sense to see the test's output each time you run the program.

In some linux distributions (ubuntu 16.04) there are compilation problems with the current configuration scripts:

• gnutls library is not included in configure.ac

• there are issues with building the embedded perl script interpreter (configure.ac, makefile.am)

Currently the application uses OpenSSL's default PBKDF1 (PKCS#5 v1.5 with MD5 an counter =1) to derive encryption keys from user keys (which are more like passwords).

While this is compatible with the current key derivation procedures from openssl's command line tool, it is recommended to replace it with PBKDF2 (PKCS#5 v.2.0 using Sha-1 and a large counter) for these reasons:

• PBKDF1 with a counter of 1 is prone to brute force attacks
• PBKDF1 with MD5 has a limited output length, meaning that derived keys won't be sufficiently large for some algorithms such as AES-256.
• PBKDF2 is the recommended security standard.

To maintain compatibility with openssl's command line tool, we should provide our own tool to derive key and iv from a password using PBKDF2. The user would need to derive manually the key & iv with the tool and then use them directly as parameters for openssl.