HK1135530B - Systems and methods for document control using public key encryption - Google Patents

Description

System and method for document control using public key encryption

Background

As a result of the migration from paper-based documents to electronic documents, which is now almost ubiquitous in the business world, document management has become an important issue for large, medium, and even small companies, businesses, and organizations.

Old, obsolete and redundant documents consume a lot of server space in a networked computer system. As a result, these entities may need to constantly increase server space, or take frequent file backup and cleanup operations that may be expensive and impractical to implement. Furthermore, due to the now common business of sending documents by email between computers, a single document may result in multiple different documents or versions stored on one or more different computer systems. Backup and restore systems may exacerbate this problem because these systems only take snapshots of existing documents-the documents are then often updated or changed and these new versions are also saved without references or indexes to earlier versions. In addition, when a user copies a document on a network server to a local computer system, such as a laptop or other off-network computer system, the network-controlled file maintenance system may not be able to perform routine deletion or other file maintenance operations. These factors may combine to increase the complexity of document management and the maintenance of Information Technology (IT) administrators.

Drawings

In order to facilitate a more complete understanding of the present disclosure, reference will now be made to the accompanying drawings, in which like elements are represented by like reference numerals. These drawings should not be construed as limiting the present disclosure, but are intended to be exemplary only.

FIG. 1 is a schematic diagram of an exemplary public key encryption-based system for document retention in accordance with at least one embodiment of the present disclosure;

FIG. 2 is a flow diagram of an exemplary method of saving a document in a public key encryption based system for document retention in accordance with at least one embodiment of the present disclosure;

FIG. 3 is a flow diagram of an exemplary method of accessing encrypted documents stored in a data store using a public key encryption based system for document retention in accordance with at least one embodiment of the present disclosure;

FIG. 4 is a block diagram illustrating exemplary components of a public key encryption based document retention interface program for interfacing between a client application, a token/key encryption server, and a data server in accordance with at least one embodiment of the present disclosure; and

fig. 5 is an exemplary token/key encryption table illustrating document destruction policy information according to at least one embodiment of the present disclosure.

Detailed Description

The following description is intended to convey a thorough understanding of the embodiments described by providing a number of specific embodiments and details relating to document retention and management based on public key encryption. It should be understood, however, that the present disclosure is not limited to these specific embodiments and details, which are exemplary only. It is further understood that one possessing ordinary skill in the art, in light of known systems and methods, would appreciate the use of the invention for its intended purposes and benefits in any number of alternative embodiments, depending upon specific design and other needs.

As used herein, the term "document" will be used to refer to an electronic file. A user application is a program that can be used to create a document. For example, a document may be created in a user application (such as a text editor, a word processing application, a spreadsheet application, a presentation program, a portable document application, a database, etc.).

Referring now to fig. 1, a schematic diagram of an exemplary public key encryption-based system 10 for document retention is depicted in accordance with at least one embodiment of the present disclosure. The exemplary system 10 of FIG. 1 may include a computer system 100, the computer system 100 including one or more user applications 110, which one or more user applications 110 may be used in various embodiments to create, access and modify electronic documents, an interface program that serves as an interface between the one or more user applications 110, and a retention system component when documents of the electronic type are to be saved or accessed. The system 10 may also include an Operating System (OS)130, the OS 130 including an access driver 132 and a communication stack 134. The system 10 may also include a key/token server 140 and one or more data storage devices 150. It should be appreciated that the one or more data storage devices 150 may include a network-based storage device, a local storage device, or a file management system.

