All eyes towards a secure environment: Deciphering facets of modern IBM Notes and Domino encryption through Ytria tools.

IBM Domino, the secure platform that it is, provides you with a full range of encryption options to cover data stored on Domino servers or user computers (locally). Understanding the basics about applying encryption in your IBM Domino environment will help you beef up your security across the board.

Although you can employ encryption in many different places and in multiple ways throughout Domino, for this article we’ll concentrate on database and document encryption/decryption methods. We’ll explore their advantages and disadvantages, and we’ll look at how you can better manage them by using Ytria’s latest tools.

Note: Before I continue, I’d like to emphasize that Ytria never bypasses IBM Domino security. Moreover, Ytria does not allow decrypting of databases or documents that haven’t been encrypted by or for your Notes ID.

If you’re concerned about local access, you may want to locally encrypt your Notes and Domino databases to protect them from being accessed at the OS level. Why should you be concerned? Since the ACL is only enforced by the Notes client, all ACL protection is useless when an unencrypted database is opened from a local machine– as it can be bypassed by any API program.

In Domino, local encryption uses a combination of symmetric and asymmetric algorithms. A random key is generated, and this key is then used to encrypt the database. This key is then, in turn, encrypted using the current User ID’s public key and appended to the database. The result is a database containing a lower level key that, once decrypted by the User ID’s private key, can be used to unlock the database. This renders the database accessible only by the ID containing the private key capable of unlocking the encryption – the one used for the initial encryption process.

There are two main situations where you’d want to encrypt databases for greater security: (1) to protect data stored on local machines and (2) to protect data on Domino servers.

1) Encrypting databases on a Domino server: Done by using the Server’s ID file, this is a great security practice to ensure databases won’t be accessible locally – by anyone. This prevents, for instance, an administrator from logging in to the server at the system level, grabbing the NSF, and then doing as they please with it. It also prevents against the using the Notes client to open the databases locally. Why would we want this? Because in both of these cases, ACL protection flies right out the window. This scenario ensures the database is only accessible through the Domino server; in normal operations it’s always the server that’s accessing it on behalf of any given user.

2) Local database encryption: This practice ensures your local replicas can only be accessed by the designated end user’s ID file and prevents data theft in the event a laptop is either (among other possibilities) lost or infected.

You can easily set encryption directly upon creating your new Domino databases. And when creating new replicas, you can set the encryption status (flags). But when encrypting existing databases, it’s important to remember that changes are not applied directly. There are 2 separate steps to this process. In addition to changing the encryption status of an existing Domino database (encrypt/decrypt it), you’ll also need to run a Compact command to actually carry out the encryption/decryption task. Consequently, there are 4 possible encryption statuses a database can have: Unset, Set, To Be Unset, To Be Set (see fig. 1).

There are various encryption strength options available for Domino databases (see fig. 2) and the stronger the encryption, the more secure your data is. However, it’s important to keep in mind that decrypting databases with strong encryption is slower and requires more resources.

The exact algorithms used for database encryption aren’t very well documented, but we do know that in current versions of Domino, Strong database encryption uses the Advanced Encryption System (AES) 128-bit standard (and this is rumored to be getting upgraded soon to AES256). We can only assume Medium Encryption also uses AES, but with a smaller key. The exact algorithm used for Simple Encryption isn’t publicly known or documented. Although, considering the official IBM documentation states that databases protected by Simple Encryption are still compressible (as opposed to Medium and Strong), we can hypothesize that this algorithm might not even properly encrypt the data. It may simply prevent opening the database without the current ID file, making it a bit of a gamble.

As I’ve previously stated, the stronger the encryption, the more CPU resources are required to use the database. The only publicly available source information that puts forward CPU usage measurements according to encryption strength was blogged by Daniel Nashed – and it’s quite interesting:

For a 64-Bit Windows2008 R2 server with 4k users and mail9 templates, NRPC CPU utilization by encryption strength:

Not encrypted: 35% CPU

Medium encrypted 39% CPU

Strong encrypted 48% CPU

