Shaded elements indicate points at which the document is secure from unauthorized use.
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 file 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 file 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 file 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 file.
This diagram shows RightsVault integrated with an information management system. Two client-side systems are on the left; two server-side systems on the right. The three-part arrows depict Net communication path.
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 an engineering firm named Genner, a project Pate that Genner is bidding on, and a consulting engineer Spencer.
Info Mngmt System is an application for creating, managing and using information. 
Typically, engineers use it to maintain and query a database of project and design information.
Example: Genner documents a design to respond to an RFP (Request for Proposal) from the manager of the Pate project. Winning the bid for the work hinges on the design of the electrical subsystem, and Genner has an innovative design. The design is created and stored in the system database.
RightsVault is an Internet-deployed system interfaced to the Info Mgmnt System. Through the user interface of Info Mgmnt System the user 
drives RightsVault to protect (encrypt, identify), catalog (describe, make visible and accessible), and set usage permissions for a protected doc. The Info Mgmnt System uses a RightsVault API (application program interface) to drive these operations. But the Info Mgmnt System is not always needed to drive RightsVault. The user 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 consultant 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.
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 protected doc 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 protected doc, 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 protected doc 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 protected doc. RightsClient tracks this off-Net use as well. When it notices a Net connection RightsClient will opportunistically upload the audit information to RightsServer.
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 protected doc 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.