Use the browser controls to return to previous page

RightsVault Overview

Persistent Document Security

The diagram below illustrates three common approaches to securing digital files. In each case a document is shown being delivered from an information system source over the Internet to a users machine (the oval say a desktop PC or a handheld tablet PC).

Shaded elements indicate points at which the document is secure from unauthorized use.

 

Several security breaks are illustrated in the first two approaches. The document can be:

By contrast, although a secured object may leave the legitimate target (check marked in the diagram), it is unusable and therefore not a breach of security.

With Channel Security (e.g. Virtual Private Network or VPN), the EMR is transported in a secure tunnel across the Internet. It will not leak en route, but once it arrives at its destination, it is insecure and can leak in many ways.

With Lock-Unlock Security, the EMR is secured before transport. It arrives secured, but the user unlocks (decrypts) it in order to use it, since the reader program cannot process an encrypted file. Thereafter, it can be copied and sent out in the same ways as above.

Persistent Security protects files before, during and after delivery. The EMR is always secure. The reader or viewer is functionally extended made trusted to dialog with the RightsClient to allow only authorized access and authorized operations, and to track selected uses of, or operations on, the EMR.

Integrated System Structure

The following diagram shows RightsVault integrated with a Health Information System. Two client-side systems are on the left; two server-side systems on the right. The three-part arrows depict Net communication paths.

We will now examine this diagram further, discussing each of the individual components. To illustrate each step in the process, we describe an example scenario involving a GP named Dr. Genner, a specialist named Dr. Spencer, and a patient named Pate.

Health Info System is an application for creating, managing and using health information. Typically, physicians and nurses use it to maintain and query a database of medical (or patient) information.

Example: Genner documents an encounter with Pate and has an X-ray taken and an X-ray interpretation report generated. All of this information, including the digital X-ray, is entered into the system database as part of the patients permanent medical record.

RightsVault is an Internet-deployed system interfaced to the Health Info System. Through the user interface of Health Info System the user drives RightsVault to protect (encrypt, identify), catalog (describe, make visible and accessible), and set usage permissions for an EMR. The Health Info System uses a RightsVault API (application program interface) to drive these operations. But the Health Info System is not always needed to drive RightsVault. The health care giver can also use a Web interface to achieve the same thing.

Example: In a few seconds, Genner pastes together a document with the information relevant to the consultation, protects it at RightsVault, and sets permission for his specialist colleague and a partner of hers to display it. When RightsVault processes the set-permission operation, it sends this information on to the RightsServer. Then Genner emails Spencer as follows.

Hello Mary. Please give me a rough estimate regarding the design we discussed this morning. I have granted you rights to view file www.Genner.RightsVault.com/PateElec.pdf for the next 2 days.

The document has three parts:

- an overview and three details of our electrical design (as discussed, the details disclose our competitive advantage on the Pate bid)
- my analysis of the advantages of our design relative to what we expect from competitor designs (please comment and note objections!)
- two paragraphs excerpted from www.XYZOnlineElecEngrReference.com .

If you do decide to consult with your partner before he gets back from overseas, email him a copy of the report you have. Ive given him display permission. As you suggest, he can read it on the plane. Remind him all uses of the document are recorded for possible audit purposes.

 

Alternately, instead of sending Spencer a download link, Genner could have attached a copy of the protected document to the email. It does not matter who has a copy of the protected document or how they get it because only authorized users will be able to open it. On the Internet we cannot rely on controlling copying and redistribution, but we can control access.

 

 

 

 

 

 

Trusted Tool and RightsClient can be used on any computer to access protected files or operations in an authorized and auditable way. The Trusted Tool with a RightsMarket trust extension (e.g. Acrobat Reader with a plugin) is the reader or renderer of the protected document. It is a common tool, familiar to the user, that will display unprotected documents as well as protected ones. When it encounters a protected document, the Trusted Tool will query the RightsClient "Does this user have permissions for this document?".

Example: Spencer receives the email from Genner. At work she uses her laptop Web browser to follow the link to the EMR in RightsVault and download it. She launches the document, causing a permission query to RightsClient, which is passed on to RightsServer. The permission answer returns via the reverse path and the document is displayed to the specialist. On a slow Net connection this may take a few seconds, but its faster than alternative delivery methods. Its secure, auditable and affords the digital advantages of being searchable, linkable, accessible online, and cheaper to store.

RightsServer is the ultimate authority for answering permission queries and tracking usage. In one sense, the RightsClient is a proxy for the RightsServer. Communication between the RightsServer and the RightsClient is secured and mutually authenticated over the Net by public key technology.

Example: When the specialist Spencer uses the EMR, the Trusted Tool reports usage to the RightsClient (e.g. opened at time X, excerpted 123 words at time Y, closed at time Z). Since she is connected to the Net, the tracking information is uploaded to the RightsServer.

 

 

 

Spencer leaves for home and takes her laptop with her. At home she opens the EMR again, this time without a Net connection. The RightsClient stored the answer to the first permission query and, assuming it is not expired (i.e. within the time limit Genner set), uses it again to permit access to the EMR. RightsClient tracks this off-Net use as well. When it notices a Net connection RightsClient will opportunistically upload the audit information to RightsServer.

Integrated System Data Flow

We repeat the example scenario above, this time with reference to the following two diagrams and focussing primarily on data flow between server side and client side components. This is a simplification of what happens, but it shows basic behavior. The first diagram depicts initial conditions.

For illustration, there is one EMR already in the RightsVault and Genner has useright for one year. The second diagram shows final conditions.

Comparing initial to final conditions, note the following ordered actions and the consequent data flows and data stores. The actions are ordered, but only synchronized within a numbered group. For example, action 1a is immediately followed by 1b, then some indefinite time later, action 2 happens.

  1. Genner creates and protects the EMR (primarily an X-ray report) that he wants to send out for consultation, and sets permissions for Spencer and her partner to display the report. The EMR shows up in the RightsVault, and the permissions show up in the RightsServer.
  2. Genner had previously discussed the case with Spencer. He emails her a consultation request with a few details and a link to the EMR in the RightsVault.
  3. Spencer follows the link and downloads the EMR at work. She already had Acrobat Reader on her laptop, but not the plugin extension to make it trusted in the RightsVault system, and not the RightsClient. So she gets those two software pieces automatically when she downloads the EMR. The next time she downloads an EMR, she will probably need only the EMR itself. Note that the useright (permission, license) does not appear on her laptop until step 4c.
  4. Spencer double-clicks the EMR and sets off a chain of actions.
    1. The open operation causes the Acrobat Reader plugin (trust extension) to ask RightsClient "Does Spencer have the right to open PateXray.pdf?". RightsClient cannot find a local permission for the operation.
    2. RightsClient passes the question over the Net to RightsServer. (If no Net connection were available, Spencer would be advised to connect.)
    3. RightsServer sends back the permission (useright) and it is stored in secure local store. RightsClient dynamically decrypts the EMR without exposing the decrypted document, and permits its display.
  5. This step is not illustrated in the diagram. Spencer scans the EMR at work then closes it and returns to her other work. Several hours later at home with her laptop she opens and studies PateXray.pdf. She is not connected to the Net but she is within the time limit set by Genner for her use of the EMR, so RightsClient can answer the permission query from secure local store. Still, all her uses are authorized and tracked. The usage information is stored in secure local store and will be uploaded to the RightsServer when a connection becomes available probably next day at work.