Daniel Nashed`s full blogpost: Details About ODS 52 shipped with Notes/Domino 9.0.1

Generally, it’s recommended you use Medium or Strong Encryption. In the case of Simple Encryption, it’s posited the actual data isn’t truly encrypted and thus could still be read using the API (suggesting that this method works more like a “flag” enforced only by the Notes client). Given that scanEZ makes extensive use of the C API, we expected to be able to bypass Simple Encryption. However, in our own testing of ODS51 databases with Simple Encryption, this wasn’t successful.

With an eye towards improving security, IBM Notes and Domino release v6 ushered in a default encryption level of Medium Encryption for all new replicas and locally created databases. So, as far as default settings go, there are two different scenarios that can be managed using notes.ini parameters: (1) default encryption for locally created databases and (2) default encryption for new replicas.

1) Default encryption for locally created databases

Using the following two lines in the notes.ini , you can manage your default encryption for locally created databases:

LOCAL_DB_ENCRYPT_ENABLE=1 -> 0/1 for whether databases should be encrypted by default

LOCAL_DB_ENCRYPT_DEFAULT=3 -> 1-3 where 1 stands for Simple, 2 for Medium, and 3 for Strong Encryption

2) Default encryption for new replicas

Keeping the same mechanics and values from the two lines shown above, we can easily set how newly created local replicas will be encrypted. Simply use the following parameters:

ReplDefEncrypt=1

ReplDefEncryptType=3

Interesting observation: When you set the default encryption type to either 1 or 2 (Simple of Medium encryption), you’ll retain the option of selecting any one of the three encryptions strengths from the drop-down menu (see fig. 3).

When you select Strong Encryption as the default (e.g. for local databases: LOCAL_DB_ENCRYPT_DEFAULT=3), the menu choices for encryption will be limited to Strong only (see fig. 4).

Fig. 4 A default of Strong Encryption will limited the drop-down menu choices to Strong Encryption only.

Now and then, questions have been raised about the encryption strength options that are available to you when trying to encrypt existing databases, versus available options for newly created databases. As it turns out, there are variances. And if one had been working on an old version of Notes (e.g. before v8.0.2), and they were to upgrade to a version later than 8.0, they would run into a few surprises. In our testing, the encryption strength for already created Notes/Domino databases underwent a change as early as v8. Before this turning point, all encryption strengths were available when encrypting both existent databases and those being created. After v8, however, unless you encrypt the database during creation, you will be limited to using Strong Encryption only.

We’ve had various customers tell us of situations in which some of their database templates had been moved to the server through FTP or Remote Desktop Connections, and in some cases these were templates that developers had previously stored on their local machines.

The problems began when the developers forgot to remove Local Encryption and they were compounded when these templates were used to create databases with hidden designs. Since access was restricted only to the developer(s) that created them, the organization naturally lost control over the application’s design once said developer(s) left the company.

The good news is that scanEZ allows you to toggle “hidden design” flags on and off (see fig. 5), and we’ve seen a large number of success stories where developers have made use of this in tandem with the Refresh Design option – allowing customers to regain control over their entire database designs. Can you imagine the amount of money this has saved?

Beginning with v12 of databaseEZ, we implemented support for managing everything connected to database encryption – no matter if the databases are located locally or on your server. With rapid property loading (regardless of database location) coupled with simple and intuitive drag-and-drop data manipulation, you`ll get a grip on your global database encryption situation in no time. When it comes to encryption, databaseEZ shows you a deeper and wider selection of information than your Notes or IBM Administrator client. Benefit from rapid visual identification for a variety of crucial settings’ status (see fig. 6):

• Unset, Set, To Be Unset, To Be Set encryption statuses.
• encryption strength
• and more

All the information you need to evaluate your encryption situation rapidly is laid out in one easy-to-use, responsive display. And, as with all our products, not only do we present this information to you, but we also provide you with all the tools you need to make changes – right at your fingertips.

After your evaluation, you can find options to simultaneously encrypt or decrypt multiple databases directly within the contextual menu’s options. But remember, applying these changes won’t directly encrypt/decrypt your databases. As we discussed earlier, in order to set your changes, you will need to run a Compact command on any changed databases. Again, this command is available directly within databaseEZ.

For local databases, you can simply select the databases you would like to process, right-click to bring up the contextual menu (see fig. 7), and in no more than 4 clicks you can process your selected databases directly, using the API.

For server databases, the process is just as easy and straightforward. You can unleash the Compact task on your databases directly from the contextual menu. But beware! Compacting a large amount of databases this way may have an impact on your server’s performance. Alternatively, you can choose to export all modified database path information into a Domino Indirect (IND) file (that you can process later using a single thread of the Compact server task) right from the same contextual menu (see fig. 8).

In addition to allowing you to sign documents using an asymmetric algorithm, Domino offers you two powerful native options for encrypting documents: asymmetric (private & public key) and symmetric (Secret key) options. Both encryption options are available on the Security tab of each document.

Public Key Encryption: Encrypting a document using public keys is a relatively straightforward process. Go to the Security tab of the document properties window, select one (or multiple) user(s) from either the Domino Directory or local address books, and the document will then be encrypted using their Public keys. Note that you don’t have to select your own Person document to ensure the document stays available to you – this is done automatically. Once the document is encrypted, only the authorized users can view it; it will be decrypted for them using their private key.

Secret Key Encryption: To encrypt documents using Secret keys, you first need to create a new Secret key under the File > Security > User Security section. With Secret keys, you have a choice of using either 128-bit RC2 (backward compatible through Domino R6) or the stronger 128-bit AES (compatible with Domino 8.0.1 and later) algorithms (see fig. 9).

This is going to be the key that will be used to both encrypt and decrypt the document. So, in order to share the document, it’s imperative that you give the intended recipient access to the key either by mailing it to them right from the security dialog or by exporting it and then transferring it to them directly (on a flash drive for example).

To read more about document encryption, check out the official IBM Documentation: Encrypting documents and fields

Unfortunately, encrypting or decrypting documents en-masse is very (!) troublesome with the native toolkit. In fact, it always has to be carried out document by document. Aside from the numerous requests by several e-discovery customers for advice on how to do this better, we’ve also been asked to help them simplify the process of identifying public and secret key encrypted documents in Domino databases.

In our v12 release of scanEZ, we implemented various search options aimed at helping you single out encrypted documents. We also added the ability to mass-encrypt/decrypt whole documents or individual elements (yes you have “element level” choice!) using either public or secret encryption keys.

Now, using scanEZ’s Document Analyzer (see fig. 10), you can easily pinpoint the following types of documents:

• Documents encrypted with Secret Encryption Key(s)
• Documents encrypted with Public Encryption Key(s) for both listed and unlisted users
• Documents not encrypted, even though Public or Secret Encryption keys are listed
• Documents not encrypted, yet containing items flagged for encryption

Once they’ve been found, scanEZ allows you to decrypt your encrypted documents directly through the Document menu’s Encrypt/Decrypt dialog (see fig. 11).

As we’ve seen, encryption is applied in many different ways throughout your environment; it’s important to keep in mind that this variance of possibilities allows for almost unmatched versatility in securing the access to your data. With Ytria’s line of effective tools, your resources for deciphering how these aspects play out across your databases has never been more complete; accurate management of such a large amount of variables has never been easier. But with such great power comes great responsibility. You can rest assured that for all the features offered, no respect is lost on the fundamentals of Notes and Domino security.