The present invention relates generally to securing documents and, more particularly, to a method and system for document rights management, file encryption, Digital signing of email/Documents and secure deletion of documents
Currently, a number of software-only, hardware-only and software-hardware combination security related products are on the market. They are meant to protect data in electronic documents from unauthorized modification, and to prevent data theft during document transmission over electronic channels. All these tools protect data from outsiders who try to gain unauthorized access to sensitive data, and not from companies' employees. In the meantime, there is a need to prevent both intentional and accidental data leaks from employees' desktops. The most important question is how to protect data from exploitation by authorized users. Protection from intentional and accidental data leaks means most for companies, where such information is of great value, and its leakage can lead to financial losses, as well as credibility losses.
Therefore, what is needed is a system and method that provides secure and efficient document rights management.
The present disclosure provides a system and method that provides secure and efficient document rights management.
Therefore, in accordance with the previous summary, objects, features and advantages of the present disclosure will become apparent to one skilled in the art from the subsequent description and the appended claims taken in conjunction with the accompanying drawings
The present disclosure can be described by the embodiments given below. It is understood, however, that the embodiments below are not necessarily limitations to the present disclosure, but are used to describe a typical implementation of the invention.
The present disclosure can be described by the embodiments given below. It is understood, however, that the embodiments below are not necessarily limitations to the present disclosure, but are used to describe a typical implementation of the invention.
Author is a person who creates, modifies, and distributes a document, and is responsible for defining usage rights for each of the document's recipients.
Recipient is a person who makes use of the information given in the document created by Author, to the extent limited by the rights set by Author.
CA—Certification Authority.
COTS—Commercial off the Shelf
RUP—Rational Unified Process.
DOD—Department of Defense.
DRM—Digital Rights Management.
IIS—Internet Information Services.
DLL—Dynamic-Link Library.
The invention allows for secure communication and documents exchange between single users and personnel of small companies with undeveloped documents workflow. There are two types of users described in the preferred embodiment—Document Authors and Document Recipients.
Author has the following use cases:
Recipient has the following use cases:
Upon request users may be supplied with a library (Module) to digitally sign web forms, and to verify digitally signed web forms. Shipping will be presumably done in two distinct versions, the server and the workstation client.
The users of both the Essential Security Suite Product and the Essential Security Reader will have the ability to Contact Essential Security Software to revoke their Digital Certificate.
Users can Revoke their Certificate if:
The system provides for secure document exchange between single users. A feature that makes the system stand out when compared to competing COTS software is digital rights management. The freedom of Recipient's actions with a protected document may be limited in any way the Author wants. Furthermore, an additional layer of document protection from unauthorized distribution (e.g. by copying, taking a print screen, printing, or email forwarding) is included in the system. This additional layer binds a document to the Recipient's computer via a passport making it impossible to view or copy information on any other media or computer. (See
A graphic representation of the protected document is sent to the recipient, instead of the documents proper. This approach is used if the recipient does not have rights to edit the document, or copy any of its contents into the clipboard. The system uses an image viewing software (Essential Security Reader) (See
There are at least two versions of the software: a commercial version, used by the Author; and a limited version called Essential Security Reader, used by the Recipient.
The Essential Security Suite includes the following functionality:
The Essential Security Reader will have the following functionality:
The minimum system requirements for running Essential Security Suite:
The algorithm used for document encryption is RC4—a symmetric encryption stream algorithm included in the MS Windows CyryptoAPI
Any standard document may be selected from the main window of the commercial version of the software by a plug-in to the parent application, or by an Explorer plug-in for already created documents.
To initiate the document selection function from the main window or from the plug-in to the parent application, the user selects the File→Open menu.
To initiate the function from Explorer (as a plug-in), the user selects a file or a folder, and then selects Restrict Rights from the right-click context menu.
In either case, the user is presented with the Document Recipients window upon function initiation.
Create Document Recipients List
This function is initiated after the Document Recipients window becomes active. This function displays two lists: locally registered certificates—names of their owners constitute the list of potential document recipients; and selected document recipients. When a recipient is selected from the first list, he/she is then added to the list of actual recipients and removed from the potential recipients list.
In addition, a <<Delete>> mode for removing recipients from the list is included in the system. The mode is activated by clicking the <<Delete>> or by choosing <<Delete>> from the drop-down menu if the user selected the recipient's entry in the list and right-clicked it.
The user can also select groups of recipients in the conventional way, by holding Control and clicking on user names. Selected entries are highlighted by a different color.
For every chosen recipient or chosen group, limitations can be set for allowed document actions. This mode is called by selecting Restrict Document on the menu or by choosing Restrict Document from username right-click context menu. However, the system does not query for recipient rights to files that are not documents or can not be presented as an image corresponding to the document's printable image (AVI, MP3, etc.). Files that are not documents or can not be presented as an image can be encrypted and signed with full rights assigned. The selecting of other use rights is disabled.
Set Document Usage Rights
This function begins by activating the Usage Rights window. The user may choose from the following options: (See
The Recipient by default has viewing rights, as those are the minimal privileges.
The rights are to split in two alternative groups: one for full rights; and a second for a subset of full rights. An example of the window is illustrated in
After defining the rights of the recipients, they are grouped in two lists: a list of recipients with Full Rights; and a list of recipients with Forwarding rights, Printing rights, Print Screen rights, and/or Date Restrictions. For Full Rights, additional processing is not performed before encryption. For the other rights, a graphic image to indicate the system is processing is displayed.
When the recipient opens the encrypted and signed email or document the certificate is displayed verifying the signature. (See
For e-mail letters created in MS Outlook or MS Outlook Express, recipient rights do not have to be defined. If rights are not defined, then all recipients are considered to have full rights and the letter is not encrypted. In this embodiment, attachments to e-mail letters in Outlook are not modified, unless the user directs otherwise. If the user wants to restrict rights on the attachment, the user must first process it as a usual restricted file and then attach to the e-mail letter.
For an e-mail with restricted rights, the letter body is extracted and placed unto a text file named EMailBody.txt; a standard phrase <<The letter body has been encrypted and placed in the attached file EMailBody.txt>> is then inserted. Processing of the EMailBody.txt file is the same as for the other restricted files.
Automated Document-To-Image Conversion
This function includes creating a page-by-page BMP image of the document corresponding to the printed output image of the document from the parent program (i.e. the program with which the document was initially created). The conversion is similar to printing the document to a BMP file or a printer, and displays the progress. In this embodiment, this function is called only when a selected file has a parent program installed.
If the document does not contain the printer's page properties, defaults are used. However, an option is the have the user specify those as well (page size, margin width, portrait/landscape, etc).
Default page properties are: Letter sized paper; top, bottom and left margins are 1 inch wide, right margin is 0.5 inch wide; color settings—black and white; and resolution of 300 DPI.
The user can specify at least the following values: Page size; Document color (black-and-white, grayscale, full color); and Resolution in DPI.
When BMP images are being generated, a progress bar along with default page properties are shown.
Digitally Sign and Encrypt a File or Folder
Signing and encrypting is initiated by the user and can be executed by the following document access options:
After the user initiates the sign and encrypt function, a window is displayed containing a list of registered certificates of the document's author. The user can select the necessary certificate for signing the document or cancel the operation. Signing is performed by calling corresponding MS Windows Crypto API functions. A Progress Bar is displayed as the encryption proceeds.
For graphical images of documents every page is signed separately. The system also provides different options for the user to customize the encryption techniques and keys. Encrypted document bodies are placed in a crypto container. Folders that are encrypted and signed are first zipped, then encrypted and signed in the usual way.
Furthermore, every recipient has a symmetric session key used for encrypting the document body and the set of the given user's rights. This information is encrypted using the given recipient's public key. The information is then encrypted again using a unique symmetric key formed from the computer's passport. The data stream received after the second encryption is then placed into a crypto container. The crypto container is then ready for delivery by any means.
Generate the Document Recipient's Passport
This function is activated as a stand-alone application or as a plug-in for Explorer. When the function is called, the software gathers at least the following information about the user's computer: BIOS version number; Video card BIOS creation date; and Primary HDD serial number. (See
The gathered data is combined into a data flow that is signed by the recipient's digital signature; then the recipient's certificate is added to them to form the final entity that is called Document Recipient's Passport, and saved as a binary file. (See
The system also allows the Recipient to possess several certificates issued by different certification authorities, by displaying the list of personal certificates and allowing the user to choose the appropriate one. The passport is then passed to the document's author for later use. The user will be given the option to designate a default certificate.
Decrypt Document on Open, Verify Digital Signature and Document Integrity
Depending on the file type and its method of processing, this function can be activated in the following ways:
The decryption process is the reverse of the creation of a forwarding-ready crypto container. The decryption begins by forming the recipient computer's passport from the following information: BIOS version number; Video card BIOS creation date; and Primary HDD serial number.
From the passport, a symmetric key is built and an attempt to decrypt one of the sets attached to the document is carried out (every set contains the encrypted symmetric session key used for encrypting the document body and the given user's set of rights.)
If the processing fails to yield a decrypted set of a symmetric session key and recipient rights, the message <<The document may not be decrypted on this computer>> is displayed, after which the program terminates.
If the processing produces a decrypted set of a symmetric session key and recipient rights, this data is then placed in a closed area of the Decrypt class and may not be copied to external media under any circumstances.
The system then starts to verify the document author's signature and document integrity. The integrity of the page and its digital signature is then verified using the decrypted session key the first page of the document (or the entire document, if the rights did not include creating graphical images) and, by using the Crypto API.
If the signature does not pass the verification, the <<File is signed by unknown person>> message is displayed.
If hashing indicated file integrity violation, the <<File corrupted in transfer>> message is displayed.
If signature verification or hashing terminates with an error message, further processing of the file is stopped. However, if signature verification or hashing is successful, the <<Verification successful>> message and the information on the person who signed the document is displayed.
An example of a window displaying the certificate data of the signing person is illustrated in (See
Further actions of the recipient are limited by the function Restrict recipient's actions in accordance with defined rights as defined below.
Restrict Recipient's Actions in Accordance with Defined Rights
This function is called automatically after normal termination of decrypting the symmetric session key used for encrypting the document body and the set of the given user's rights. Depending on the user rights he/she is allowed to either save the document on an external media (HDD, CD, etc. . . . ), or open it for viewing and printing.
The <<full rights>> option enables the user to save the document to external media by automatically decrypting the file. If the document is an encrypted folder, it is decrypted and then unzipped to a path specified by the user. Normally decrypted files are also saved to a path specified by the user.
At this point, the system allows the user to call up the necessary program for editing, copying, printing any number of copies, or listening to and viewing the decrypted document.
Document's Graphical Representation Viewing Rights
The options of Forwarding rights, Printing rights, Print Screen rights, Limit document usage dates are controlled by the function Document graphical representation viewing rights. This function is called automatically for documents with limited user rights. The interface of the function is unified with the Essential Security Reader program. The Essential Security Suite includes the Essential Security Reader. This allows both the Author and the recipient to view documents and emails that have been given usage rights.
This function first calculates how many pages will fit in the navigation part of the screen and decrypts only that amount of pages from the document's graphical representation. The navigation previews and a full-sized first page (further called the current page) are then displayed.
Changing the current page is controlled by selecting a new page in the navigation area by the mouse cursor and double-clicking it. In addition, pressing the <<PageUP>> and <<PageDown>> initiates decryption of the previous or next batch of navigation pages.
If rights allow, the user must be able to print any part of the document. If document usage dates are limited, the following is checked:
Documents are purged securely and permanently (see Guaranteed file purging detailed below for more details).
Web Form Authoring and Verification with Digital Signatures System
The system is intended for authorization of data entered by a user into a web form within some web application and guarantees their protection from any possible tampering. The authorization here means that the data was entered exactly by the same system user who owns the certificate.
This function is called as a plug-in for Internet Explorer version 6.0 and above. This function is initiated when the user is viewing a Web-form and selects Check Sign from the menu. All the values entered are regarded as a data flow that must be subjected to a standard signature verification procedure using the Crypto API functions. The digital signature is treated as an extra service field and added to the previously entered data. The signature is also used by the recipient's side to verify the data integrity. The user can also view the personal information of the person who signed the Web-form.
The function consists of the two following components:
The notary service is implemented as a SOAP Web Service and performs the following commands:
The system makes keys and manages certificates for end users. This function includes:
This function provides secure corporate document storage. It includes the following functionality:
This function provides support for automated document coordination and approval process. It includes the following functionality;
This function monitors all user actions when working with documents. It includes the following functionality:
Guaranteed file purging corresponds to the DoD 5220.22-M standard requirements specification in this embodiment. This function deletes files bypassing the system Recycle Bin procedure. The deleted data is impractical to restore, either partially or wholly.
Cryptographic Kernel
“Both versions of the system perform information encryption/decryption and digital signature forming/checking. The kernel-implemented operation set defines the system cryptographic functionality.
The cryptographic kernel includes two kinds of operations: Basic Stream Operations and file level wrappers.
Basic Stream Operations
Basic stream operations include cryptographic operations on abstract data streams without binding them to their storage and allocation options. The operations include:
Digital signatures are additional information attached to the protected data. They are derived from the contents of the document being signed and is formed with a secret key. Digital signatures are characterized by the following:
These operations manipulate cryptographic objects at the file level. File-level wrappers are based on the crypto container concept. All cryptographic objects, associated with a single original file, are encapsulated into a single file of compound structure (cryptocontainer). These objects include:
A cryptocontainer is stored in the same folder as the original file. Its name is modified by attaching an additional extension, which prevents incorrect file processing on systems where the product is not installed.
The following functionality is also included in the commercial version:
The above functionality add the following operations:
The transparency subsystem extending the system functionality. The transparency subsystem provides a way to process encrypted and signed files without any additional user actions. When someone tries to access a file, the subsystem reproduces the file's original state in some separate buffer space, grants the user access to the file located in this space and later purges the buffer space, reflecting all changes done to the file there into the actual file. Any action this subsystem takes does not change the file's cryptographic state (except for purging all digital signatures if the file was modified).
Thus, from the point of view of this subsystem, there are three file categories:
To support the transparent file processing logic, simultaneous existence of the original file and corresponding cryptocontainer is considered a conflict, which should be resolved by the user's choice of which of the files should be considered the actual file. From the point of view of most applications, cryptocontainers are hidden, while virtual files are indistinguishable from original files.
In this embodiment, all standard applications which require transparent file access have their entries in the system registry. For these applications, opening an encrypted and signed file will always mean verifying its integrity, signatures and then decryption; likewise, when the file is closed, it is encrypted and all present signatures are voided if the file has been modified. For applications with no associated extensions, transparent access to encrypted files is not provided.
The system includes the following transparency functions:
In order to more clarify the invention, the following describes more details of the invention as described through the figures.
It is understood that several modifications, changes and substitutions are intended in the foregoing disclosure and in some instances some features of the invention will be employed without a corresponding use of other features. Accordingly, it is appropriate that the appended claims be construed broadly and in a manner consistent with the scope of the invention.
Number | Name | Date | Kind |
---|---|---|---|
4027243 | Stackhouse et al. | May 1977 | A |
4393269 | Konheim et al. | Jul 1983 | A |
4477809 | Bose | Oct 1984 | A |
4484355 | Henke et al. | Nov 1984 | A |
4530051 | Johnson et al. | Jul 1985 | A |
4545071 | Freeburg | Oct 1985 | A |
4707592 | Ware | Nov 1987 | A |
4709136 | Watanabe | Nov 1987 | A |
4799156 | Shavit et al. | Jan 1989 | A |
4947028 | Gorog | Aug 1990 | A |
4955049 | Ghisler | Sep 1990 | A |
5020093 | Pireh | May 1991 | A |
5053606 | Kimizu | Oct 1991 | A |
5099420 | Barlow et al. | Mar 1992 | A |
5220564 | Tuch et al. | Jun 1993 | A |
5283639 | Esch et al. | Feb 1994 | A |
5412416 | Nemirofsky | May 1995 | A |
5426427 | Chinnock et al. | Jun 1995 | A |
5475819 | Miller et al. | Dec 1995 | A |
5483596 | Rosenow et al. | Jan 1996 | A |
5600364 | Hendricks et al. | Feb 1997 | A |
5604542 | Dedrick | Feb 1997 | A |
5638513 | Ananda | Jun 1997 | A |
5655077 | Jones et al. | Aug 1997 | A |
5675507 | Bobo, II | Oct 1997 | A |
5684950 | Dare et al. | Nov 1997 | A |
5689638 | Sadovsky | Nov 1997 | A |
5721780 | Ensor et al. | Feb 1998 | A |
5802304 | Stone | Sep 1998 | A |
5862339 | Bonnaure et al. | Jan 1999 | A |
5884024 | Lim et al. | Mar 1999 | A |
5889958 | Willens | Mar 1999 | A |
5892900 | Ginter et al. | Apr 1999 | A |
5896444 | Perlman et al. | Apr 1999 | A |
5898780 | Liu et al. | Apr 1999 | A |
5898839 | Berteau | Apr 1999 | A |
5913040 | Rakavy et al. | Jun 1999 | A |
5918013 | Mighdoll et al. | Jun 1999 | A |
5935207 | Logue et al. | Aug 1999 | A |
5940074 | Britt, Jr. et al. | Aug 1999 | A |
5950010 | Hesse et al. | Sep 1999 | A |
5974461 | Goldman et al. | Oct 1999 | A |
5983273 | White et al. | Nov 1999 | A |
6023585 | Perlman et al. | Feb 2000 | A |
6023698 | Lavey, Jr. et al. | Feb 2000 | A |
6026079 | Perlman | Feb 2000 | A |
6061798 | Coley et al. | May 2000 | A |
6070192 | Holt et al. | May 2000 | A |
6073168 | Mighdoll et al. | Jun 2000 | A |
6128663 | Thomas | Oct 2000 | A |
6134590 | Perlman | Oct 2000 | A |
6138119 | Hall et al. | Oct 2000 | A |
6141694 | Gardner | Oct 2000 | A |
6178505 | Schneider et al. | Jan 2001 | B1 |
6185685 | Morgan et al. | Feb 2001 | B1 |
6289450 | Pensak | Sep 2001 | B1 |
6311197 | Mighdoll et al. | Oct 2001 | B2 |
6571290 | Selgas et al. | May 2003 | B2 |
6721784 | Leonard et al. | Apr 2004 | B1 |
6824051 | Reddy et al. | Nov 2004 | B2 |
6990684 | Futamura et al. | Jan 2006 | B2 |
7143296 | Hirata | Nov 2006 | B2 |
7149893 | Leonard | Dec 2006 | B1 |
7290285 | McCurdy et al. | Oct 2007 | B2 |
7310821 | Lee et al. | Dec 2007 | B2 |
7398556 | Erickson | Jul 2008 | B2 |
7406596 | Tararukhina et al. | Jul 2008 | B2 |
7418737 | Grupe | Aug 2008 | B2 |
7472280 | Giobbi | Dec 2008 | B2 |
7590861 | Abdallah et al. | Sep 2009 | B2 |
7870198 | Graham et al. | Jan 2011 | B2 |
8205078 | Bhogal et al. | Jun 2012 | B2 |
8239682 | Meehan et al. | Aug 2012 | B2 |
8290160 | Steeger | Oct 2012 | B1 |
8474058 | Benson et al. | Jun 2013 | B2 |
8677126 | Meehan et al. | Mar 2014 | B2 |
8838704 | Naylor et al. | Sep 2014 | B2 |
9094215 | Meehan et al. | Jul 2015 | B2 |
20010029581 | Knauft | Oct 2001 | A1 |
20020010679 | Felsher | Jan 2002 | A1 |
20020082997 | Kobata et al. | Jun 2002 | A1 |
20020129275 | Decuir | Sep 2002 | A1 |
20030037237 | Abgrall et al. | Feb 2003 | A1 |
20030044012 | Eden | Mar 2003 | A1 |
20030191946 | Auer et al. | Oct 2003 | A1 |
20040003139 | Cottrille et al. | Jan 2004 | A1 |
20040003269 | Waxman et al. | Jan 2004 | A1 |
20040022390 | McDonald et al. | Feb 2004 | A1 |
20040148356 | Bishop et al. | Jul 2004 | A1 |
20050060537 | Stamos et al. | Mar 2005 | A1 |
20050120212 | Kanungo | Jun 2005 | A1 |
20050177873 | Wu et al. | Aug 2005 | A1 |
20050229258 | Pigin | Oct 2005 | A1 |
20070033397 | Phillips, II | Feb 2007 | A1 |
20070050696 | Piersol et al. | Mar 2007 | A1 |
20070067618 | Sandhu et al. | Mar 2007 | A1 |
20130326220 | Connelly et al. | Dec 2013 | A1 |
20160028700 | Meehan et al. | Jan 2016 | A1 |
Number | Date | Country |
---|---|---|
0248403 | Dec 1987 | EP |
0384339 | Aug 1990 | EP |
0421808 | Apr 1991 | EP |
0479660 | Sep 1991 | EP |
0501967 | Sep 1992 | EP |
0506637 | Sep 1992 | EP |
0590861 | Apr 1994 | EP |
0650307 | Apr 1995 | EP |
0745924 | Apr 1996 | EP |
0814589 | Dec 1997 | EP |
2190820 | Nov 1987 | GB |
2289598 | Nov 1995 | GB |
WO-8603926 | Jul 1986 | WO |
WO-9317529 | Sep 1993 | WO |
WO-9600485 | Jan 1996 | WO |
WO-9707656 | Mar 1997 | WO |
WO-9709682 | Mar 1997 | WO |
WO-0197480 | Dec 2001 | WO |
Entry |
---|
Ford et al, “A Key Distribution Method for Object-Based Protection”, ACM, 1994, Retrieved from the Internet on Sep. 10, 2007: <URL: http://delivery.acm.org/10.1145/200000/191225/p193-ford.pdf?key1=191225&key2=0109739811&coll=&dl=acm&CFID=15151515&CFTOKEN=6184618>, pp. 193-197. |
Bott et al, “Microsoft Windows Security Inside Out”, Microsoft Press, 2003, pp. 351-362. |
Microsoft Computer Dictionary, Microsoft Press, 5th Edition, 2002, p. 171. |
Schneider, F.B., “Trust in Cyberspace”, Dec. 1998 ISBN-10:0-309-06558-5; ISBN-13: 978-0-309-06558-0 [retrieved on Jun. 6, 2007]. Retrieved from the internet, URL:http://www.aci/netkalliste/tic.htm.>, pp. 1-249. |
“Authentica Unveils Saferoute for Secure Messaging”, Press Release, Dec. 2002, Retrieved from the Internet on Sep. 10, 2007:<URL:http://www.authentica.com/news/pr2002/12-16-2002-saferoute.aspx>, 2 pages. |
U.S. Appl. No. 15/136,142, Pollet et al. |
U.S. Appl. No. 15/136,154, McCarthy et al. |
Thomas, Shane; “International Search Report” prepared from PCT/US16/28834, as mailed Aug. 30, 2016, 3 pages. |
Number | Date | Country | |
---|---|---|---|
20150244688 A1 | Aug 2015 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 10823042 | Apr 2004 | US |
Child | 14635262 | US |