Skip navigation.
Architecture Briefs

Tolven Document Encryption

Security applies at many different layers and components in the system. For example, a firewall is often the first line of defense protecting against outside attacks. If the firewall is penetrated or if an attack comes from inside the firewall, Tolven SSL provides protection from attempts to snoop on private conversations between system components.

This paper is primarily concerned with data at rest, such as when it is in a database. More specifically, this means data maintained in a Tolven database. This destinction is important because, although encrypted data can be distributed to end users, there is no way to manage and audit access to that encrypted data once it leaves the database server. In general, Tolven assumes that it is easier (read possible) to protect data in a data center than it is to manage data on laptops, desktops, or mobile devices. Also, while it is beyond the scope of this paper, Tolven provides for so-called explicit acts to accompany all activity between accounts. This results in a natual audit trail of activity. Thus, at least to the extent that Tolven manages data, the "audit trail" is maintained naturally.

Many architectures assume that there is an inner circle of system administrators, operations and support staff that are trusted not to reveal secrets. Tolven has a more strict requirement: an attacker with the root password and with the source code and access to the database should not be able to access protected data. This problem would be relatively easy to solve if the data were simply encrypted by a user and later decrypted by that same user. But such a system would not be terribly useful. It would be analogous to storing cash in a safe deposit box.

To understand how Tolven manages identifiable medical information it is necessary to review some key principals:

Security by obscurity is ineffective (Ref). While there will be those that don't trust banks with their money, hiding ones money under a mattress is not more secure. So too with health data. Ignoring the fact that health data stored under a mattress (on laptop computers or on a desktop computer in a doctor's office) has very limited utility, security is virtually impossible to maintain in such environments. The custodians of such data will have limited skills, resources or motivation to protect identifiable medical data. Of course keeping data under a mattress has the potential for being very secure, the price of doing so, posting a 24 hour guard and perhaps a guard to ensure that guard remains honest, would be costly. And if that local system had any access to the internet, the administrator is still faced with the same problem (and costs) that they were trying to avoid with a server-based approach.

Tolven uses a security by design approach employing several process and technical elements:

Ground up

Many vulnerabilities are caused by the fact that security is often added as an afterthought. For example, a system designed to operate only within a single enterprise, perhaps before the internet and HIPAA privacy were factors, may have to depend on a firewall and employee policy as its only means of defense. Years of finding and patching vulnerabilities may result.


The most effective security mechanisms are those that depend on well known difficult-to-break mechanisms such as public-key encryption used in a straightforward way. The use of these mechanisms is easily audited so that trojan horses or back doors can be found during an audit.

Open Source

Open source further enhances security by limiting the likelihood that a single vendor or maintainer intentionally or unintentionally allows a vulnerability. As many eyes as appropriate can inspect the source code. Analogy: Mom tells one of two bothers to divide a piece of cake in two, the other brother gets to choose his piece first. Result: The most accurate bisection known to man. In other words, it doesn't matter who writes the code as long as others get to watch and to judge its vulnerabilities.

Tolven User

A Tolven User is someone with a username and password, a real person. Not all patients are users, not all users are patients. Not all providers are users, not all users are providers. For example, a young child may be a patient but would not likely be a user. A physician may author documents or perform medical procedures but they may not be a users, preferring instead to allow other users enter information on their behalf.

The most common security token that a user posesses is a password. But whatever it is, it's security must be preserved. That means, among other things, a user should never have to share their password with anyone. Once a password is shared, security of protected information becomes dificult to manage.

Further, the password should never exist anywhere that it could be stolen. For Tolven, that means that the password remains with the user, never stored in a form that can be revealed. Only a ramdomized "one-way" hash of the password is stored in Tolven (actually in LDAP), sufficient for verifying that a supplied password is valid but it cannot be used to recover the password. Thus, there is no ability for Tolven to tell a user their password. (Tolven does have an optional password-recovery feature which when used reduces the security level slightly in favor of user convenience).

Tolven Account

A Tolven Account is a collection of one or more users that work as a team, typically on patient data which is associated with that account. Typical accounts are clinics and families. From a security perspective, privacy and security among and between clinics and families is handled in the same way: While additional security measures might limit user access within an account, for data encryption purposes, all Tolven Users have access to all data within each Tolven Account they are a member of. For this reason, Tolven encourages accounts to have the smallest number of users needed to administer the protected data within that account. A family, a clinic, an Emergency department, a medical or surgical department, ancillary unit, nursing unit or a small inpatient hospital make good Tolven Accounts.