In an exemplary embodiment, the interface program 120 (referred to herein in some cases as a "shim") may be automatically invoked when a user attempts to save a document from the user application 110. The interface program 120 may then obtain destruction information regarding the destruction policy for the current document and, using the operating system's communication stack 134, may obtain an encryption key for encrypting the document. Using the operating system's access driver 132, the interface program 120 may save the document on the data storage device 150 as an encrypted document with a pointer in the document in the header that points to the key on the key/token server 140. The key length may be any suitable length. The various embodiments of the system do not depend on a particular length. If the key is owned in a very good privacy (PGP) environment, the key may be 4096 bits long. When the user application 110 subsequently attempts to gain access to the encrypted document from the data store 150, the interface program 120 may be automatically invoked, and after reading the appropriate pointer information from the document header, the interface program 120 may request the key from the key/token server 140. If the key is still valid, i.e., the key has not exceeded the validity period specified in the destruction policy, the key may be returned to the shim so that the document can be decrypted and viewed by the requesting application. Otherwise, if the key for the document has expired, the interface program 120 may send a message to the requesting application indicating that the document is no longer available and/or has been corrupted.

Fig. 2 is a flow diagram of an exemplary method of saving a document in a public key encryption based system for document retention according to at least one embodiment of the present disclosure. The operation of the method begins at block 200. At block 205, a document save operation is requested. In various embodiments, the document save operation may be initiated by a user submitting a save command to a user application via a user interface. In other embodiments, the document save operation may be initiated automatically, for example, by an automatic save operation performed by a user application and/or whenever a new document is created.

In block 210, a user interface program may be automatically invoked in response to the received save request. In an exemplary embodiment, the user interface program, or shim as sometimes referred to herein, may comprise a relatively small (compared to the size of the user application) software program that is the operating system of the user's computer system 100 requesting the application to run thereon, enabling it to invoke operating system components such as the communication stack 134 and access driver 132. Thus, the shim may run on a server computer, and/or the shim may run locally on each user's computer in a network or other distributed computing environment. In this manner, document control may be maintained regardless of whether the documents are stored locally or on a centralized server. Additionally, in an exemplary embodiment, the shim may detect a request by an application, such that the shim may not need to modify the user application itself to utilize the various systems and methods described in the present disclosure.

In block 215, for example, the interface program 120 may obtain the destruction information for the document by obtaining one or more rules related to the destruction of the current document. The destruction information may be obtained via user input, i.e., the user may be prompted to enter one or more pieces of information related to the destruction of the document, such as a destruction policy. Additionally, the user may be prompted to select one or more entries from the pre-populated list of destruction information and/or destruction policies. Alternatively, or in addition, the destruction information may be obtained from a previously specified destruction policy and/or a default policy. For example, the interface program may access a default destruction policy, such as deleting a document five years later. Alternatively, there may also be policies specified for documents relating to particular business units, people, teams, etc. The destruction policy may be applied to documents of a particular type, category, time period, or other criteria. In addition, the breach information may be obtained via an electronic request from the interface program 120 to the key server 140. As discussed herein, "destruction" of a document is effected by destroying the key of the document. Once a key is destroyed, it is not possible to open/read any document created with that key. Thus, the document is unreadable after the key expires, regardless of where it is located.

In block 220, the document may be stored in a designated storage device based on the destruction information. In an exemplary embodiment, the document may be encrypted and any unencrypted versions may be deleted at the same time. In addition, the document may preferably include a pointer to a key on the key server 140 that can be used to decrypt the document when it is later accessed, as long as the key is available. The exemplary method of fig. 2 may be performed each time a document is first saved, either locally or on a network-based server.

Additionally, it should be understood that the techniques described in FIG. 2 may be applied to already existing documents that have not previously been subjected to the techniques. For example, if a save operation is requested, the interface program may be invoked to determine whether the current document includes a pointer to the encryption key. If so, the document is saved in encrypted form as described in the context of block 200. Otherwise, the steps beginning in block 215 may be performed to "migrate" the document to a document retention system, in accordance with various embodiments of the present invention.

Referring now to fig. 3, a flow diagram of an exemplary method for accessing encrypted documents stored in a data server using a public key encryption based system for document retention is depicted in accordance with at least one embodiment of the present disclosure. The operation of the method starts in step 300. In step 305, an interface program may be invoked. In various embodiments, step 305 is performed by a user request via an interface of a user application to access documents stored in storage device 150. In an exemplary embodiment, the interface program 120 may be automatically invoked when such a document access request is received.

