The Remapper Encryption Key
The MIRC Anonymizers (both DICOM and XML) have the ability to remap certain elements containing PHI to unique values in such a way that if the same PHI is encountered again, the same substitute values are supplied. The remapper keeps track of the correspondence between the PHI and the substitute values in a simple database. To keep the PHI from being visible to an unauthorized person, it is encrypted in the database. The cipher uses a key which can be configured for the specific remapper or left as a default value which is built in to the remapper code.
For security, the remapping database, which is located in the storage service's trial directory in a file called idtable.properties, should not be accessible on the network. The MIRC software refuses to serve that file from any location on the server, but it is possible that anyone with privileges to see that directory on the system - not to mention a hacker - can find the file. If this is a concern, it is wise to use a unique encryption key rather than the default. When doing this, it is important not to allow the key to be compromised. One way to avoid compromising the key is to write it in a file stored on a removable medium like a CD-ROM or a USB key, plug the medium into the system, start MIRC (which will read the file on startup), then remove the medium and store it in a safe place. This article describes how to configure MIRC to implement this process.
1 Creating a keyfile
An encryption key is stored in a keyfile as a text string. To create a keyfile, run the |KeyMaker application, click the Make a Random Key button, and then click the Save the Key button and save the keyfile in a file outsite the Tomcat directory tree.
The default key length is 128 bits. This is the maximum allowed by U.S. export regulations. You can create larger keys, but to do so, you must install the unlimited cipher configuration in Java. Unless you know exactly what you are doing, you shouldn't bother.
2 Configuring the Remapper
When you first install a new release, it will be configured to use the default key. After starting Tomcat, go to the storage service's admin page, click the Update Configuration button in the DICOM Service column and look for the part of the page that shows the Central Remapper Parameters. In the External key file field, enter the fully qualified path to the keyfile, for example, X:\keyfile.storageservicename. (If this field is left blank, the system uses the default key.) Click the "Update trial.xml" button at the bottom of the page and then restart Tomcat. The system loads the key from the keyfile when it starts, so you can remove the keyfile's medium once Tomcat has restarted. Do not lost the key or you will lose access to the remapping database.
Whenever Tomcat starts, it initializes the remapper and checks to see if the supplied key is the one used for the database. If the database has no PHI entries, it will allow the key to be changed; otherwise, the initialization will fail. Thus, you must change to the final value of the key before using the remapper.
Each storage service has its own remapper with its own database, and each remapper can have its own key.
If the system fails to initialize the IdTable with whatever key it has been configured to use, it puts an entry in the logs in the Tomcat/logs directory and it also displays the error in the Show Log listing on the storage service's admin page. If the initialization was successful, it just puts a message in the Show Log listing, not the Tomcat logs.