Private data owned by one account can never be read by a person that is not a member of that account

This is an absolute Tolven rule that results in a number of other requirements. First, the restriction includes system administrator "insiders". In other words, being an insider should not afford any special ability to access protected information. Tolven does not suggest allowing database access beyond those few trusted individuals, but it is good to know that inside access does not provide carte blanche to protected data. It does mean that a misplaced backup tape or the actions of a disgruntled employee do not necessarily constitute an actual privacy breech.

Account User

An AccountUser object associates one user with one account. While a user is logged in, the user can be associated with only one account at a time. AccountUser is essentially "membership" criteria allowing a previously authenticated user to access a partuular account. As such, this object is where each user stores their encrypted copy of the AccountPrivateKey. With this key, the user is able to recover documents held by the account. In effect, certain account users are able to "invite" other users into the account. This peer-based invitation is critical because it is how the key that unlocks documents owned by that account is shared between user of that account. In other words, a top-level system administrator, unless they were listed as a member of the account, would be unable to pass on the private key for an account.

By analogy, the accountPrivateKey entrusted to the user behaves like the dual keys used to open a safe deposit box. The user never has the ability to open the box (document) on their own and the box is not kept by the user. So, in practice, the ability to access protected data can be revoked and all access can be audited.

Secret Keys

Secret or symmetrical keys such as DES, 3DES, or AES are used for encrypting or decrypting documents. The key itself must be protected since physically having it, provides access to the document it encrypted. When Tolven stores a secret key, the secret key is encrypted using assymetric key pairs (see next section). Each document is given a different secret key so that, in case a secret key is recovered, it can only be used to decrypt one document.


Public-Private Key Pairs

Public/private (asymmetric) keys allow a document to be encrypted without requiring access to the private key, which is required to decrypt (recover) the encrypted document. In practice, the public key is only used to encrypt a secret key which is then used to decrypt the document itself. Tolven defines two different kinds of key pairs, one for each user and one for each account.

The account keys are used to encrypt documents (using the public key) and decrypt documents (using the private key). The account private key is encrypted.

The user keys are used to sign documents and to protect a user's copy of the AccountPrivate key. Each user in an account has an encrypted copy of the account private key. In this way, one does not have to "change all the locks" when a user leaves an account.

Each user's private key is protected (encrypted) by the user's password.


Document Encryption

Encryption comes down to protecting documents while at rest in persistent storage. Here is a rundown of the steps involved in being able to read an encrypted document (assuming you can somehow get access to the document):

  • To decrypt a Document, the encrypted Document and the encrypted SecretKey used to encrypt the document are needed
  • To decrypt the SecretKey, the encrypted Account PrivateKey is needed
  • To decrypt the encrypted Account PrivateKey, the encrypted Tolven UserPrivateKey is needed
  • To decrypt the TolvenUser PrivateKey, the user's password is needed
  • To get the user's password, the user must be logged in
  • In order to log in, the user name and password must be authenticated by LDAP

What is not Encrypted

In practice, a lot of data about a patient, although protected, may not be encrypted. This is due to the tradeoff between the restrictions imposed by encrypted data and the utility of having fast access to indexed data which is not encrypted.

Tolven supports both extremes, full encryption as well as (almost) no encryption. Technically, index data (called MenuData) is not encrypted. Menu data is used for patient lists, problem lists, lists of results, allergy lists, etc. When the user drills down to an item in a list, the detail is almost always encrypted.

When Tolven rules extract data from encrypted documents (or messages if you prefer), the amount of information indexed can be limited. For example, say a rule only puts general information into an index without, say, including patient identity. In that case, the unencrypted index data might have research value but does not reveal any of the personal information stored in the encrypted document.

More often, personal information is included in the index, thus enabling patient lists, cohorts, and registries. Psych notes are sensitive enough that they may never be indexed for any purpose. In that case, only the author can access the note itself.

One approach that retains full encryption with only a limited reduction in performance is to maintain lists in document (encrypted) form rather than in direct database indexes. In this approach, Tolven rules do not add the patient to a patient list maintained in MenuData. Instead, the list is maintained in an encrypted XML document. As long as the number of updates to the list is limited and the length of the list is small, this approach ensures complete protection. [Due to its limitations, this approach is not supported out of the box but can be implemented in Tolven rules if needed.]


Rely on the Tolven support team to help resolve problems during any stage of your application development lifecycle, deployment or implementation.