In block 310, the interface program 305 may request a document from a data storage device (such as the data storage device 150 in FIG. 1). In various embodiments, this step may include requesting the document by using an access driver 132 (shown in FIG. 1) of the operating system 130. As described above, data storage device 150 may be located in the same computer system that is running the requesting application, e.g., computer system 100 in FIG. 1. Additionally, for example, data storage device 150 may be remote when access to documents stored on a web server is requested.

In block 315, after retrieving the requested document, the interface program 120 may read an encryption key identifier, which may preferably be located in a document header of the encrypted document. In various embodiments, the encryption key identifier may point to a file, index, or other addressable data structure on a key server (such as key server 140 in FIG. 1). It should be appreciated that for documents that are not stored in accordance with the various systems and methods disclosed herein, i.e., documents that are not encrypted, the remaining blocks of the method of FIG. 4 are optional, as the retrieved documents may be provided directly to the requesting user application.

In block 320, the interface program 120 may request the encryption key identified in the document from the key server 140. The key server 140 may be located in a different physical location relative to the interface program 120, so long as the key server 140 is accessible remotely (i.e., over a communications network). At step 325, it may be determined whether the key is valid, which in turn may indicate whether the current document is corrupt and, therefore, no longer accessible. According to at least one embodiment, the determination may be based on the presence/absence of an encryption key for the current document. If, in block 325, no key is returned from the key server, the interface program may return a "document no longer available" message to the requesting application. In at least one embodiment, a message and/or pop-up screen may be presented to the user indicating that the requested document is no longer available or has been destroyed. Otherwise, if in block 325 the key server returns a key, operation may proceed to block 335 where the document may be decrypted by using the provided key and the decrypted document presented to the user via the interface of the requesting application.

Referring now to fig. 4, a block diagram illustrating exemplary components of a public key encryption based document retention interface program 120 for interfacing between a client application, a token/key encryption server, and a data server is depicted in accordance with at least one embodiment of the present invention. As discussed above, in various embodiments, the program 120 may be installed on a user computer system (such as the computer system 100 in FIG. 1). In addition, the program 120 may be stored on one or more centralized, networked computer systems. Program 120 may include various modules that may provide functionality for one or more user applications to save encrypted documents to access the encrypted documents and facilitate organized, centralized document retention and destruction. In the example of fig. 4, there is an application interface module 122, an Operating System (OS) interface module 124, a token/key server interface module 126, and a data store interface module 128. It should be appreciated that although in some exemplary embodiments each module may comprise a component of a software-based program, each module may also be configured as a separate software application running on computer hardware, one or more Application Specific Integrated Circuits (ASICs), a combination of hardware and software, or other suitable configurations. Further, one or more modules may be combined or divided into multiple additional modules. In addition, additional and/or different modules than those shown in FIG. 4 may be utilized.

In various embodiments, the application interface module 122 may include one or more Application Program Interfaces (APIs) for interfacing with one or more user applications. As discussed above, the application interface module 122 may be automatically invoked whenever a compatible user application requests a document and/or attempts to save a document. In addition, the application interface module 122 may receive document save and document access requests from one or more compatible user applications.

Operating System (OS) interface module 124 may allow interface program 120 to access one or more data stores and key/token servers using the OS's existing communication stack and access server. In various embodiments, the OS interface module 124 may be dedicated to a particular operating system, such as, for example, WINDOWS, LINUX, MAC OS, or other suitable operating systems. In other embodiments, the OS interface module 124 may be used with multiple different operating systems, i.e., the OS interface module 124 may include program code that performs redundant communication functions with multiple different operating systems.

