Source: http://patents.com/us-9542560.html
Timestamp: 2018-12-16 16:00:18
Document Index: 412715049

Matched Legal Cases: ['art 1', 'art 2', 'Application No. 02258532', 'Application No. 02258532', 'Application No. 02258532', 'Application No. 02258532', 'art 1', 'Application No. 60']

US Patent # 9,542,560. Methods and systems for providing access control to secured data - Patents.com
United States Patent 9,542,560
Garcia , et al. January 10, 2017
Garcia; Denis Jacques Paul (Palo Alto, CA), Ouye; Michael Michio (Mountain View, CA), Rossmann; Alain (Palo Alto, CA), Crocker; Steven Toye (Burlingame, CA), Gilbertson; Eric (Menlo Park, CA), Huang; Weiqing (Flower Mound, TX), Humpich; Serge (Tournan-en-Brie, FR), Vainstein; Klimenty (San Francisco, CA), Ryan; Nicholas Michael (Sunnyvale, CA)
Family ID: 1000002338037
14/034,147
US 20140075206 A1 Mar 13, 2014
12057015 Mar 27, 2008 8543827
10074804 May 27, 2008 7380120
Current CPC Class: G06F 21/60 (20130101); G06F 21/6209 (20130101); G06F 21/6218 (20130101); G06F 21/6227 (20130101); H04L 63/04 (20130101); H04L 63/08 (20130101); H04L 63/105 (20130101); H04L 63/12 (20130101); H04L 63/20 (20130101); H04L 67/42 (20130101); G06F 2221/2107 (20130101); G06F 2221/2111 (20130101); G06F 2221/2113 (20130101); G06F 2221/2137 (20130101); G06F 2221/2141 (20130101); H04L 63/101 (20130101); H04L 63/102 (20130101)
Current International Class: G06F 7/04 (20060101); G06F 21/60 (20130101); G06F 21/62 (20130101); H04L 29/06 (20060101)
5693652 December 1997 Takase et al.
5832518 November 1998 Mastors
6754665 June 2004 Kawamoto et al.
6987752 January 2006 Sarraf et al.
7287055 October 2007 Cannata et al.
8543827 September 2013 Garcia et al.
2003/0229795 December 2003 Kunigkeit et al.
2004/0003293 January 2004 Viets et al.
2004/0064507 April 2004 Sakata et al.
2005/0021629 January 2005 Cannata et al.
2006/0011400 January 2006 Thomas
2007/0193397 August 2007 Hwan
2012/0137130 May 2012 Vainstein et al.
WO 01/63387 Aug 2007 WO
"Affect," The American Heritage Dictionary of the English Language, Fourth Edition, Houghton Mifflin Company, 2002. Retrieved May 4, 2006 from http://dictionary.reference.com/search?q=affect, 9 pages. cited by applicant .
Boneh et al., "IBE Secure E-mail," Stanford University, Apr. 8, 2002, http://ctypto.stanford.edu/ibe/, 3 pages. cited by applicant .
Botha et al., "Access Control in Document-Centric Workflow Systems--An Agent-Based Approach," Computers & Security, vol. 20:6, Sep. 2001, pp. 525-532. cited by applicant .
Botha et al., "Separation of Duties for Access Control Enforcement in Workflow Environments," IBM, 2001. cited by applicant .
Curtis, et al., "Securing the Global, Remote, Mobile User," 1999 John Wiley & Sons, Ltd., Int. J. Network Mgmt. 9, pp. 9-21. cited by applicant .
"Encrypting File System," from MSDN Oct. 2001 version, exact publication date is unknown but believed prior to Dec. 12, 2001. cited by applicant .
English language abstract for Japanese Appl. No. Pub. 2001-036517, published Sep. 2, 2001, 1 pg. cited by applicant .
English language translation (unverified, machine-generated) of Japanese Patent Publication No. JP 2006-244044, Japanese Patent Office, Patent & Utility Model Gazette DB, 2006. cited by applicant .
English language translation (unverified, machine-generated) of Japanese Patent Publication No. 2009-020720, Japanese Patent Office, Patent & Utility Model Gazette DB, 2009. cited by applicant .
"eXPeriencing Remote Assistance" Microsoft TechNet--Professor Windows Oct. 2002 Oct. 15, 2002 http://web.archive.org/web/20021015165237/www.microsoft.com/techneUcolumn- s/profwin/, Retrieved from web.archive.org on Dec. 3, 2009. cited by applicant .
"Features of EFS" from MSDN Oct. 2001 version, exact publication date is unknown but believed prior to Dec. 12, 2001. cited by applicant .
"How EFS works," from MSDN Oct. 2001 version, exact publication date is unknown but believed prior to Dec. 12, 2001. cited by applicant .
"Inside Encrypting file system," Part 1, from MSDN Oct. 2001 version, exact publication date is unknown but believed prior to Dec. 12, 2001. cited by applicant .
"Inside Encrypting file system," Part 2, from MSDN Oct. 2001 version, exact publication date is unknown but believed prior to Dec. 12, 2001. cited by applicant .
Juvva et al., "A Real-Time Push-Pull Communications Model for Distributed Real-Time and Multimedia Systems," CMU-CS-99-107, School of Computer Sciences, Carnegie Mellon University, Pittsburgh, PA, Jan. 1999, 25 pages. cited by applicant .
Microsoft Press Computer Dictionary, 1997, Microsoft Press, Third Edition, p. 426. cited by applicant .
Microsoft Windows 2000 server. Windows 2000 Group Policy White Paper, 2000, 137 pages. cited by applicant .
"Migrating Accounts From Windows NT 4.0 Domains to Windows 2000," Microsoft TechNet--Professor Windows Apr. 2002, http://web.archive.org/web/20020415004611/www. m icrosoft.com/tech neticolumns/profwin/, Apr. 15, 2002. cited by applicant .
Copy of Office Action, dated May 10, 2005, for European Patent Application No. 02258532.7, 5 pages. cited by applicant .
Copy of Office Action, dated Oct. 5, 2005, for European Patent Application No. 02258532.7, European Patent Office, 5 pages. cited by applicant .
Copy of Office Action, dated May 12, 2006, for European Patent Application No. 02258532.7, European Patent Office, 5 pages. cited by applicant .
Office Action, dated Dec. 5, 2006, for European Patent Application No. 02258532.7, European Patent Office, 5 pages. cited by applicant .
Search Report, completion date Jul. 6, 2005, for European Patent Application No. EP 02 25 8529, 4 pages. cited by applicant .
"Scripting Your Windows 2000 Network, Part 1" Microsoft TechNet--Professor Windows Jun. 2002, http://web.archive.org/web/20020622055532/www.microsoft.com/techneUcolumn- s/profwin/ Retrieved from web.archive.org on Dec. 3, 2009. cited by applicant .
"Secure Sockets Layer (SSL): How it Works," Verisign, http://www.verisign.com/ssl/ssl-information-center/how-ssl-security-works- , pp. 1-2. cited by applicant .
"Security Options". Dec. 20, 2001. DC & Co. pp. 1-2. cited by applicant .
"WayBack Machine" web.archive.org, http://web.archive.org/web/*/http://www.microsoft.com/technetlcolumns/pro- fwin/, Retrieved on Dec. 3, 2009. cited by applicant .
U.S. Appl. No. 10/074,825, entitled "Method and Apparatus for Accessing Secured Electronic Data Off-line," Lee et al., Feb. 12, 2002. cited by applicant .
U.S. Appl. No. 10/206,737, entitled "Method and System for Updating Keys in a Distributed Security System" (now abandoned), Hildebrand, Jul. 26, 2002. cited by applicant .
U.S. Appl. No. 10/259,075, entitled "Effectuating Access Policy Changes to Designated Places for Secured Files," Crocker, Sep. 27, 2002. cited by applicant .
U.S. Appl. No. 10/286,575, entitled "Method and Architecture for Providing Access to Secured Data from Non-Secured Clients," Vainstein, Nov. 1, 2002. cited by applicant .
U.S. Appl. No. 10/325,102, entitled "Method and apparatus for securing/unsecuring files by file crawling," Prakash, Dec. 20, 2002. cited by applicant .
U.S. Appl. No. 60/475,109, entitled "Method for Enforcing and Managing Usage Rights of Digital Data Objects in Dynamic, Distributed and Collaborative Contexts", Leser et al., Jun. 2, 2003. cited by applicant .
U.S. Appl. No. 10/405,587, entitled "Method and system for securing digital assets using content type designations," Nath, Apr. 1, 2003. cited by applicant .
U.S. Appl. No. 10/448,806, entitled "Method and System for Using Remote Headers to Secure Electronic Files," Ryan, May 30, 2003. cited by applicant.
This application is a divisional of U.S. application Ser. No. 12/057,015, filed Mar. 27, 2008, which is a continuation of U.S. application Ser. No. 10/074,804, filed Feb. 12, 2002, which claims the benefit of U.S. Provisional Application No. 60/339,634, filed Dec. 12, 2001, and entitled "Pervasive Security Systems," which are hereby incorporated by reference in their entireties.
This application is related to U.S. application Ser. No. 10/259,078 filed Sep. 27, 2002 (now abandoned), Ser. No. 10/259,075 filed Sep. 27, 2002 (now abandoned), Ser. No. 10/325,102 filed Dec. 20, 2002 (now abandoned), Ser. No. 10/405,587 filed Apr. 1, 2003 (now abandoned), Ser. No. 10/206,737 filed Jul. 26, 2002 (now abandoned), and Ser. No. 10/159,537 filed May 31, 2002 (now U.S. Pat. No. 7,178,033), which are all incorporated by reference herein in their entireties.
1. A method for securing an electronic document, the method comprising: obtaining an electronic document to be secured; determining a particular electronic document data type corresponding to the electronic document, wherein the electronic document and the electronic document data type are associated with an application; obtaining a data type key associated with the electronic document data type that has been determined; encrypting at least a data portion of the electronic document using the data type key according to a public key encryption algorithm; producing an encrypted document corresponding to the electronic document and storing the encrypted document in an existing database, wherein the encrypted document is associated with the application and is in a format accessible by the application; wherein the data portion of the electronic document can be decrypted using the data type key upon determining that a requester has permission to access the particular electronic document data type of the electronic document.
2. The method as recited in claim 1, wherein the electronic document data type provides a categorization of different types of electronic document content.
3. The method as recited in claim 1, wherein the method further comprises: saving the secured electronic document to a storage device.
4. The method as recited in claim 1, wherein the determining comprises: receiving a selection of at least one of a plurality of available data types.
5. The method as recited in claim 1, wherein the determining comprises: displaying a plurality of available data types; and selecting at least one of the available data types being displayed.
6. The method as recited in claim 5, wherein the displaying and the selecting are performed with the assistance of a graphical user interface.
7. The method as recited in claim 1, further comprising attaching security information to the encrypted data portion, wherein the security information includes the data type key.
8. The method as recited in claim 7, wherein the data type key within the security information is encrypted.
9. The method as recited in claim 1, wherein the encrypting uses an encryption hierarchy, and wherein the data type key is used in at least one level of the encryption hierarchy.
10. The method as recited in claim 1, further comprising imposing at least one data type policy restriction to the encrypted document based on the electronic document data type corresponding to the electronic document.
11. The method as recited in claim 1, wherein the encrypted document maintains the same length as the electronic document.
12. The method as recited in claim 1, wherein the existing database is a financial application database.
13. The method as recited in claim 1, wherein the encrypting further comprises: accessing the electronic document via the application; and automatically requesting, by the application, that the electronic document be encrypted using the data type key.
14. A method for decrypting a secure electronic document, the method comprising: identifying an electronic document to be unsecured for access by a requestor; determining a particular electronic document data type of the electronic document, wherein the electronic document and the electronic document data type are associated with an application; determining whether the requestor has permission to access the particular electronic document data type of the electronic document; obtaining a data type key associated with the electronic document data type when the determining determines that the requestor has permission to access electronic documents having the particular electronic document data type, wherein at least a data portion of the electronic document has been encrypted using the data type key according to a public key encryption algorithm, and wherein the encrypted electronic document is in a format accessible by the application; decrypting at least the data portion of the electronic document using at least the data type key upon determining that the requester has permission to access the particular electronic document data type of the electronic document; and providing at least the unencrypted data portion to the requestor.
15. The method as recited in claim 14, wherein the electronic document data type provides a categorization of different types of electronic document content.
16. The method as recited in claim 14, wherein the secured electronic document includes the data portion and security information, the security information including a reference to the data type key in an encrypted or unencrypted manner.
17. The method as recited in claim 16, wherein the reference to the data type key within the security information is encrypted.
18. The method as recited in claim 14, wherein the decrypting is used to reverse an encryption hierarchy, and wherein the data type key is used in at least one level of the encryption hierarchy.
19. The method as recited in claim 14, wherein the obtaining further comprises obtaining at least one data type policy restriction.
20. The method as recited in claim 19, wherein the at least one data type policy restriction prevents usage of the data type key in specified circumstances.
21. The method as recited in claim 19, wherein the decrypting is prohibited when the at least one data type policy restriction is not satisfied.
22. The method as recited in claim 19, wherein the at least one data type policy restriction is specified by an administrative user.
23. The method as recited in claim 14, wherein the method further comprises: determining, prior to the providing, whether the secured electronic document has at least one data type policy restriction; and requiring that the at least one data type policy restriction is satisfied before at least one of the obtaining, the decrypting, or the providing are performed.
24. The method as recited in claim 23, wherein the at least one data type policy restriction is a rule affiliated with the electronic document data type for the secured electronic document.
25. The method as recited in claim 14, wherein the unencrypted electronic document maintains the same length as the encrypted electronic document.
26. The method as recited in claim 14, wherein the electronic document is stored in an existing financial application database.
27. The method as recited in claim 14, wherein the decrypting further comprises: accessing the encrypted electronic document via the application; and automatically requesting, by the application via a file system driver, that the electronic document be decrypted for use by the application.
28. A computer program product embodied in a non-transitory computer-readable storage medium having computer program logic recorded thereon enabling a hardware processor to secure an electronic document, said computer program code comprising: computer program code enabling a processor to obtain an electronic document to be secured; computer program code enabling the processor to determine a particular electronic document data type corresponding to the electronic document, wherein the electronic document and the electronic document data type are associated with an application; computer program code enabling the processor to obtain a data type key associated with the electronic document data type that has been determined; computer program code enabling the processor to encrypt at least a data portion of the electronic document using the data type key according to a public key encryption algorithm; computer program code enabling the processor to produce an encrypted document corresponding to the electronic document and store the encrypted document in an existing database, wherein the encrypted document is associated with the application and is in a format accessible by the application; wherein the data portion of the electronic document can be decrypted using the data type key upon determining that a requester has permission to access the particular electronic document data type of the electronic document.
The present invention relates to the area of protecting data in an enterprise environment, and more particularly, relates processes, systems, architectures, and software products for providing pervasive security to digital assets at all times.
In one aspect of the present invention, a server module executable in a server computer is configured to provide access control (AC) management for a group of users, software agents, or devices with a need to access secured documents under the access control management. Within the server module, various access rules for the secured documents and/or access privileges for the users or software agents can be created, updated, and managed so that the users, software agents, or devices with the proper access privileges can access the secured documents if granted by the corresponding access rules in the secured documents. According to one embodiment, a secured document includes a header and encrypted data portion. The header includes encrypted security information to control the access to the encrypted data portion. A user key associated with an authenticated user must be retrieved in order to decrypt the encrypted security information. Once the security information becomes available, the access rules are retrieved from the security information and can be measured against the access privileges of the user who is accessing the secured document. If such measurement succeeds, a file key is retrieved from the security information and used to decrypt the encrypted data portion, subsequently, a clear version of the secured document is made available to the user.
In another aspect of the present invention, the AC management is performed in a distributed fashion. A number of local server computers are employed to operate largely on behalf of a central server responsible for the centralized AC management. Such a distributed fashion ensures the dependability, reliability, and scalability of the AC management undertaking by the central server. According to one embodiment, a cache version of the server module is loaded and executed in a local server. As a result, it is not necessary for a client machine to have live consultation with the central server when accessing secured documents. In fact, the secured documents can still be accessed even if the central server is down or a connection thereto is not available.
In still another aspect of the present invention, the local version for a local server can be dynamically reconfigured depending on a user's current location. According to one embodiment, a local version for a local server is so configured that it only services the users, software agents, or devices that are local to the local server or have previously been authenticated by the local server. When a user moves from one location to another location, upon detecting a new location of the user who has moved from a previous location, a local version for the new location is reconfigured to add support for the user while at the same time a local version for the previous location is reconfigured to remove support for the user. As a result, the security is enhanced while the AC management can be efficiently carried out to ensure that only one access from the user is permitted at any time across an entire organization, regardless of how many locations the organization has or what access privileges the user may be granted.
In still yet another aspect of the present invention, the format of the secured document is so designed that the security information of a document stays with the document being secured at all times. As such, this integrated mechanism facilities the transportation of secured documents to other locations without the loss of the security information therein and/or creating difficulty of accessing the secured documents from the other locations. According to one embodiment, a secured file or secured document includes two parts: an attachment, referred to as a header, and an encrypted document or data portion. The header includes security information that points to or includes the access rules and a file key. The access rules facilitate restrictive access to the secured document and essentially determine who/when/how/where the secured document can be accessed. The file key is used to encrypt/decrypt the encrypted data portion. Only those who have the proper access privileges are permitted to retrieve the file key to encrypt/decrypt the encrypted data portion. Depending on an exact implementation, the header may include other information (e.g., a flag, a signature, or version number) to facilitate the detection of the security nature of the document. Alternatively, the two parts, encrypted security information and the encrypted data portion, may be encrypted again to be a secured file or secured document.
FIG. 3 shows an exemplary implementation 300 of how a document securing module (DSM) 302 interacting with and operating within an operating system 304 (e.g., Windows 2000.RTM.) to ensure that a document is made secure in a manner that is transparent to the user;
FIG. 5B.5 shows a flowchart of a server assisted process of securing a document according to one embodiment, and shall also be understood in conjunction with FIG. 3.
The present invention is related to processes, systems, architectures, and software products for providing pervasive security to digital assets at all times. In general, pervasive security means that digital assets are secured at all times and can only be accessed by authenticated users with appropriate access privileges. The present invention is particularly suitable in an enterprise environment.
Digital Asset--defines a type of electronic data that includes, but is not limited to, various types of documents, multimedia files, streaming data, dynamic or static data, executable code, images, and texts.
Secured file, or secured document--defines a type of digital asset that cannot be accessed without a priori knowledge. Example of a priori knowledge may include, but not be limited to, a password, a secret phrase, biometric information or one or more keys.
In another setting, the computer 100 and the computing or storage device 102 are inseparable, in which case the computing or storage device 102 may be a local store to retain secured documents or receive secured network resources (e.g., dynamic Web contents, results of a database query, or a live multimedia feed). Regardless of where the secured documents or secured sources are actually located, a user, with a proper access privilege, can access the secured documents or sources from the computer 100 or the device 102 using an application (e.g., Internet Explorer.RTM., Microsoft Word.RTM., or Acrobat Reader.RTM.).
The server machine 104, sometimes referred to as a local server, is a computing device coupled between a network 108 and the network 110. According to one embodiment, the server 104 executes a local version of a server module of a linked and compiled version of one embodiment of the present invention. As will be detailed below, a local version is a localized server module configured to service a group of designated users or client computers, or a location. Another server machine 106, also referred to as a central server, is a computing device coupled to the network 108. The server 106 executes the server module and provides centralized access control (AC) management for an entire organization or business. Accordingly, respective local modules in local servers, in coordination with the central server, form a distributed mechanism to provide a distributed AC management. Such distributed access control management ensures the dependability, reliability, and scalability of centralized AC management undertaken by the central server for an entire enterprise or a business location. As will be further explained below, the server module in the central server maintains or interfaces to a database that includes, but is not limited to, a list of users and corresponding access privileges for the entire organization or business and rules for folders or files, while a local module can be configured to maintain or interface to a portion or whole of the database, hence, servicing a group of users local to the local server.
FIG. 1D shows internal construction blocks of a computing device 118 in which one embodiment of the present invention may be implemented and executed. The device 118 may correspond to a client device (e.g., computer 100, 102 in FIG. 1A and FIG. 1B or computer 116 in FIG. 1C) or a server device (e.g., server 104, 106 in FIG. 1A and FIG. 1B or server 112 in FIG. 1C). As shown in FIG. 1D, the device 118 includes a central processing unit (CPU) 122 interfaced to a data bus 120 and a device interface 124. CPU 122 executes instructions to process data and perhaps manage all devices and interfaces coupled to data bus 120 for synchronized operations. The instructions being executed can, for example, pertain to drivers, operating system, utilities, or applications. A device interface 124 may be coupled to an external device, such as the computing device 102 of FIG. 1A, hence, the secured documents therefrom can be received into memory 132 or storage 136 through data bus 120. Also interfaced to data bus 120 is a display interface 126, a network interface 128, a printer interface 130, and a floppy disk drive interface 138. Generally, a client module, a local module, or a server module of an executable version of one embodiment of the present invention can be stored to storage 136 through floppy disk drive interface 138, network interface 128, device interface 124, or other interfaces coupled to data bus 120. Execution of such module by CPU 122 can cause the computing device 118 to perform as desired in the present invention. In one embodiment, the device interface 124 provides an interface for communicating with a capturing device 125 (e.g. a finger print sensor, a smart card reader or a voice recorder) to facilitate the authentication of a user of the computing device 118.
Main memory 132, such as random access memory (RAM), is also interfaced to data bus 120 to provide CPU 122 with instructions and access to memory storage 136 for data and other instructions. In particular, when executing stored application program instructions, such as a document securing module in the present invention, CPU 122 is caused to manipulate the data to achieve results contemplated by the present invention. Read-Only Memory (ROM) 134 is provided for storing executable instructions, such as a basic input/output operation system (BIOS) for operation of keyboard 140, display 126, and pointing device 142, if there are any.
Referring now to FIG. 2A, an illustration diagram of securing a created document 200 is shown. After the document 200 is created with an application or authoring tool (e.g., Microsoft Word.RTM.), upon an activation of a "Save," "Save As" or "Close" command or automatic saving invoked by an operating system, the application, itself, or an application that is previously registered with the server, the created document 200 is caused to undergo a securing process 201. The securing process 201 starts with an encryption process 202, namely the document 200 that has been created or is being written into a store is encrypted by a cipher with a file key. In other words, the encrypted document could can not be opened without the file key (i.e., a cipher key).
In essence, the secured document 208 includes two parts, the document itself, and the corresponding security information therefor, both are in encrypted form. To access the document, one needs to obtain the file key that is used to encrypt the document and is now included in the encrypted security information. To obtain the file key, one needs to be authenticated to get a user or group key and pass an access test in which the access rules in the security information are measured against the user's access privilege.
Alternatively, a secured document in a folder appears substantially similar to a regular document and launches the same application when activated except the application will fail to access the contents therein. For example, icons or file names of secured documents may appear in a different color or with a visual indicator to distinguish from non-secured documents. When a secured document is unintentionally ends up in a machine or readable medium (e.g., CD or disk), if a user of the machine or a machine attempting to read the readable medium has no proper user key or if the user cannot be authenticated, the secured document will not be successfully accessed.
TABLE-US-00001 <rule> <doc_type> PDF </doc_type> <grantor name="ACCTG"/> <grantee name="MKTG"/> <grantee name="PR"/> <action> VIEW </action> <action> PRINT </action> <conditions> <delivery_channels> HTTPS </delivery_channels> <min_time_day> 1700 </min_time _day> <expiry_date> 3 Aug, 2002 </expiry_date> </conditions> </rule>
FIG. 20.2 illustrates another exemplary structure of a secured document 250 including a header 252 and an encrypted portion 254. The header 252 further includes a user block 256 and a rules block 258. The user block 256 includes a clear portion and an encrypted portion 260. The clear portion includes user/group ID(s) and block version number(s). The encrypted portion 260 is encrypted with a user key according to a cipher. If there are N number of distinctive groups/users with possible different access privileges, there will be N such encrypted portions, each encrypted with a corresponding user key. The encrypted portion 260 includes, among other things, the file key that, once retrieved, can be used to decrypt the encrypted data portion 254. In addition, the encrypted portion 260 includes the cipher information to facilitate the encryption/decryption of the encrypted portion 254.
FIG. 20.3 shows an exemplary header 266 corresponding to that of the secured document structure in FIG. 2C.2. The header 266 includes a number of segments. In addition to those segments in clear mode, segments 267-269 are encrypted. Specifically, the secured file is configured to be accessed by two groups: marketing and engineering. All users in the two groups are supposed to be able to access the file with an authenticated user key. According to one embodiment, the segment 267 is encrypted with a user key specifically designated to marketing users, while the segment 268 is encrypted with a user key specifically designated to engineering. However, both of the segments 267 and 268 could be respectively encrypted with a single user key. In any event, the encrypted segments in the header 266 include a file key 270 in addition to corresponding cipher information about the cipher being used.
Sometimes, a user may have a need to export or import a set of predefined access rules. In this case, the temporary file having the access rules may be exported, downloaded, or imported into another device or folder. The exportation/importation of access rules provides convenience for a user because the user need not create the access rules from scratch.
An application 306 (e.g. a server registered application, such as Microsoft Word) operates over operating system (OS) 304 and may be activated to access a document stored in a store 308. The store 308 may be a local storage place (e.g., hard disk) or remotely located (e.g., another device). Depending on the security nature (secured vs. non-secured) of the document being accessed, the DSM 302 may activate a cipher module 310. According to one embodiment, the DSM 302 is analogous in many ways to a device driver that essentially converts more general input/output instructions of an operating system to messages that a device/module being supported can understand. Depending on the OS in which the present invention is implemented, DSM may be implemented as a VxD (virtual device driver), a kernel, or other applicable format. The cipher module 310 is included in or controlled by the DSM 302 and can be activated for operations when a secured document is involved.
In another embodiment, an operating system (OS) access, known as the ProcesslD property, can be used to activate an application (as an argument to the AppActivate method). The parameter ProcesslD identifies the application and an event handler thereof takes necessary parameters to continue the OS access to the Installable File System (IFS) Manager 312 that is responsible for arbitrating access to different file system components. In particular, the IFS Manager 312 is configured to act as an entry point for processes such as opening, closing, reading, writing files and etc. With one or more flags or parameters passed along, the access activates the DSM 302. If the document being accessed by the application is regular (non-secured), the document will be fetched from one of the File System Driver (FSD) (e.g., FSD 314) and passed through the DSM 302 and subsequently loaded into the application through the IFS Manager 312. On the other hand, if the document being accessed by the application is secured, the DSM 302 activates the cipher module 310 and proceeds to obtain an authenticated user key to retrieve the access rules therein. If the access privileges satisfy the access rules, a file key will be retrieved to decrypt the encrypted data portion of the secured document by the cipher. As a result, the data portion or the document in clear mode will be loaded into the application through the IFS Manager 312.
At 406, a secret cipher key (i.e., a file key) is generated from a cipher module for the document and typically stored in a temp file that is generally not accessible by an ordinary user. The temp file will be erased automatically when the secured document is done (e.g., at a "Close" command from the application). At 408, the document is checked to see if a request to write the document into a local store is made. If such request is detected (which could be made manually by the user or periodically by the authoring tool or an OS), the document is encrypted with the file key at 410. One of the features in the present invention is that the stored document is always encrypted in storage even if it is still being processed (e.g., authored, edited, or revised). When the user is done with the document, a "Close" request is activated to close the document. At 412, such a request is detected. As soon as such request is received, it means that a secured version of the document is being written into the store. At 413, the access rules and the file key are included in security information that is encrypted with the authenticated user key. Depending on implementation, a flag or signature and the security information can be included in the header. Alternatively, the header could include the security information without a flag. At 414, the header is attached to the encrypted document from 410 and subsequently the secured document is placed into the store at 418.
Referring back to FIG. 4B, the user authentication process is invoked, communication to a server (e.g., server 104 or 106) is checked at 432.
If it is detected that no communication to the server is available, which may mean that the client machine may not be on a network or the server is down or other causes, the user may have at least three options. First, the user can now access only non-secured documents or may generate secured documents at 434 if a public user key is available or retained in the client machine. Second, the user can keep trying to communicate with the server, in which case the process 430 goes back to 432 till a secured communication link is established. Third, the user may take advantage of another feature offered by the present invention, offline access at 433. In short, the user may access a limited number of secured documents on the client machine, the details of which will be provided below.
Although the description of the process 430 in FIG. 4B is based on the user authorization process formed in conjunction with a server. It is clear to those skilled in the art that the description is readily applied to other means for conducting the user authentication. For example, the user key can be authenticated, validated, or retrieved by biometric information of the user as described above.
In general, the rules manager 520 is an enforcement mechanism of various access rules. According to one aspect, the rules manager 520 is configured to specify rules based on i) data types (e.g., Microsoft Word), ii) group users or individual, iii) applicable rights, and iv) duration of access rules.
Typically, a set of rules is a policy. A policy can be enabled, disabled, edited, deployed and undone (e.g., one or two levels). Policies managed by the rules manager 520 operate preferably on a global level. They are downloaded to the client machine during the login process (after the user is authenticated) and can be updated dynamically. In addition, respective policies may be associated with active folders (i.e., those designated places to store secured documents). These polices are also downloaded and updated on the client machine. Simple policies are also embedded in the document and provide document specific policies. According to one embodiment, a header is received by a local server from a client and the access rules from the header are retrieved. The key manager 510 is called upon to decrypt the encrypted security information in the header. The rules manager 520 is also called upon to parse the access rules from the security information and evaluate or measure the access rules against the access privilege of the user to determine whether the secured document can be accessed by the user. If the evaluation or measurement succeeds, a file key is retrieved and sent back to the client.
Depending on the actual situation and an implementation in which the user key(s) is being replaced, the newly generated key(s) may be kept with the key manager or released to a client machine next time a corresponding user logs on therefrom. At 518, the process 510 awaits a decision whether the newly generated keys remain with the server or is downloadable to a client. When the decision is to retain the newly generated key(s) in the server, the process 510 goes to 522 in which the new key are set to be associated with the same user. When the decision is to release the newly generated keys to the user next time the user logs onto the server, the process 510 goes to 522. At 522, the process 510 awaits a contact from the user. As described above, the user may login on any time from a client machine when he/she needs to access a secured document. When such contact does happen, the server will receive the credential information from the user to ensure that the user is who he/she claims to be. After the user is authenticated, the new keys are encrypted with the credential information at 524. The credential information is provided by the user when requesting for authentication and may include a set of username and password or a biometric feature (e.g., a fingerprint) of the user. Regardless of what cipher is used, the newly generated keys are converted into an illegible format at 524. The encrypted new keys are then uploaded or transmitted to the client machine at 526. Upon receiving the encrypted new keys, the client machine is caused at 528 to decrypt the encrypted new keys to make the new user keys readily available for accessing secured documents or securing documents. In some cases, the client module in the client machine may be scheduled to scan in designated folders all available secured documents whose headers were originally encrypted by the old user key. These documents can be now encrypted again with the new key to ensure that the secured documents are indeed secured. In a preferable embodiment, the updating of user keys can be made to perform transparently as far as the users are concerned. In other words, the users are not aware that the process 510 has happened and the new keys are now installed.
According to one embodiment, the local module 572 is a localized version of some of the server module 502 in the central server 500 and services the users local to the local server. For example, in FIG. 5D, it shows a table 584 of all the users managed by the central server 500. Among the users, John's access privilege 585 is at level 10 (assumed highest) and can access secured documents all days at all times from any of the three locations. Dell's access privilege 586 is at level I (assumed lowest) and can access secured documents 8 hours (e.g., 9:00 AM-5 PM) a day, Monday to Friday and only from location A. Mike's access privilege 587 is at level 5 and can access secured documents 12 hours Monday to Saturday and only from locations A and B. If three local servers are employed respectively for the three locations A, B and C, there can be three different access control management possibilities as shown in FIG. 5E, each assigned to one local server. As a result, the local users need only to check with the corresponding local server and none of the users would be affected if other local servers are down for whatever reasons or disconnected from the central server.
To continue the above embodiment employing one or more local servers to store a localized version of the server module so as to provide only localized access control management. FIG. 6B shows a flowchart of dynamically configuring the access control management process 620 which may be implemented in one or more local servers. The process 620 is performed 610 and 612 of FIG. 6A. At 610, the user has been determined to be authenticated.
Next, at 622, the server needs to determine the number of locations or computers from which the user is authorized to access the secured document. In operation, the user's access privilege is examined. Typically, the user's access privilege includes information identifying where (e.g., a permitted location, a geographic location or a local area network) and/or which local computers the user can utilize (e.g. permitted computers). In some case, a user travels a lot among a few offices in several geographic locations, thus the user could be privileged to access secured documents from either one of these geographic locations/computers.
There are numerous functions, benefits, and advantages in the present invention. One of the functions, benefits and advantages is that the securing mechanism contemplated in the present invention keep selected digital assets under protection at all times by employing access rules in the secured digital assets. As such only authorized user with authenticated machines can access the secured digital assets. Other functions, benefits, and advantages are apparent to those skilled in the art given the detailed description herein.
Previous Patent US 9,542,559 | Next Patent US 9,542,561