The token/key interface module 126 may interface with a local and/or remote cryptographic key server, such as the key server 140 in fig. 1. For example, during a document storage operation for a newly created document, the interface program 120 may utilize the token/key interface module 126 to access the key server 140 to obtain encryption key information for the document to be saved. As discussed above, the key server may provide information identifying a destruction policy for the current document, may prompt the user for such information, and/or may use a default set of policy information. In addition, other document profile fields specified by the user may be used to determine an appropriate destruction policy.

As another example, in a document access operation, token/key interface module 126 may read key identification information from a requested document (such as a header portion of a retrieved encrypted document) and communicate this information to key server 140 to determine whether the key is still valid. If the key is still valid, the token/key interface module 126 may receive the key to be used in decrypting the requested document. Otherwise, the token/key interface module 126 may receive an indication from the key server that the key is unavailable. If no key is returned, the token/key interface module 126 may assume that no key is available and thus indicate to the user application that the requested document is no longer available.

It should be understood that the particular modules shown in fig. 4 are merely exemplary and should not be construed as being necessary or exhaustive. In various embodiments, it may be desirable to use more, fewer, or even different modules than those shown in FIG. 4.

Referring now to FIG. 5, an exemplary token/key encryption table 400 is depicted illustrating document destruction policy information in accordance with at least one embodiment of the present invention. It should be appreciated that although the various encryption keys/policies are stored in a single table/file 400 in the example of fig. 5, in other embodiments, one or more encryption keys/policies may be stored in a separate data structure. In various embodiments, one or more policies may be defined through a separate user interface through which a user specifies an encryption key, a policy name, a date of destruction, and/or a policy owner (i.e., an organization, a person, and/or a responsible entity). In the example of FIG. 5, there are two active destruction policies-billingrecords-2001 and merger policy, owned by the financial chief executive (CFO) and the counselor (GC), respectively. Because the destruction date of 01/01/2004 has passed, there is also an inactive (inactive) policy of key loss entitled "cloning records-1999". Thus, if a document is requested that includes a pointer to the balling records-1999 policy, the key server will not return an encryption key. Thus, regardless of where the document may be stored, the document will no longer be accessible.

A feature of various embodiments of the present disclosure is that by specifying the encryption key at the time of document creation, all subsequent versions will be effectively destroyed, i.e., rendered inaccessible according to a specified destruction policy. Another feature is that destruction of multiple different documents can be controlled by a single destruction policy, i.e., not just different versions of the same document, but unique documents that are related to the same policy owner. For example, if one or more persons working on a particular project in a company/business/organization or the like work on multiple series of documents related to the same project, a single retention policy may be specified for the documents related to the project. Each time a new document is created that is related to a project, the user may select a corresponding policy, or the policy may be automatically selected based on other document identification fields provided by the user.

In the foregoing specification, various exemplary embodiments have been described with reference to the accompanying drawings. It will, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that follow. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims (7)

1. A method for document control using public key encryption, comprising:

saving a document from an application to an electronic storage medium in response to a user save command entered into the application;

receiving at least one rule regarding a disruption to the document;

storing the document in encrypted form with a pointer to a decryption key of the document on an encryption key server;

providing the decryption key to a requesting application in response to at least one of the document and a subsequent version of the document being subsequently opened, so long as the decryption key remains valid in accordance with the at least one rule; and

destroying the decryption key in accordance with the at least one rule, wherein the at least one rule specifies expiration dates of decryption keys for the document and subsequent versions of the document.

2. The method of claim 1, further comprising: after storing the document in encrypted form, the unencrypted document is destroyed.

3. The method of claim 1, wherein saving the document comprises: and calling an encryption interface program.

4. The method of claim 3, wherein receiving at least one rule regarding the destruction of the document comprises: at least one rule input from a user to the cryptographic interface program is received.

5. The method of claim 3, wherein receiving at least one rule regarding the destruction of the document comprises: receiving at least one rule input from the cryptographic key server.

6. The method of claim 1, wherein storing the document comprises: storing the document destruction date in association with the decryption key of the document on the encryption key server.

7. The method of claim 6, further comprising: destroying the decryption key on the document destruction date, thereby rendering the document unusable.