Method and system for offline access to secured electronic data

Description: TECHNICAL FIELD [Detailed description of the invention]

【0001】

[Technical field to which the invention belongs]

The present invention relates to the field of data protection in a corporate environment, especially with respect to processes, systems, architectures, software products, and programs that provide security to digital assets at all times.

【0002】

[Cross Reference to Related Applications] This application is in US Provisional Patent Application No. 60 / 339,634, which was filed on December 12, 2001 and whose title of the invention is "Pervasive Security Systems". It is a priority claim application based on. This US provisional patent application is cited as a reference for all purposes.

【0003】

[Conventional technology]

The Internet is the fastest developing communication medium in history. This development of the Internet and the accessibility of the Internet have significantly increased the opportunities for using the latest information technology in both the public and private sectors. This provides an unprecedented opportunity for interaction and data sharing between businesses and individuals. However, the benefits gained by the Internet carry with it a very large risk to the reliability and integrity of the information. The Internet is a widely open, public, international network of interconnected computers and electronic devices. Without adequate security measures, unauthorized persons or unauthorized machines intercept information transmitted over the Internet and, in some cases, are interconnected to the Internet, which is generally unavailable to the public. You can get confidential information stored on your computer.

【0004】

Numerous attempts are underway to protect sensitive information that travels over the Internet and to limit access to computers that hold sensitive information. Cryptography makes it possible to bring the trust found in the physical world into the electronic world, allowing people to do business electronically without being fooled by fraud or impersonation. Every day, hundreds of thousands of people interact electronically through e-mail, e-commerce (businesses conducted on the Internet), ATM machines, mobile phones, and so on. This leads to an increase in reliance on cryptographic technology, which allows for an increase in electronically transmitted information.

【0005】

One ongoing attempt to protect sensitive information transmitted over the Internet is to use one or more cryptographic techniques to ensure a private communication session between two communicating computers on the Internet. Is to use. Cryptography provides a way to convey information over an uncertain communication channel without disclosing the content of the information to anyone eavesdropping on the communication channel. Using an encryption process for cryptography allows one party to protect the content of the data being transmitted from access by an unauthorized third party, and the target party (the other party) It is possible to read the data using the corresponding decryption process.

【0006】

Firewalls are another security measure that protects the resources of a private network from users on other networks. However, it has been reported that a large number of unauthorized accesses to sensitive information are made internally rather than externally. An example of a person making unauthorized access from the inside is when restricted or confidential information is accessed by someone in the organization who should not have access to it. Due to the openness of the Internet, contractual information, customer data, executive communications, product specifications, and other confidential and confidential intellectual property hosts remain available and protected. It is vulnerable to improper access and use by unauthorized persons within or outside the bounds of what should be.

【0007】

According to a government report from the Accounting Inspection Office (GAO), "Seven agencies within the U.S. Department of Commerce have found serious and widespread computer security vulnerabilities, and the widespread computer security vulnerabilities throughout the agency. , Endangers the integrity of some of the institution's most delicate systems. " In addition, the government report demonstrates that "by using readily available software and common technologies, it is possible to invade sensitive commerce systems from within commerce and remotely, such as the Internet. ", And" both internal and external individuals of commerce have unauthorized access to these systems and should pay close attention to economic, financial, personnel data, and confidentiality. I was able to read, copy, modify, and delete business data, etc. " The government report concludes that "intruders can interfere with the operation of systems that are critical to the ministry's mission."

【0008】

[Problems to be Solved by the Invention]

In practice, most businesses and institutions are looking for effective ways to protect their sensitive information. Businesses and institutions typically deploy firewalls, virtual private networks (VPNs), and intrusion detection systems (IDSs) to provide protection. Unfortunately, these various security measures have proven to be inadequate for the reliable protection of sensitive information residing on private networks. For example, depending on the password to access a document that requires great care, security is often compromised when passwords of several character lengths are leaked or found. Therefore, it is always desirable to provide a more effective way to guarantee and protect digital assets.

【0009】

One object of the present invention is to provide a general-purpose protection mechanism capable of always protecting a protected digital asset.

【0010】

[Means for solving problems]

In order to outline some aspects of the invention, some of the preferred embodiments will be briefly introduced. In order to clarify the purpose of explaining the outline, the description in this column has been simplified or omitted. However, such simplifications or omissions are not intended to limit the scope of the invention.

【0011】

The present invention relates to methods, systems, architectures and software products that constantly provide pervasive security to digital assets and is particularly suitable for corporate environments. In general, pervasive security means that digital assets are always protected and can only be accessed by authenticated users with appropriate access rights or privileges. Here, examples of digital assets include, but are not limited to, a wide variety of documents, multimedia files, data, executable code, images and text.

【0012】

According to one aspect of the invention, a server module that can be run on a server computer is for a group of users, software agents, or devices that need access to protected documents under access control management. It is configured to perform access control (AC) management. Within the server module, various access rules for protected documents and / or access privileges for users or software agents are created, updated, and managed so that users, software agents, or users with appropriate access privileges, or The device may access the protected document if permitted by the corresponding access rules in the protected document. According to one embodiment, the protected document includes a header and an encrypted data part (encrypted data part). The header contains encrypted security information (encryption security information) for controlling access to the encrypted data unit. In order to decrypt the cryptographic security information, the user key associated with the authenticated user must be obtained. When security information becomes available, access rules are taken from the security information and compared to the access privileges of the user accessing the protected document. If this comparison is passed, the file key is obtained from the security bulletin and used to decrypt the encrypted data portion, which in turn makes the unprotected clear document of the protected document available to the user.

【0013】

According to another aspect of the invention, access control management is performed in a distributed manner. Many local server computers function mostly in place of the central server, which is responsible for centralized access control management. Such a distributed form guarantees the reliability, certainty and scalability of access control management performed by the central server. According to one embodiment, the cached version of the server module is loaded and executed on the local server. As a result, the client device does not need to communicate live with the central server when accessing the protected document. Protected documents can be accessed even when the central server is down or the connection to the central server is unavailable.

【0014】

According to another aspect of the invention, a local local version of the local server can be dynamically reconfigured according to the user's current location. According to one embodiment, the local version of the local server works only for users, software agents or devices that are near or authenticated by the local server. When a user moves from one location to another, after detecting the new location of the user who moved from the previous location, the local version of the local server for the new location re-adds support for that user. At the same time, the local version of the local server for the previous location is reconfigured to remove support for that user. As a result, security is improved and a user is always granted only one access right throughout the organization, regardless of the number of locations in the organization or the type of access privilege granted to that user. Access control management is performed efficiently to ensure that it exists.

【0015】

According to yet another aspect of the invention, the protected document format is designed so that the security information of the document always accompanies the protected document. This integration mechanism makes it easy to move the protected document to another location without losing the security information contained in the protected document, making it difficult to access the protected document from another location. According to one embodiment, the protected file or protected document includes two parts, an attachment part called a header and a cryptographic document or a cryptographic data part. The header contains security information that specifies or contains access rules and file keys. Access rules allow restricted access to protected documents to be easily achieved and essentially determine who, when, how, and where they can access protected documents. The file key is used to encrypt / decrypt the encrypted data part. Only people with appropriate access privileges are allowed to obtain the file key to encrypt / decrypt the encrypted data part. Depending on the precision of the embodiment, the header may contain other information (eg, flags, signatures, or version numbers) so that the security type of the document can be easily detected. Alternatively, the cryptographic security information and the two parts of the cryptographic data section may be re-encrypted in the form of a protected file or protected document.

【0016】

According to yet another aspect of the invention, a client module running on a client device has access to a protected document located in a local storage location, another computer machine, or somewhere on the data network. It is configured to perform control. According to one embodiment, the client module includes a document protection module built in to work with an operating system. In particular, the document protection module operates in the path that the accessed document passes through, so that the document is inspected or detected for security type. When the document is protected, the document protection module obtains a user key or group key to decrypt the security information in the document header regarding the access rule. When it is determined that the user who accesses the document is granted access privilege to the protected document, the file key is obtained from the protection information, the encryption module is activated, and the encrypted data part is decrypted with the file key. Similarly, when a document needs to be protected, the cryptographic module encrypts the clear data from the document in order to create a cryptographic data section. The document protection module integrates appropriate or desirable security information with the encrypted data unit in order to generate a protected document. The document protection module runs on the operating system, so the cryptographic / decryption process is unnoticed by the user.

【0017】

According to yet another aspect of the invention, the client module of the client device activates the offline access module to provide an offline access mechanism for users who are away from the network. When the user decides to leave the network environment or when the user is on a business trip, an offline access request is created by the offline access module of the client device and forwarded to the access control server. In response, the access control server grants the user, as well as the client device for the user to access the protected document offline, an offline access request. According to one embodiment, the access control server has been modified so that it automatically expires after a certain amount of time or becomes invalid when the client device connects to the access control server at the next opportunity. Alternatively, provide temporary access rules, access privileges, or user keys. As a result, the user can access some or all of the protected documents in the client device and at the same time create protected documents, which are temporary access rules, Access or be protected with access privileges or user keys. During the offline access period, the Access Report Manager is activated to record all activities of the user accessing the protected document. When the client device is reconnected to the access control server, the access activity record of the protected document is accessed so that the access control management can be easily synchronized with the protected document accessed offline or the protected document created. Notified to the control server.

【0018】

Other objects, features and effects of the present invention will become apparent by examining the detailed description of the embodiments of the present invention with reference to the accompanying drawings.

【0019】

BEST MODE FOR CARRYING OUT THE INVENTION

The above and other features, aspects and advantages of the present invention will be better understood with respect to the following description, claims and the accompanying drawings.

【0020】

The present invention relates to methods, systems, architectures and software products (programs) that always provide pervasive security for digital assets. In general, pervasive security means that digital assets are always protected and can only be accessed by authenticated users with appropriate access privileges. The present invention is particularly suitable for the corporate environment.

【0021】

In the following description, a number of specific details are provided to aid in a complete understanding of the invention. However, as will be apparent to those skilled in the art, the present invention can be practiced without the use of such particular details. The descriptions and expressions herein are common means used by one of ordinary skill in the art or one of ordinary skill in the art to most efficiently convey one's achievements to those of ordinary skill in the art. In another example, well-known methods, procedures, components and circuits are not described in detail to avoid unnecessarily obscuring aspects of the invention.

【0022】

The term "one embodiment" or "(some) embodiment" means that the particular features, structures or properties described for that embodiment are included in at least one embodiment of the present invention. Although the phrase "in one embodiment (according to one embodiment)" is used in various contexts of the specification, they do not all have to specify the same embodiment and are independent of each other. Nor does it have to specify a separate or alternative embodiment. Furthermore, the sequence of steps in the processing flow chart, or the diagram representing one or more embodiments of the present invention, does not essentially specify any particular order, but may imply any limitation in the present invention. Absent.

【0023】

To facilitate the description of the present invention, it will be necessary to define certain terms used throughout the description below. It should be noted that the following definitions are intended to aid in the understanding of the invention and to describe the invention in accordance with one embodiment. These definitions may seem to include certain restrictions from the point of view of the examples, but as will be apparent to those skilled in the art, the actual meaning of these terms is limited to such examples. It can be widely applied without being used.

【0024】

Digital Assets Digital assets define the types of electronic data, including various types of documents, multimedia files, streaming data, dynamic or static data, executable code, images, and text. It is not limited to the example.

【0025】

[File] or [Document] A file or document, which is used interchangeably, indicates a type of digital asset and is generally in clear mode, i.e., one or more without prior knowledge. It can be accessed from the application. Here, access to a file or document is a request for opening, viewing, editing, playing, listening, or printing the file or document in the format or result desired by the user requesting access to the file or document. Is.

【0026】

Protected File or Protected Document A protected file or document defines a type of digital asset that cannot be accessed without prior knowledge. Examples of prior knowledge include, but are not limited to, passwords, secret phrases, biometric information, or one or more keys.

【0027】

[Cryptographic File] or [Cryptographic Document] A cryptographic file or cryptographic document represents a file or document encrypted by cryptography (ie, introduction of cryptographic techniques).

【0028】

[File key] A file key is an example of prior knowledge, which is also called an encryption key, and once acquired, it is used to decrypt or decrypt an encrypted document.

【0029】

[User Key] A user key is another encryption key associated with a user or a group of users, or identifying a user or a group of users, and is used to obtain a file key. According to some formats of protected files, the user key is used to obtain the file key, then the file key decrypts or decrypts the encrypted document, and another user key or the same user key keeps the file key secret. Or used to encrypt.

【0030】

Access Privileges Access privileges are one or more rights granted to a user with respect to a protected file or document. A user can only access protected files from a specified location during a particular time period if restricted by that user's access privileges. Optionally, access privileges are the specific host the user logged in to, the file transfer protocol, the access application (model and / or version), the permission to grant access privileges to others (eg, consultants), or members of other groups. Other restrictions may be specified for qualifications, etc.

【0031】

[Access Rule] An access rule is a flag or specified permission for limiting the actions that a user takes on a protected file or document. According to one embodiment of the invention, at least a portion of the access rule is contained in a protected file or document. In some cases, access rules are extensible by users with appropriate access privileges.

【0032】

[Client device, computer, or machine] A client device, computer, or machine is a terminal device that is used interchangeably and is typically used by a user to access a protected document.

【0033】

[Server device, computer, or machine] A server device, computer, or machine is used interchangeably and represents a computer device. According to one embodiment, such a computer device performs access control (AC) management on protected documents accessible by a client machine or user.

【0034】

[Client Module] A client module generally represents a viable version of an embodiment of the present invention, typically to achieve the features, features, benefits, and effects considered in the present invention. , Loaded on the client device.

【0035】

[Server Module] A server module generally represents an executable version of an embodiment of the present invention, typically to realize the features, features, benefits, and effects considered in the present invention. , Loaded into the server device.

【0036】

[Server and Client] Unless otherwise specified or explicitly stated, server refers to a server device or server module, and client refers to a client device or client module, in which case the specific meaning is context. It is clear from.

【0037】

Hereinafter, examples of the present invention will be described with reference to FIGS. 1A to 7C. However, one of ordinary skill in the art will readily appreciate that the detailed description of these drawings is for purposes of illustration, as the present invention is not limited by these examples.

【0038】

FIG. 1A is a block diagram of a basic system in which the present invention is implemented according to an embodiment of the present invention. Documents or files such as product descriptions, customer lists, and price schedules are created using authoring tools running on client computer 100. The client computer is a desktop computer device, a laptop computer, or a portable computing device. Examples of authoring tools include Microsoft Office® (eg, Microsoft Word®, Microsoft PowerPoint®, and Microsoft Excel®), Adobe FrameMaker®, and Adobe. Includes Photoshop®.

【0039】

According to one embodiment, the client computer 100 is loaded with a client module that is a linked and compiled version of an embodiment of the present invention or an interpreted version. Has the ability to break the data network (ie, the Internet or the local area network) and communicate with the server 104 or 106. According to another embodiment, the client computer 100 is connected to the server 104 via a private link. As described below, the document created by the authoring tool is protected by the client module detailed. The client module is configured to ensure that protected documents are always protected on a storage device (eg, a hard disk or other data repository (storage location)) when executed. According to the present invention, a document is stored in protected mode and is accessed only by users with appropriate access privileges. In general, user access privileges include, but are limited to, read, copy, print, edit, transfer, upload / download, and location permissions. Do not mean.

【0040】

According to one embodiment, the created document is preferably encrypted without being noticed by the user. In other words, the created document is encrypted or decrypted under the authoring application, so the user is unaware of this process. The key for obtaining the file key for decrypting the cipher document (hereinafter referred to as the user key) is associated with the access privilege. Only users with appropriate access privileges can access the protected document.

【0041】

In some situations, the protected document is uploaded over network 110 to a computer device or storage device 102 that acts as a central repository. Although not required, the network 110 preferably sets up a private link between the computer 100 and the computer device 102. Such links are provided by the company's internal network or by protected communication protocols over the Internet (eg VPN and HTTPS). Alternatively, such a link may be easily realized by a TCP / IP link. In this way, the protected documents on computer 100 are accessed remotely.

【0042】

In another situation, the computer 100 and the computer device or storage device 102 are inseparable, in which case the computer device or storage device 102 holds a protected document or a protected network resource (eg, dynamic). It may be a local storage device that captures web content, the results of database queries, or live multimedia inputs). Regardless of where the protected document or protected source actually exists, users with appropriate access privileges can use applications (eg, Internet Explorer®, Microsoft Word®, or Acrobat Reader (eg, Internet Explorer®, Microsoft Word®, or Acrobat Reader). The registered trademark)) can be used to access protected documents or protected sources from computer 100 or device 102.

【0043】

The server device 104, sometimes referred to as a local server, is a computer device connected between network 108 and network 110. According to one embodiment, server 104 is a local version of a compiled, linked version of the server module of one embodiment of the invention. As described below, a local version is a localized server module configured to serve a designated group of users or client computers, or a location. Another server device 106, also called a central server, is a computer device connected to network 108. Server 106 runs the server module and provides centralized access control (AC) management for the entire organization or business. Therefore, each local module in the local server cooperates with the central server to form a distributed mechanism for distributed access control management. Such distributed access control management guarantees the reliability, certainty and scalability of centralized access control management performed by a central server for the entire enterprise or business location. As described below, the server module of the central server maintains or concatenates a database, which is a list of users and their associated organization-wide or business-related access privileges, folders or Contains rules for files, but is not limited to these examples. Local modules, on the other hand, are configured to hold or concatenate part or all of the database, servicing a group of users near the local server.

【0044】

FIG. 1B is a configuration diagram of a system in which a central server and a local server are used. This configuration accommodates large enterprises with numerous geographic locations or offices. The central server 106 maintains a database that manages access privileges and access rules for the entire enterprise. One feature of this configuration is to provide fault tolerance and efficient access control management for large groups of users. Rather than having a central server 106 that performs access control for each of the users in one place (single location), many local servers 104 (eg 104-A, 104-B, ... and 104-N) ) Is used in a distributed format to serve individual locations or offices. Each local server 104 executes a local module obtained or replicated from a server module running on central server 106 to manage users near each local server 104. The central server 106 not only manages users, but also centralizes access control management as needed.

【0045】

According to one embodiment, a local module is a custom version of a server module that works efficiently for a small number of locations or groups of users. For example, local server 104-A functions only for location A user or computer 102-A, and local server 104-B functions only for location B user or computer 102-B. Fulfill. As a result, access control is unobtrusive even if the central server 106 is down for maintenance or is not active when the user needs to access the protected document. The detailed operation of the local server 104 in cooperation with the central server 106 will be described later.

【0046】

According to another embodiment, the local module is a duplicate version of the server module, exchanging updates with the server module when connected (eg, on a regular basis or on request). .. Depending on the embodiment, some or all of the server modules are replicated to the local server to ensure efficient communication with the user or client device and fault tolerance. As a result, access control is unobtrusive even if the central server 106 is down for maintenance or is not active when the user needs to access the protected document. For example, in such a situation, any local server 104 is prepared and used in place of the central server. When the central server 106 is running or communicating with the local server 104, the information collected about the user or user activity on each local server is returned to the central server 106. In this regard, the detailed operation of the local server 104 in cooperation with the central server 106 will be described later.

【0047】

Figure 1C is a system configuration diagram suitable for a small group of users. With this configuration, the local server is not used. The server computer 112 is loaded with the server module, and each user or each terminal computer 116 (only one is shown) is loaded with the client module. As a result, the server computer 112 executes access control for each user or for each terminal computer 116.

【0048】

It should be noted that there is no clear distinction between a group of small users and a group of large users as far as the number of users is concerned. With the following description, one of ordinary skill in the art will understand how to distribute or balance access control management among one or more other computer devices. In order to facilitate the following description of the present invention, the scene shown in FIG. 1B is assumed. One of ordinary skill in the art can similarly apply the following description to Figure 1C, as well as in situations where other situations are preferred between one or more central servers and one or more local servers. You will understand that there is.

【0049】

FIG. 1D is a block diagram of the internal configuration of a computer device in which an embodiment of the present invention is incorporated and executed. Device 118 is a client device (eg, computers 100, 102 in FIGS. 1A and 1B, or computer 116 in FIG. 1C) or a server device (eg, servers 104, 106, or 1C in FIGS. 1A and 1B). Corresponds to server 112). As shown in FIG. 1D, device 118 includes a central processing unit (CPU) 122 connected to data bus 120 and device interface 124. CPU122 processed the data and was probably connected to databus 120 for synchronous operationExecute instructions to manage all devices and interfaces. The instructions executed relate to, for example, a driver, operating system, utility, or application. The device interface 124 is connected to an external device such as the computer device 102 of FIG. 1A, and the protected document from the external device is taken into the memory 132 or the storage device 136 via the data bus 120. A display interface 126, a network interface 128, a printer interface 130, and a flexible disk drive interface 138 are connected to the data bus 120. In general, a viable version of a client module, local module or server module according to an embodiment of the invention is on a flexible disk drive interface 138, network interface 128, device interface 124, or data bus 120. It is stored in storage device 136 via other connected interfaces. When the CPU 122 executes such a module, the computer device 118 operates as desired in the present invention. In one embodiment, device interface 124 provides an interface for communicating with a capture device 125 (eg, a fingerprint sensor, smart card reader, or voice recorder) to facilitate authentication of the user of computer device 118. ..

【0050】

A main memory 132, such as random access memory (RAM), is connected to the data bus 120 to give the CPU 122 access to storage for instructions and data and other instructions 136. In particular, when executing stored application program instructions such as the document protection module in the present invention, the CPU 122 manipulates the data to achieve the results considered by the present invention. Read-only memory (ROM) 134, if any, is provided to hold executable instructions, such as the basic input / output operating system (BIOS) for the operation of the keyboard 140, display 126, and printing device 142.

【0051】

With reference to FIG. 2A, an example of the protection process of the created document 200 is shown. After the document is created using an application or authoring tool (eg, Microsoft WORD®), then "Save", "Save As", or "CLOSE". The created document 200 is protected by the protection process 201 when a command such as "" is activated, or when the created document 200 is automatically saved when it is called by the operating system, the application itself, or an application registered in advance using the server. The protection process 201 starts from the encryption process 202, that is, the document 200 created or written in the storage device is encrypted by the encryption unit using the file key. In other words, a cipher document can only be opened with a file key (ie, a cryptographic key).

【0052】

A set of access rules 204 for document 200 is retrieved and associated with header 206. In general, access rule 204 determines or adjusts who and / or how to access the protected document 200. In certain cases, access rule 204 determines or adjusts when or where document 200 can be accessed. Typically, the header is a small file structure that stores or possibly links security information about the resulting protected document. Depending on the strict embodiment, the security information may be completely contained in the header or specified by a pointer contained in the header. According to one embodiment, access rule 204 is contained in header 206 as part of the security information. The security information further includes a file key and, in some cases, offline permissions (eg, in access rules) when requested by a user who is granted such access. The security information is encrypted by cryptographic techniques with a user key associated with the authorized user to generate cryptographic security information 210. The cryptographic header is attached to the cryptographic document 212 to create the protection document 208 if no other information has been added.

【0053】

The cryptographic technique is implemented based on one of a large number of cryptographic / decryption methods. Examples of such cryptosystems include, but are not limited to, Data Encryption Standard (DES), Browfish Block Ciphers, and Two-Fish Ciphers. Therefore, the operation of the present invention is not limited to the selection range of these popular encryption / decryption methods. Any efficient and reliable encryption / decryption method can be used. Therefore, the details of the encryption / decryption method will not be described further in order to avoid obscuring the aspect of the present invention.

【0054】

In essence, the protected document 208 contains two parts, the document itself and the security information corresponding to the document, both in cryptographic form. In order to access the document, it is necessary to obtain the file key used to encrypt the document. This file key is included in the cryptographic security bulletin. In order to obtain the file key, it is necessary to obtain the user or group key and be authenticated to pass the access test. In the access test, the access rules in the security information are compared with the user's access privileges.

【0055】

According to one embodiment, the cryptographic security information including the access rules or the header is placed at the head of the cryptographic document (data unit) so that the protection characteristics or the protection document can be easily detected at an early stage. One zero in such an arrangement is that the access application (ie, the authoring or viewing tool) can immediately activate the document protection module to decrypt the header. After successfully decrypting the header with the authenticated user key, the access rules are compared to the user's access privileges. If the user requesting the protected document has the appropriate access privileges, the clear content of the document (unencrypted content) is loaded into the access application, and if the user does not have the access privileges, it is being rejected. A value (eg, a message or a blank document) is sent to the user. However, the cryptographic security information or header may be placed anywhere in the cryptographic document and may not be continuously embedded in the cryptographic data portion. According to the present invention, the cryptographic header is always attached to the cryptographic data section, that is, the security information is integrated with the protected document. This integration mechanism makes it easy to transfer protected documents to other locations without losing the security information contained in the protected documents.

【0056】

One feature of the present invention is that the protected document is unnoticed by the user. In other words, the protected document or protected file is configured to have the same file extension as the unprotected file, so the application specified to access the file can be run to access the protected file. .. For example, the newly created word document xyz.doc can be accessed by the application WINWORD.EXE. After the word document is protected, the protected document remains with the same file name, i.e. xyz.doc, and the access rules for that word document do not allow the user to open the document. You can access this word document with the same application WINWORD.EXE unless the application fails to open the document.

【0057】

Alternatively, the protected document in the folder looks virtually like a regular document and launches the same application when this document is activated, unless the application cannot access the contents of that document. To do. For example, a protected document icon or file name may appear in a different color or with a visual sign to distinguish it from an unprotected document. When the protected document is unintentionally terminated in the device or readable medium (eg, CD or disk), the user of the device to read the readable medium, or the device is not given a suitable user key. In some cases, or if the user is not available, access to the protected document will not be successful.

【0058】

It should be noted that the header of the protected document can be configured in a format different from the above-mentioned few formats without departing from the principle of the present invention. For example, a protected document contains a header containing a plurality of cryptographic headers, and each cryptographic header is allowed access by only one designated user or a group user. Alternatively, the header of the protected document contains two or more sets of security information, each set is for one specified user or group of users, and a single file key is for all sets. used. Some or all of the access rules are viewed or updated by users who have access to the protected document.

【0059】

As described below, in order to access the protected document, the user needs a user key that first decrypts the cryptographic security information or headers. In one embodiment, the user key is associated with the user's login to a local or central server. Appropriate access privileges associated with the user are valid when the user is authenticated, pre-registered on the server, and logged in properly. Depending on the grant or access privilege, the access rules in the protected document determine whether the content of the document may be exposed to the user.

【0060】

According to one embodiment, access rules are represented in markup languages such as HTML and SGML. In a preferred embodiment, the markup language is an extensible access control markup language (XACML), which is essentially an XML specification for expressing information access policies. In general, XACML provides fine control of allowed behavior, the effects of the characteristics of the access requester, the protocol on which the request was made, authentication based on the class of behavior, and content reflection (ie, request). It can handle both the original and the authentication based on the attribute value in the target whose attribute value is unknown to the policy author). Moreover, XACML can propose a policy authentication model to guide the adopters of the authentication mechanism.

【0061】

The following is an example of an access rule expressed in XACML:<img file="JP2003228520A_D0001.tif" />【0062】

To put the meaning of the above example in words, "The new PDF document created by ACCTG (Accounting Group) is downloaded via HTTP and is accessed by 5 pm every day before August 3, 2002. , MKTG (Marketing Group) and PR (Public Relations Group) are allowed to view and print. "

【0063】

FIG. 2B is an explanatory diagram of an exemplary structure of a protected document including a header 222 and a cipher 224. The header 222 includes a security information block 226 containing cryptographic security information that essentially controls access to the cipher document 224. In certain embodiments, header 222 includes flag 227 (eg, a given set of data) to indicate that document 220 is protected. The security information block 226 stores one or more user IDs 228, access rule 229, at least one file key 230, and other information 231. User ID 228 maintains a list of authorized users that have been compared (matched) against access rule 229 before file key 230 was obtained. Access rule 229 determines who and how at least the cipher manuscript 224 can be accessed. Depending on the embodiment, other information 231 is used to incorporate other information that facilitates secure access to the cipher document 224. Examples of other information include version numbers or author identifiers.

【0064】

Generally, a document is encrypted with a cryptographic technique (eg, symmetric or asymmetric cryptography). Encryption is the conversion of data into a format that makes it unreadable without the use of appropriate knowledge (eg, keys). Its purpose is to ensure privacy by keeping information hidden from unintended others, even if they are given access to other cryptographic data. Decryption is the opposite of encryption. Encryption and decryption requires the use of some sort of confidential information, commonly referred to as a key. Some cryptosystems use the same key for both encryption and decryption, while others use separate keys for encryption and decryption. For the purpose of controlling access to documents, keys collectively called file keys may be the same or separate for encryption and decryption, preferably contained in or specified by the header. It is stored in the security information, and once obtained, it is used to decrypt the encrypted document.

【0065】

The key itself is protected by access privileges and rules to ensure that the key cannot be obtained or accessed by anyone. If the user requesting the document has the appropriate access privileges that can be granted by the access rules, the key is obtained to proceed with the decryption of the encrypted document.

【0066】

The header itself is encrypted with cryptography to ensure that security information or headers (if flags are not incorporated) are not readily available. Depending on the strict embodiment, the encryption technique for the header may or may not be the same as the encryption technique for the document. The key for decrypting the cryptographic header (called the user key) is stored, for example, in the local storage of the terminal device and is activated (activated) only when the associated user is authenticated. To. As a result, only authorized users can access the protected document.

【0067】

Optionally, the two ciphers (ie, the cipher header and the cipher document) are re-encrypted and can only be decrypted with the user key. Alternatively, the cipher (one or all) is error-checked by error-checking unit 225, such as using cyclic redundancy check, to ensure that the cipher or protected document 220 is error-free. ..

【0068】

FIG. 2C.1 is an explanatory diagram of a typical structure of the protection document 236 including the header 238 and the encryption unit 239. Header 238 allows four types of entities 240-243 to access protected document 236. The four types of entities 240-243 include two individual users and two group users, where the group user means that everyone in the group can access the document with the same privileges. To do. Two individual users are given two separate access privileges. User A is only allowed to read the document and User D is allowed to edit and read the document. On the other hand, everyone in Group B is allowed to edit and read the document, and everyone in Group C is only allowed to print the document. Each entity has a corresponding ID, which is associated with the corresponding user and its unique access rules. According to one embodiment, header 238 of protection document 236 is divided into four corresponding subheaders 240-243, each subheader being assigned to one user or one group, accommodating a file key, and separate. It is encrypted with the user key of. In other words, when User A requests Protected Document 236, only the header 240 specified for User A belongs to User A, is decrypted with the user key authenticated by User A (eg, Key A), and the rest. Subheaders 241-243 are kept encrypted. In any case, after one of the subheaders 241-243 is decrypted, the protected document is decrypted with the key (eg, file key) obtained from the decryption subheader.

【0069】

FIG. 2C.2 is an explanatory diagram of an example of another structure of the protection document 250 including the header 252 and the encryption unit 254. Header 252 further includes user block 256 and rule block 258. The user block 256 includes a clearing unit and an encryption unit 260. The clear part includes the user / group ID and the block version number. The encryption unit 260 is encrypted with a user key corresponding to the encryption. If the number of separate groups / users with different access privileges is N, then there are N ciphers, and each cipher is encrypted with the corresponding user key. The encryption unit 260 specifically houses a file key that can be used to decrypt the encryption data unit 254 after it has been acquired. Further, the encryption unit 260 includes encryption information for promoting the encryption / decryption of the encryption unit 254.

【0070】

Rule block 258 can be encrypted individually or with cipher document 254 using the file key that is ultimately held in user block 256. The advantage of using a file key instead of a separate user key to encrypt rule block 258 is that all authorized users / groups can see who has what access rules and rights. It is to provide a mechanism that can be used. According to one embodiment, a random number or a result from the initialization process (eg, a vector) is added to the beginning of the rule block 258 in order to prevent an attack on the rule block 258.

【0071】

FIG. 2C.3 is an explanatory diagram of an example of header 266 corresponding to the header of the protected document structure of FIG. 2C.2. Header 266 includes the number of segments. In addition to these segments in clear mode, segments 267-269 are encrypted. In particular, the protected files are configured to be accessible by two groups, the marketing group and the engineer rig group. All users in the two groups would be able to access the file with an authenticated user key. According to one embodiment, segment 267 is specifically encrypted with a user key specified for the marketing user, and segment 268 is specifically encrypted with the user key specified for engineering. However, both segment 267 and segment 268 can be encrypted with a single user key. In any case, the cryptographic segment of header 266 contains the file key 270 in addition to the corresponding cryptographic information about the cryptographic technique used.

【0072】

Rule block (ie, segment) 269 contains two sets of access rules 271 and 272 (rule details not shown). One set of access rules corresponds to each user group of the two user groups. Rule block 269 is encrypted with a key such as file key 270, or any other key, depending on the cryptographic technique used. According to one embodiment, one of the cryptographic segments of user blocks 267 and 268 is decrypted with the authenticated user key in order to obtain the file key 270. Rule block 269 is decrypted with file key 270 before file key 270 is applied to decrypt the encrypted data portion. The access rule is then compared to the user's access privileges. If the user is not authorized to access the protected document, the file key will be applied to decrypt the encrypted data part. If the user is granted access to the protected document, the file key 270 is applied to decrypt the encrypted data portion.

【0073】

It should be noted that Figure 2C.1, Figure 2C.2 and Figure 2C.3 are only exemplary structures of protected documents. According to other embodiments, the file key required to decrypt the document is encrypted independently and maintained in a separate block of headers. The file key becomes available when one of the subheaders is decrypted (the file key is no longer maintained). In yet another alternative embodiment, one or more flags or messages are contained in the security information of the protected document, and the flags or messages indicate the degree to which the protected document is protected. For example, protected documents are classified as regular documents, confidential documents, confidential documents or confidential documents that require different access levels. Therefore, multiple levels of encryption with respect to file keys and / or access rules are used to ensure that only authorized users can access protected documents. Within the scope of such description, options of other embodiments are also feasible and are not listed individually to avoid obscuring aspects of the invention.

【0074】

FIG. 2D is an explanatory diagram of an example of a graphic user interface (GUI) 275 that can be used to set or create access rules. GUI275 is ready when the user cleans up the protected document and is ready to save the protected document in the designated location, or when the clear document or new document is stored in the designated location. Sometimes activated and / or displayed. According to one embodiment, all data at the designated location has substantially similar access rules. Depending on the strict embodiment, GUI275 is dynamically generated or controlled by a central server to include users who need to access data at a specified location. GUI275 facilitates the determination of the access rules that the user is imposing. As shown in Figure 2D, the selected group of users is selected to be added to access list 276. Action (action, action) 277 determines how to access data at a designated location. Action 277 may be set using GUI275. As a result, the parameters that define the access rules are graphically determined and collected from GUI277 for inclusion in the document (eg, header security information). In one embodiment, access rules are maintained in an optionally encrypted temporary file (eg, markup language format) associated with the specified folder. When the document is written to local storage as a protected file, the temporary file can be attached to the cipher.

【0075】

At times, users need to export or import a set of predefined access rules. In this case, the temporary file containing the access rules is exported, stage loaded, and imported into another device or folder. Access rule export / import is convenient for the user because the user does not have to create the access rule from scratch.

【0076】

One of the features of setting a set of access rules for a particular location or folder is to give the user a protective mechanism to create a protected document without specifying who, how, when, or where to access the document. That is. FIG. 2E is an explanatory diagram of the directory structure 280 including the clear folder 281 and the protected folder 282. Clear folder 281 generally stores system files and files that are not intended to be protected. Protected folder 282 contains a large number of subfolders configured for each access level. For example, the document "Employee List" is accessed by anyone with Level A access privileges. Similarly, the document "Product Milestone" and "Product Specifications" or "Product Schedule" are granted access level B access privileges to folder 284 and access level C access privileges to folder 286. Accessed by a given person. Similarly, the created document, when placed in the folder "Design Team 2", is automatically encrypted with a corresponding access rule that allows only those who have access privileges up to access level B. In the case of this embodiment, the access level is hierarchical, that is, the user of the access level A authentication is not only the item of the access A but also a subset of the access level A, and the access level is lower than the access level A. B and C are also accessible.

【0077】

Unlike conventional systems in which a document to be protected is encrypted by a user-initiated encryption process, one feature of the present invention is that the encryption process (as far as the user is concerned is unnoticed by the user). That is, the encryption / decryption process) is activated. In other words, the user is unaware that the document is protected by cryptographic processing while it is being written to storage.

【0078】

Figure 3 shows that a document protection module (DSM) 302 interacts with operating system 304 (eg, WINDOWS® 2000) in it to ensure that the document is protected unnoticed by the user. It is explanatory drawing of the example of the embodiment of the method of operation.

【0079】

Application 306 (eg, a server-registered application such as Microsoft Word®) runs on operating system (OS) 304 and is activated to access documents held in storage 308. Storage device 308 is a local storage location (eg, a hard disk) or a remote location (eg, another device). Depending on the security characteristics (protected, unprotected) of the document being accessed, the DSM302 activates the cryptographic module 310. According to one embodiment, the DSM302 is in many ways similar to a device driver that, in principle, translates the very common I / O instructions of an operating system into messages that can be understood by supported devices / modules. Depending on the OS in which the present invention is implemented, DSM is implemented as a VxD (Virtual Device Driver), kernel, or other applicable format. Cryptographic module 310 is housed in or controlled by DSM302 and is activated for operation when protected documents are handled.

【0080】

During operation, the user selects a protected document associated with application 306 (eg, MS WORD, PowerPoint, or print). Application 306 uses the Win32 API to createFile and Common Dialog File Open in APIs (eg, MS Windows®) to access the Implementable File System (IFS) 312. Acts on protected documents that call Dialog). If it is detected that an "open" request has been made by application 306, the request is communicated to the appropriate file system driver (FSD) 314 to access the protected document at the request destination. At the same time, the cryptographic module 310 is activated and the authenticated user key is obtained from the local storage device to decrypt the header of the requested protected document. When the cryptographic header is decrypted and the access rules in it pass the comparison with the user's access privileges, the file key is obtained from the header of the protected document and the cryptographic module 310 decrypts the cryptographic document within DSM302. .. Clear content is returned to application 306 via IFS Manager 312. For example, if application 306 is an authoring tool, clear content will be displayed. If application 306 is a print rule, clear content is sent to the specified printer.

【0081】

If a "new" request is detected, i.e. a protected document is created or written, a file key is generated by DSM302 (eg, by cryptographic module 310), and this file key is then the document being created. Used to encrypt the contents of. To ensure that the local storage always holds the cryptographic document, every time any content in the processed or created document is encrypted with the DSM302 file key using the cryptographic module 310. , A "write" request (eg, a Microsoft Word "save" command) is made manually by the user, or automatically by application 306 or OS 304. When a "close" request is made, the file key is held in a header containing any access rules applied by the user. The header is then encrypted with the authenticated user key and the document is sent to a suitable FSD (eg, 314) for storage in storage 308 (eg, a folder or a designated location). Attached to the encrypted document.

【0082】

In another embodiment, operating system (OS) access, known as the ProcessID property, is used to run the application (as an argument to the AppActivate method). The parameter ProcessID is required to identify the application and the event handler for that application to continue OS access to the Implementable File System (IFS) Manager 312, which is responsible for mediating access to various file system components. Take a parameter. In particular, IFS Manager 312 is configured to act as an entry point for processes such as opening (opening), closing (closing), reading (reading), and writing (writing) files. This access activates the DSM302 by transmitting one or more flags or parameters. If the document being accessed by the application is normal (unprotected), the document is obtained from a single file system driver (FSD) (eg, FSD314), propagated via DSM302, and then through IFS Manager 312. Loaded into the application via. On the other hand, if the document accessed by the application is protected, the DSM302 activates the cryptographic module 310 and proceeds to obtain the authenticated user key in order to obtain the access rule. When the access privilege satisfies the access rule, the file key is acquired because the encrypted data part of the protected document is decrypted by the encryption device. As a result, the clear mode data section or document is loaded into the application via IFS Manager 312.

【0083】

According to one embodiment, the DSM302 resides on a local disk (eg, storage 136 in Figure 1D) within a file constructed like a dynamically linked library (DLL) and typically has a SYS or IFS extension. It has children and is loaded during system initialization. After DSM302 is installed and initialized, the kernel communicates with DSM302 for logical requests such as file open, read, write, seek, and close. Through IFS Manager 312, FSD314 translates these requests into sector read and write requests using the control structures and tables found on its own volume, and for that request File System Helpers (FsHlps). ) Calls a special kernel entry point. The kernel passes the sector I / O request to the appropriate device driver and returns the result (eg, the requested document) to FSD314. After receiving a result from FSD314 that the requested document has been protected, the DSM302 will use the internal cryptographic module 310 to decrypt the document, if permitted by the protected document access rules. Operate.

【0084】

FIG. 4A is a flowchart of the process 400 for protecting the document created by the embodiment of the present invention. At step 402, a blank document is opened or created by an authoring application selected or activated by the user. According to one preferred process, the user stores the document in an already established folder using a set of access rules. At step 404, a set of predetermined access rules is received, preferably in markup language. As mentioned above, access rules may be obtained by importing a pre-created file containing the desired access rules, user access privilege defaults, or individually created user access privileges.

【0085】

At step 406, the private cryptographic key (ie, the file key) is generated from the cryptographic module for the document and is typically stored in a temporary file that is generally inaccessible to normal users. Temporary files are automatically erased when the protected document exits (for example, with a "close" command from the application). At step 408, the document is inspected to see if a request has been made to write the document to local storage. If such a request is detected (this request may be made manually by the user or periodically by the authoring tool or OS), the document is encrypted with the file key in step 410. File. One of the features of the present invention is that the stored document is always encrypted in the storage device, even during processing (eg, being created, being edited, or being revised). When the user exits the document, the "close" request is enabled to close the document. At step 412, such a request is detected. As soon as such a request is obtained, a protected version of the document is written to storage. In step 413, the access rule and file key are contained in the security information encrypted with the authenticated user key. Depending on the embodiment, flags or signatures and security information are contained in the header. Alternatively, the header may contain unflagged security information. At step 414, the header is attached to the encrypted document from step 410, and then the protected document is stored in storage at step 418.

【0086】

As described above, the protected document is composed of a header containing cryptographic security information and two cryptographic parts, a cryptographic data part (that is, a cryptographic document). The two parts of this protected document are each encrypted with two different keys, a file key and a user key. Alternatively, the two ciphers may be re-encrypted in step 416 with different keys (or with the same user key).

【0087】

If there are a large number of sets of access rules for a particular user or group of users, the cryptographic access rules in step 413, along with the other sets of cryptographic access rules, are within the rule block as shown in Figure 2C.2. It can be seen that it is integrated into. In this way, access from one user or group does not affect other users or groups, but other users or groups can probably see the updated version of the cipher manuscript.

【0088】

FIG. 4B is a flowchart of an example of the process 430 for acquiring the access rule. Process 430 is performed in step 404 of FIG. 4A to facilitate the document protection process. In order to reduce the load on the user, the present invention provides a one-time authentication mechanism as described later. This authentication mechanism differs significantly from prior art systems where user authentication is required for each access to a protected document. During operation, once the user is authenticated for access to the protected document, user authentication is no longer required. In addition, after the user is authenticated, the user can access other protected documents without being re-authenticated.

【0089】

In general, there are at least two situations in which a user must be authenticated before they can access the protected document. In the first situation, the client device is connected to a network (eg LAN) and the user of the client device needs to authenticate himself by providing his credentials the first time he uses the client device. is there. Credentials are generally a set of username and password. If the user is registered and the credentials given match the user's identity in the server, the user is authenticated. When the user is authenticated, the user key associated with the user is activated or authenticated. The user will be able to use the client device and then access the protected document. Other feasible credentials include, for example, user biometric information such as fingerprints, voices, etc. that can be obtained from a dedicated device on the client device. An example of such a device is CA 94063, Redwood City, Suite 301, 805 A fingerprint sensor from Digital Persona Incorporated in Veterans Boulevard. When the user's biometric information is captured, the user's claimed rights can be verified. Depending on the embodiment, the user key may be stored locally or retrieved remotely. In either case, the user key is preferably in an unbreakable format (eg, encrypted or scrambled with a passphrase associated with the user) to prevent possible hacking of the user key before it is authenticated. There is.).

【0090】

User authentication, or user biometric information, is used to validate, obtain, or authenticate a user key. As a result, the user key authenticated in clear form becomes readily available for the user to access any protected document. In the second situation, the networked client device can tolerate everything that the client device user intends to do other than requesting a protected document. In the case of a request for a protected document, the user authentication process is called.

【0091】

Again, referring to FIG. 4B, the user authentication process is called and communication to the server (eg, server 104 or 106) is checked in step 432. If no available communication to the server is detected, that is, the client device is not on the network, the server is down, or there are other causes, the user has at least three ways. A range of choices is given. First, the user may access only unprotected documents or generate protected documents in step 434 if the public key is available or maintained on the client device. It is possible. Second, the user can continue trying to communicate with the server, in which case process 430 returns to step 432 until a protected communication link is established. Third, the user takes advantage of another feature provided by the present invention, offline access. That is, the number of protected documents that the user has access to on the client device is limited. Details will be described later.

【0092】

Consider the case where a secure link (preferably via HTTPS, VPN, SSL) is established between the client device and the server. Process 430 needs to go to step 436 to authenticate the user and / or client device itself. In some cases, protected documents need to be guaranteed to be accessed only by users from authorized devices. Therefore, in such cases, it is necessary to authenticate the user and the client device when the user accesses the protected document.

【0093】

As far as the user is concerned, the user needs to provide his credentials (eg username / password) to be verified. After the user is authenticated by the server, the client device needs to be authenticated. Specified that the user has access to the protected documents to ensure that the user is restricted to one or more designated local computers and that the user has access to only the protected documents from these designated local computers. Decide if you want to use one of your local computers. During operation, at step 436, 1) Whether this client device can be used to access protected documents, as well as 2) The client device identifier (eg, the number from the network card) is checked by the server to determine if the client device and user combination is valid. If this inspection process is successful, process 430 proceeds to step 438, otherwise the user works only on the unprotected documents in step 434.

【0094】

The user key associated with the user is authenticated in step 438. At this point, the user has access to the protected document. Certainly, the user's corresponding access privileges and the access rules for the protected document ultimately determine whether the user can open the protected document.

【0095】

After the user and the client device used by this user are each authenticated or verified, the user key is in a valid state (for example, ready to be used). The user key is newly generated or stored in an undecipherable format. The user authentication process obtains the user key in an easily usable format and / or gives the user key to the client device.

【0096】

It is assumed that the user is accessing the protected document or editing the protected document. At step 440, the user access privilege originally set by the administrator is enabled, and this user access privilege determines the location and type of access to the protected document. Similarly, default access rules for specific folders that store protected documents are made available or collected for viewing in step 442. This default access rule can be stored in a temporary file that is accessed by the user or finally attached (in cryptographic format) to the cipher manuscript created.

【0097】

The description of process 430 in FIG. 4B is based on the user authentication process formed in conjunction with the server. However, as will be apparent to those skilled in the art, this description is readily applicable to other means for performing user authentication. For example, as described above, the user key is authenticated, verified, or acquired by the biometric information of the user.

【0098】

With reference to FIG. 4C, a flowchart of the protected document access process 450 according to one embodiment is shown. This should be understood in conjunction with Figure 3. At step 452, the application is started with the specified document. For example, WINWORD.EXE has the file name xyz. Activated to open doc files. As mentioned above, the handler from the OS identifies the application, enters the OS, and in step 454 the IFS manager is called. The IFS manager activates the DSM module in step 456, while the IFS manager passes the handler in step 458 to retrieve the selected document from storage. Since the selected document passes through the DSM module, it is determined in step 460 whether the selected document is protected or unprotected. In general, there are at least two ways to check the protection properties of a selected document. The first possible method is for the DSM module to look for the flag at the beginning of the document. As mentioned above, in some protected documents, flags such as a given set of data are placed in the header to indicate that the document being accessed is protected. If no such flag is found, process 450 proceeds to step 470. That is, the selected document is considered unprotected, allowed through the DSM module, and loaded from the IFS manager into the application. The second possible method is for the DSM module to look for the header of the protected document. In the case of a protected document, a header is attached to the encrypted data part. The data format of the header should be irregular when compared to unprotected documents. If the DSM module determines that the irregular data format required by the application does not exist in the selected document, this process 450 proceeds to step 470. That is, the selected document is considered unprotected, allowed through the DSM module, and loaded from the IFS manager into the application.

【0099】

If it is determined in step 460 that the selected document is truly protected, process 450 proceeds to step 462 and the header or security information in the header is decrypted with the authenticated user key. In step 464, the access rule in the decryption security information is obtained. At step 466, the access rule is compared (matched) with the access privileges associated with the user. If the match fails, i.e. the user is not allowed to access a particular document, a notification or warning message will be generated by the DSM module and presented to the user in step 467. Alternatively, the application itself may display a warning message when it fails to open the selected document. If this match is passed, that is, when the user is granted access to a particular document, the file key is obtained from the security bulletin in step 468 and the encrypted data portion of the selected (protected) document is DSM. Used to decrypt with the cryptographic module activated by the module. As a result, in step 470, the clear content of the decrypted or selected document is loaded from the IFS manager into the application.

【0100】

Referring to FIG. 5A, a functional block diagram of a server unit 500 in which a server module 502, which can be executed by one or more processors 501, is mounted in memory space 503 is shown. The server device 500 includes a network interface 504 for facilitating communication between the server 500 and other devices on the network and the local storage space 505. Server module 502 is a viable version of an embodiment of the invention that, when implemented, produces the features / results considered in the invention. According to one embodiment, the server module 502 includes a management interface 506, an account manager 508, a user key manager 510, a user monitor 512, a local server manager 514, and a partner access manager 516. The access report manager 518 and the rule manager 520 are provided.

【0101】

About management interface 506 As the name implies, management interface 506 makes it easy for system administrators to register users and grant them access privileges, and all submodules, or their results, are initialized. An entry point for server modules that are updated and managed. In one embodiment, the system administrator sets various active folders, storage locations, and hierarchical access levels for users or groups of users. For example, Figure 5B. As shown in 1, different users are assigned different access privileges. User A is an executive or branch manager who has been granted access privileges to any protected document. User B has restricted access privileges, and all members of user group C share the same access privileges. Privileges include, but are not limited to, open, edit, write, print, copy, download, or other privileges. Examples of other privileges include changing the access privileges of other users, accessing protected documents from one or more locations, and setting access rule sets for folders that are different from the ones previously set. Included (these are probably done by your system administrator). By using each user ID assigned to a user, management of all users becomes easy. Unless otherwise noted, a user or corresponding user ID is used interchangeably to identify a person, a software agent, a group of users, and / or a group of software agents. Software applications or agents, as well as users requesting access to the protected document, may need to access the protected document in order to proceed forward. Therefore, unless otherwise noted, the term "user" does not necessarily mean a person. Generally, a user who accesses a protected document is associated with a user key that can decrypt (decrypt) the encryption head in the protected document. The expiration or reissue of the user key is initiated by the system administrator. According to one embodiment, management interface 506 is a user graphic interface that presents a selection for various tasks to be performed by an authenticated system administrator or operator.

【0102】

About Account Manager 508 In principle, the account manager is a database that holds all registered users, the access privileges of each registered user, and possibly the corresponding user keys (eg, private and public keys), or database 507 (eg, database 507). , Oracle database). During operation, Account Manager 508 authenticates the user when the user logs on to Server 500 and determines if the user can access the protected document from his current location. In general, Account Manager 508 allows a company to control its users.

【0103】

About User Key Manager 510 This module is configured to keep a copy of the key for each user in the organization. According to one embodiment, the user key manager 510 is not activated to acquire a key. In some situations, the key is a system administrator to access the protected document in cases where the key in the client device has been tampered with or the user who has been granted access privileges to access the protected document is no longer valid. Acquired by. Optionally, the User Key Manager 510 is configured to revoke some or all of the keys for security reasons. In some cases, the user leaves the organization and the corresponding user key is manually revoked within the User Key Manager 510. In another case, the user's key is used for a long time, and the user key manager revokes the old user's key and replaces the old user's key with a newly generated key. Such substitutions are made unnoticed by the user, and the new key is uploaded to the client device the next time the user logs on. According to another embodiment, the user key manager 510 keeps a private key and a public key for each user. The public key is used to encrypt the header security information, and the private key is used to decrypt the header security information. Figure 5B.2 is an explanatory diagram of an example of a table held by User Key Manager 510 in collaboration with Account Manager 508.

【0104】

About user monitor 512 This module is configured to monitor user requests and whereabouts. Typically, users are allowed to access protected documents from one or more designated locations or networked computers. If the user is granted higher access privileges (for example, if access is allowed from other than the location or networked computer), the User Monitor 512 will always have the user in a registered location or computer. It is configured to guarantee that only one access right is given from one of the above. Moreover, the user monitor 512 is configured and scheduled to periodically push for access privilege updates or to respond to requests for access privilege updates.

【0105】

About Local Server Manager 514 This module is designed to serve to distribute the appropriate local module for a given location or local server acting for a given group of users. According to one embodiment, the local server manager 514 replicates some or all of the server module 514 running on server 500 and distributes the duplicated copy to all local servers. As a result, the user can access the protected document from anywhere within the network facility targeted by the local server without being authenticated by a single central server, the server 500. According to another embodiment, local server manager 514 replicates a portion of server module 502 running on server 500 and distributes it to the corresponding local server. In the case of this embodiment, each local server comprises a replica made individually from server module 502. When a user is granted sufficiently high access privileges (for example, access from more than one location or more than one computer is allowed), User Monitor 512 is a service provided by the user on a local server. You can detect that you have moved from the originally configured location to another authorized location that enjoys the services of another local server. After notification, Local Server Manager 514 is configured to reconfigure the local module for the local server that the user has newly contacted. That is, the user is added as a user to the newly contacted local server. If a user is required to be accessible from only one computer at a time, regardless of where he or she is in the organization, the local server manager 514 will use the local server with which the user was previously contacted. It is possible to reconfigure the local module for. As a result, the user is removed from the local server with which the user was previously in contact.

【0106】

About Partner Access Manager 516 This is a special module for managing non-employee accounts. A non-employee may be a consultant for a business that requires the consultant to access certain protected documents. The partner access manager 516 generally operates according to the modules of the server, but imposes additional restrictions on users who are directly managed by the partner access manager 516. In one application, Partner Access Manager 516 generates a request to User Key Manager 510 to revoke a key or key pair for a consultant when the contract with the consultant expires.

【0107】

About Access Report Manager 518 This module is configured to record or track possible access behavior and primarily works with the corresponding submodule within the client module running on the client device. The access report manager 518 is preferably operated by the system administrator, and the content collected by the access report manager 518 is accessed only by the system administrator or an authorized person.

【0108】

About Rule Manager 520 In general, Rule Manager 520 is the enforcement mechanism for various access rules. According to one aspect, Rule Manager 520 i) data type (eg Microsoft) It is configured to specify rules based on Word®)), ii) group users or individuals, iii) applicable rights, and iv) access rule duration. A set of rules is typically a policy. Policies can be allowed, banned, edited, deployed, and revoked (eg, level 1-2). Policies managed by Rule Manager 520 preferably operate at the global level. The policy is downloaded to the client device (after the user is authenticated) during the login process and updated dynamically. In addition, each policy is associated with an active folder (ie, the location specified to store protected documents). These policies are downloaded and updated on the client device. A simple policy is embedded in the document and gives a document-only policy. According to one embodiment, the header is retrieved from the client by the local server and the access rules are retrieved from the header. The key manager 510 is called to decrypt the cryptographic security information in the header. Rule manager 520 is called to parse the access rule from the security bulletin and evaluate or compare the access rule with the user's access privilege to determine if the protected document is accessible by the user. If the evaluation or comparison is successful, the file key is retrieved and returned to the client.

【0109】

The server module 502 in FIG. 5A lists some exemplary modules according to an embodiment of the present invention, but in order to carry out the present invention, not all modules of the server module 502 are necessarily implemented. Does not have to be incorporated. As will be apparent to those skilled in the art from the matters described, the various combinations of modules and modules variants will not deviate from the spirit of the invention and will have the various desirable functions, benefits and effects considered in the present invention. To achieve.

【0110】

With reference to FIG. 5B.3, a flowchart of the process 510 for updating the user key is shown. As mentioned above, in some cases it is necessary to expire the user key and to renew the expired user key with a new user key. Preferably, process 510 proceeds unnoticed by, for example, when the user logs on to the server. As an option, the user is notified of the update of their user key. In general, there are at least two situations that require a user key to be revoked / renewed. When a user leaves the organization, for security reasons it is desirable to invalidate the user key associated with that user. Therefore, in step 511, process 510 awaits a manual request. Such a manual request can be made when the system administrator is notified of an employee's turnover.

【0111】

Alternatively, the organization or system administrator can set an expired timetable for any managed user key, for example, every 6 months, to replace the expired user key with a new user key. In step 512, this process awaits a timed request.

【0112】

In either case, when process 510 is advanced at the request from step 511 or 512, at step 514 the server module key manager looks up the user key being targeted or the user key being sought. It will be used as a reference. When the key of interest is obtained, the corresponding new key is generated by cryptography in step 516. According to one embodiment, the cipher used is the same as or substantially the same as the cipher used in the client module to encrypt / decrypt the header of the protected document. This ensures that the newly generated user key can be used when it is available on the client device. According to another embodiment, the key pair associated with the user is updated. Since the two keys are held on the server and never left the server, a suitable cipher can be applied to update the user key.

【0113】

Depending on the actual situation and embodiment in which the user key is replaced, the newly generated key is retained in the key manager or to the client device the next time the corresponding user logs on from the client device. Handed over. In step 518, process 510 waits for the decision whether to leave the newly generated key on the server side or download it to the client side. If it is decided to keep the newly generated key on the server, process 510 proceeds to step 520 and the new key is associated with the same user. If the next time the user logs on to the server, it is decided to hand over the newly generated key to the user, process 510 proceeds to step 522. In step 522, process 510 waits for contact from the user. As mentioned above, the user can log on from the client device at any time when the protected document needs to be accessed. When such a contact occurs, the server receives credentials from a user who seeks to prove that he or she is a credential holder. After the user is authenticated, the new key is encrypted with the credentials in step 524. Credentials are given by the user when requesting authentication and include a username / password pair or a biometric feature of the user (eg, a fingerprint). Regardless of what cipher is used, the newly generated key is uploaded or transmitted to the client device in step 526. After receiving the new encrypted key, the client device is encrypted in step 528 to make the new user key readily available to access the protected document or to protect the document. You are ready to decrypt the new key. In some cases, the client module of the client device is scheduled to inspect (scan) all available protected documents with headers that are primitively encrypted with the old user key in the specified folder. Will be done. These documents are really protected documents To ensure that, it will be re-encrypted with the new key. According to one preferred embodiment, the user key update can be performed unnoticed as far as the user is concerned. In other words, the user is unaware that process 510 is taking place and that a new key has been installed.

【0114】

Referring to FIG. 5B.4, a flowchart of server assisted processing 530 accessing a protected document according to an embodiment of the present invention is shown. The process 530 will be described with reference to FIG. One of the features of process 530 is that the user key (ie, the private key and the public key) does not leave the server that generated the key, as described below, thereby ensuring key security. Level is improved.

【0115】

Suppose a user tries to access a protected document from a client device and is authenticated by a server (for example, server 500) that runs access control management. When a protected document is selected, the document protection module (DSM) 302 of FIG. 3 determines that a user key is required to access the security information in the protected document. According to this embodiment, the DSM 302 is configured to separate the header from the protected document and send the header to the server. At step 532, such a header is received from the client device. As described below, the header contains cryptographic security information. At step 534, the private user key associated with the user is retrieved. The private user key is retrieved, for example, from the key manager. The cryptographic security information in the header is then decrypted with the retrieved private user key in step 536. As a result, the access rule for this protected document is acquired in step 538.

【0116】

At the same time, the user's access privileges are reclaimed in step 540. Access privileges are retrieved, for example, from the account manager. If access privileges and document access rules are given, an evaluation is performed in step 542 to determine if the access rights can be granted. If the user's access privileges do not allow access according to the access rules, the process proceeds to step 544. At step 544, an error message is generated to transfer to the client device, which tells the user that his access privileges do not allow access to the selected document. However, on the other hand, if the user's access privileges allow access according to the access rules, the process proceeds to step 546. At step 546, the file key in the security bulletin is retrieved. In step 548, the file key is transferred to the client device. Upon receiving the file key, the DSM 302 activates the encryption module 310 to decrypt the encrypted data portion of the selected document.

【0117】

FIG. 5B.5 is a flowchart of the server support process 550 for document protection according to an embodiment of the present invention. The process 550 will be described with reference to FIG. Consider the case where the user has just finished the document and decides to protect the document. One possible way to protect a document is to put it in a preset designated folder or a designated folder associated with a set of access rules, as described above. In other words, all documents in a folder are given virtually the same access rules.

【0118】

Therefore, the DSM302 is activated, and the DSM302 then activates the cryptographic module 310. When the document is protected for the first time, the cryptographic module 310 generates a new file key. If the file key already exists, the cryptographic module 310 typically does not generate a new file key unless requested. It is assumed that the user is authenticated and the link between the client device and the server is established before the process 550 starts.

【0119】

After receiving the file key from the client device in step 552, the public user key associated with the user is retrieved in step 554, for example, from the key manager. The access rule for the document is obtained in step 556. As mentioned above, access rules can be obtained in a number of ways. One possible method is to receive access rules directly from the client device. Another possible method is to get access rules locally from the rule manager if the document is stored in a folder set by the system. Given the access rules and file key, it is possible to form security information in step 558. The security information is encrypted with the public user key in step 560. According to an embodiment similar to Figure 2C.2, access rules and file keys are placed in a segment if another segment already exists within the rule block.

【0120】

At step 562, a header for the document is generated. Depending on the embodiment, the header may include other unencrypted information (eg, flags). Alternatively, a user block containing the current user is added to the header. The header is transferred to the client device in step 565, where the header is attached to or integrated with the cryptographic data section to generate a protected document. Note that process 550 is also applicable when the protected document is revised and stored in a storage device.

【0121】

FIG. 5C is a functional block diagram of the local server device 570. The local server unit 570 is generally similar to the server shown in Figure 5A. Therefore, the large number of parts shown in FIG. 5C will not be described repeatedly in order to avoid obscuring aspects of the present invention. As shown in FIG. 5C, the local server unit 570 executes a module called the local module 570, which is configured to be a complete or partial replica of the server module 502 of FIG. 5A. .. As one of the features of the present invention, the local module 572 provides reliability, certainty, and scalability of centralized access control management performed by the central server 500 of FIG. 5A. Therefore, it is not always necessary to handle all authentication requests at one central point without losing control of access control management. Another feature of the invention is that the user is unaffected if the central server is down for maintenance and if the connection to the central server is unavailable. When a large number of local servers are used and each local server has a copy of the server module, the reliability of the service provided to the user is significantly improved. The possibility that a user wants to access a protected document and cannot be authenticated is minimized.

【0122】

According to one embodiment, local module 572 is some localized version of server module 502 on central server 500, servicing users near the local server. For example, Figure 5D shows Table 584 for all users managed by Central Server 500. Among users, John's access privilege 585 is level 10 (which is considered to be the highest level), and protected documents can be accessed from any of the three locations at any time and every day. Dell Access Privilege 586 is Level 1 (the lowest level) and has access to protected documents from Location A only, Monday through Friday, 8 hours a day (for example, 9 am to 5 pm). It is possible. Mike's access privilege 586 is Level 5 and allows access to protected documents from locations A and B 12 hours a day, Monday through Saturday. If the local server is used separately for the three locations A, B and C, there are three types of access control management possibilities assigned to each local server, as shown in Figure 5E. To do. As a result, the local user only has to inspect on the corresponding local server, and the user is disconnected from the central server, even if another local server is down for any reason. Even if it is, it will not be affected.

【0123】

Figure 5F shows the accessibility of each user. Working with User Monitor 512 on Server Module 500, Local Module 572 can be dynamically configured. In one embodiment, instead of providing three local modules to allow John to access from any of the three locations in each local module, the locations that John can access at the same time are: Only one local module is configured to be one of the three locations. One of the additional security benefits provided by this dynamic configuration mechanism is that John can access protected documents in only one location at a time. In practice, this is an undesirable security feature for anyone who logs in to the system or accesses protected documents from two physical locations at the same time. Also, for security reasons, preferably users are only allowed one access location at a time, regardless of their access privileges.

【0124】

Figure 5G shows a dynamic configuration that affects access control management. At one point, the system recognizes that John is accessing from location A. When John moves to location B, upon John's login, a central server (for example, the server module's user monitor) detects John's whereabouts and tells local server manager 514 that location A and location. Notify you to reconfigure both local modules in B. As shown in Figure 5G, local access control management 589 on the local server in location A has finished its role for John, and local access control management 590 in the local server in location B has the functionality for John. take over. As a result, John is allowed access to the protected document from location B, but not from location A. Figure 5H is a graphic representation of John's accessibility moving from location A to location B. In this way, John, along with Mike, will be able to access the protected document from location B, and both will be temporarily not allowed to access the protected document from location A.

【0125】

If Mike moves location A, the local module will be reconfigured as shown in Figure 5I. John's access privileges allow John to access protected documents from location C if he moves to location C.

【0126】

FIG. 6A is a flowchart of the user authentication process 600 incorporated in the central server 500 or the local server 570. As mentioned above, processing 600 is required in at least two situations: the initial login to the networked client device and the initial access to the protected document. When either situation arises, the client module in the client device initiates a request sent to the server running the module that performs access control management in order to initiate processing 600.

【0127】

At step 602, the server listens for the request. Upon receiving the request from the client device, the server proceeds to step 604 to determine if the user and the client device that the user uses to access the protected document are authenticated or copper. If both have already been authenticated, no further authentication process is performed on the user or client device. On the other hand, when the user and the client device have not been authenticated yet, the authentication process is continued. According to one embodiment, the server establishes a secure link with the client device if both the server and the client device are connected to the public network. Such links are supported over HTTPS or through VPN. Alternatively, if another authentication means is used, a direct link is established between the client device and the server.

【0128】

In step 606, the server responds to the request received with the authentication response. Depending on the embodiment, such a response is a dialog box, command, or other request that should be displayed on the screen of the client device. In either case, this response requires that the credentials be given by the user. As described above, the credential information is a set of user name and password, biometric information of the user, etc., and needs to be received from the user in step 608 before the authentication process proceeds.

【0129】

Upon receiving the credentials in step 610, the server is allowed access to protected documents held by the user in the repository, local storage, the server itself, or any other device accessible over the network. You need to determine if you are a user. This determination includes matching the received credential with what is pre-stored on the server. The server may be a central server or a local server. As will be apparent to those skilled in the art, this commentary applies equally in both situations. If the collation fails, that is, if the user is not authenticated, process 600 returns to the beginning and continues listening for the request. In other words, the current request for access to protected documents or login to the system is waived. If the trade name is successful, the user is recognized as an authenticated user.

【0130】

At the same time, the client device will probably be subject to similar authentication by its IP address, or network card identification information, or other means of individually identifying the client device.

【0131】

If both the user and the client device are authenticated, process 600 proceeds to step 612, where the user's access privileges are reclaimed and put into a valid state. Depending on the embodiment, enabling the user's access privilege can be to download the file containing the access privilege to the client device, decrypt the local file containing the access privilege, or simply the memory space of the server. To enable the user within. In either case, at this point the user's access privileges are readily accessible and the user is allowed to access the protected document from an authenticated client device.

【0132】

According to one embodiment, XML-RPC is used to facilitate communication between a server (eg, a local server or a central server) and a client device. XML-RPC is an easy and portable way to make remote procedure calls over HTTP. XML-RPC can be used with Perl, Java, Python, C, C ++, PHP, and other programming languages. In addition, XML-RPC allows software running on different operating systems and software running in different environments to make procedural calls over the data network. This is a remote procedure call that uses HTTP as the transport and XML as the encoding. XML-RPC is designed to be as simple as possible, while allowing the transmission, processing and return of complex data structures.

【0133】

In an embodiment implementing a dynamic configuration mechanism, the user is allowed to contact the server from the client device and the local module in the local server is allowed to service the user from the client module at the current location. It is inspected to determine if it is possible. If not allowed, the local server communicates with the central server to determine whether the local server should be reconfigured or updated to next support users from the client module at the current location. When the local module is reconfigured, the user and client device are authenticated and the user's access privileges are made accessible, which allows the user to access the protected document from the authenticated client device. Will be done.

【0134】

Following the above embodiment, one or more local servers are utilized to maintain a localized version of the server module so that only localized access control management is performed. FIG. 6B is a flowchart of process 620 embedded in one or more local servers to dynamically configure access control management. Process 620 is performed in steps 610 and 612 of FIG. 6A. In step 610, the user is determined to be authenticated. Next, in step 622, the server needs to determine the number of locations or the number of computers that the user is allowed to access the protected document. During operation, the user's access privileges are checked. Typically, the user's access privileges are the location (eg, authorized location, geographic location, or local area network), and / or. , Contains information that identifies the local computer available to the user (eg, an authorized computer). In some cases, users frequently move between several offices in several geographic locations, so users access protected documents from either their geographic location / computer. You are given the privilege of being able to.

【0135】

In step 624, the current location of the receiving requesting user is checked to determine if it is a location granted with access privileges. If the current location is not among the allowed locations, process 620 proceeds to step 626 to send a notification to the user or simply reject the request. If the current location is included in the allowed locations, process 620 proceeds to step 628, where the local manager performing the currently localized access control management is localized by the user. It is checked to determine if it is under access control management (for example, in local server manager 514 in Figure 5A). If the user is controlled by localized access control management by the local module, the process proceeds to step 612 of FIG. 6A. If the user is not controlled by localized access control management by a local module, the server in step 630 which local module previously provided localized access control management to the user. It is necessary to determine whether it is. After the information has been collected from the local modules of the various local servers, the local module reconfiguration takes place in step 632. In essence, user assistance is removed from one local module and added to another local module, as shown in Figure 6C.

【0136】

At step 634, the newly configured local modules are uploaded to the corresponding local servers, respectively. As a result, users will be able to access protected documents from new locations, ensuring that the system is always allowed access from only one location / computer.

【0137】

One of the features of the mechanism for dynamically reconfiguring the local module is the reliability, certainty, and scalability of the central access control management by the central server 500 in FIG. 5A. If the enterprise has a large number of employees in many locations, local servers can be added to meet the needs without compromising performance. In practice, users are largely unaffected during a given period of time if their respective connections between the central server and the local server are unavailable.

【0138】

FIG. 6C is a flowchart of process 640 for reconfiguring the local / module according to one embodiment. Process 640 is, for example, the process executed in step 632 of FIG. 6B. In step 642, the first local module that previously assisted the user at the first location is identified. At step 644, the first local module is configured to, in principle, remove support for the user at the first location. The newly configured first local module is then uploaded to the corresponding local server enabled in step 646, so that the user is no longer supported on the local server. At step 648, a second local module is identified to assist the user at the second location (ie, the user's current location). At step 650, the second local module is essentially reconfigured to add support to the user at the second location. The newly configured second local module is uploaded to the corresponding local server that should be enabled in step 652 and the user is supported on that local server.

【0139】

Configuring user access to protected documents is sometimes referred to as the provisioning process. The dynamic provisioning described above is believed to provide the necessary security measures required by large enterprises with employees in several locations without losing centralized access control management on the central server. In addition, reliability, certainty, and scalability can be increased by using a large number of local servers to assist the central server.

【0140】

A functional block diagram of the client device 700 is shown with reference to FIG. 7A. The client device 700 is mainly a computer device used by a user who accesses a protected document. The client device 700 may be, for example, a desktop computer, a portable device, or a laptop computer. According to one embodiment, the client device 700 has a processor 701, a client module 702, a memory space 703, a network interface 705, and a local storage device 707. The client module 702 is located in the memory space 703 and realizes the features, effects and advantages considered in the present invention when executed by the processor 701. Through the network interface 705, the client device 700 has the ability to communicate with other computers, such as servers, over the data network. From the client device 700, the user can access the protected documents contained in the repository (storage device) 706. The repository 706 is provided on the client device 700, another network connection device, or other storage means. Client module 702 is an executable version of an embodiment of the present invention. According to one embodiment, the client module 702 is a number of submodules including an access reporting module 704, a user matching module 710, a key manager 708, a document protection module 711, and an offline access module 714. Have.

【0141】

About access reporting module 704 This module is a software agent configured to record access behavior and is associated with authenticated users. Since this module reports to the access reporting module of the central server, a record of the protected documents accessed, the users accessed, and the time of access is set. In particular, the access reporting module 705 is activated to capture user access behavior when the client device is not networked. Access behavior is later synchronized with the corresponding part of the server, facilitating access control management for offline access.

【0142】

About Key Manager 708 One purpose of Key Manager 708 is to ensure that protected documents are kept available when they are being accessed by an application that suddenly stops. According to one embodiment, after the encryption header is decrypted, the file key is copied and the copy of the file key is stored (cached) in the key manager 708. The file key is then used to decrypt the encrypted document. Clear documents will be available from the application. If the application is stopped due to a power failure or interference from another application or OS, the file key in the header may be corrupted. If a copy of the file key is not available, the encrypted document cannot be decrypted without the file key and the protected document cannot be used. In this case, the spare key stored in the key manager is used to replace the damaged key and decrypt the cipher manuscript. After the user saves the file again, the file key is returned in the header. Another purpose of Key Manager 708 is to cache (hide) the user key of an authenticated user.

【0143】

About user verification module 710 This module is responsible for determining if the user accessing the protected document has been authenticated, and if not, triggers a request for authentication by the local or central server. That is, the user matching module 710 is always inspected before granting permission to the user seeking access to the protected document. According to one embodiment, the user key of the authenticated user is stored (cached) in the key manager 708 after the user is authenticated by the user verification module via the server. When the protected document is accessed, the user key should be retrieved from Key Manager 708 to decrypt the cryptographic security information in the protected document header.

【0144】

About document protection module 711 As mentioned above, the DSM711 comprises an encryption device 712 used to generate a file key / user key and encrypt / decrypt a document / header. In addition, other protective measures may be incorporated into the DSM711. Other protective measures include, for example, a filter that prevents copying the contents of a protected document to a non-protected document, and a link from the protected document / original source to another document or recipient source.

【0145】

About Offline Access Manager 714 This module is enabled when a networked client device is out of the network, i.e. when the local or central server is unavailable. For example, when a user is on a business trip, they need to access certain protected documents on their laptop computer. If live consultation is not available, Offline Access Manager 714 will be activated and authorized users will still have access to protected documents, but with limited time and possibly limited privileges. Guarantee.

【0146】

The client module 702 of FIG. 7A is a list of exemplary submodules according to an embodiment of the present invention, and in order to carry out the present invention, it is not always necessary to incorporate all the modules in the server module 702. It should be noted that it may be. As will be apparent to those skilled in the art from the description herein, various combinations of submodules will achieve certain functions, benefits and effects considered in the present invention.

【0147】

Many aspects of the operation of client module 702 have already been described. Client module 702 provides offline access capabilities to allow users to work with protected documents that are remote to the server (ie, the central or local server). Dependencies on the server (either the central server or the local server) are minimized so that the functionality applies equally to mobile users. With reference to FIG. 7B, a flowchart of the offline access providing process 720 according to the embodiment of the present invention is shown.

【0148】

If the user decides to leave the computer environment for a period of time and needs to access certain protected documents on the client device (eg, laptop computer) that he intends to carry, the user is networked. Pre-authenticate from the server before disconnecting the client device from. In step 722, a pre-authentication request is made on the client device to request approval of the offline access request from the server (eg, central server or local server). Depending on the strict embodiment, the response to the pre-request received from the server is a dialog box in which the server requests more information from the user to proceed with the offline access request.

【0149】

At step 724, the user enters the required information into an offline access request that includes the user's identification information for a specific time period. Perhaps the offline access request includes a protected document that is accessed offline, or the name of a protected directory / folder that contains the protected document. Generally, a specific time is manually entered or selected, but the user's identification information is automatically entered. This is because the user is typically pre-authenticated and the client device obtains the user's identification information. The offline access request is then forwarded to the server, which processes the offline access request. It is assumed that the user is allowed to receive such offline access privileges.

【0150】

There are many possible ways to allow offline access functionality during operation. One method is to include time-limited access modifications in the desired protection document. For example, a user is pre-authenticated by allowing a newly generated short-term user key pair, or by uploading the user's key to a client device in an unbreakable format (only for protected documents). You only need the private key to access it, and you need both keys to protect the newly created document.) In other words, the user's access privileges, or access rules in the selected protected document, are updated over the requested time period. Therefore, depending on the implementation, a modified access rule, modified access privilege, or time-limited user key is received from server 726 in step 726.

【0151】

In step 728, the original access rule, or the user's original access privilege, or the original user key is modified, updated, or temporarily overwritten. When the modified access rule is received, the protected document is processed to incorporate the amendment into the access rule, and as a result, the user can access this protected document later, even when offline. it can. When the modified access privilege is received, the user's original access privilege is temporarily revised with the received modification, allowing the user to access the protected document offline. When a time-limited user key is received, the user's original key is retained (for example, converted to an undecipherable format and cannot be easily used), and the newly received key is only for the offline access period. Be enabled. In Figure 7C, access rule amendments are placed in a protected document accessible by users A, B, C and D, user A requests offline access, the request is granted offline access, and user B , C and D have been shown to have no offline access to their protected documents.

【0152】

For security reasons, the amendment typically expires at the end of a particular offline time, regardless of whether the user has returned or not. This feature is important in situations where the client device (eg, a laptop computer) is away from the user or is owned by an unauthorized person. This is because the protected document in the client device cannot be accessed with the expired user key, even if the user's credentials (username / password) are stolen. Therefore, in step 730, process 720 continues to check if the offline time has expired. If the offline time has not expired, the user can still access the protected document offline. When the expiration of the offline time is detected, process 720 proceeds to step 734, the original access rules are restored, and the protected document becomes inaccessible offline.

【0153】

Similarly, the modified access privilege of the user is set to expire when the end of offline time is detected, and process 720 proceeds to step 734 to restore the user's original access privilege, thus protecting it. The document becomes inaccessible offline. According to one embodiment, the modified access privilege is overwritten by the original access privilege.

【0154】

Processing 720 may be configured to initiate the restoration of the original settings for the protected document or the user's access privileges to account for situations in which the user has shortened his or her travels. In step 732, consider the case where the client device establishes a connection to the access control server, which eliminates the need for offline access anymore. Process 720 proceeds to step 734 to restore the original settings, user access privileges, or user key for the protected document. As a result, the protected document becomes inaccessible offline from the client device.

【0155】

In either case, preferably, the access reporting module 704 of the client module 702 is called to record the access behavior by the user during the offline access period. Next, when the user connects to the server, the access behavior of the protected document is reported to the server, and access control management or synchronization of the protected document accessed during the offline period is easily realized.

【0156】

The present invention has a number of functions, benefits and effects. One of the functions, benefits and effects is that the protection mechanism considered in the present invention always keeps the selected digital asset in a protected state by utilizing the access rules of the protected digital asset. Is. In this way, only authenticated devices and authorized users can access the protected digital assets. Other functions, benefits and effects will be apparent to those skilled in the art by reference to the detailed description.

【0157】

The present invention can be realized as methods, systems, computer-readable media, programs, computer products, and other forms that implement the desired embodiments. As will be apparent to those skilled in the art, the above description will be similarly applied to or used in a wide variety of other settings with respect to the various combinations, examples, or settings described.

【0158】

The processes, sequences or steps, and functions described above are interrelated and each is considered to be uniquely novel. The disclosed processes, sequences or steps, and functions can be performed independently or in combination to provide a novel and non-trivial system or part of a system. Is. By combining a process, sequence or step, and function, even in the broadest sense, i.e., each of the process, sequence or step, and function is reduced to a particular embodiment for implementation. It should be noted that even if it is less than the above, equally independent and novel combinations can be obtained at the same time.

【0159】

The description of the above examples is merely an example of various aspects / examples of the present invention. Various changes relating to the present invention will be made by those skilled in the art without departing from the true spirit and scope of the invention described in the claims. Therefore, the scope of the present invention is defined not by the above description of the examples but by the matters described in the claims.

[Simple explanation of drawings]

[Fig. 1A]

It is a block diagram of the basic system by one preferable Example of this invention.

[Fig. 1B]

It is a block diagram of the system which used the central server and the local server.

[Fig. 1C]

It is a block diagram of a system suitable for a small group of users who do not use a local server.

[Fig. 1D]

FIG. 5 is an internal block diagram of a computer device (eg, a client device, a central server, and a local server) into which the present invention is introduced and executed.

[Fig. 2A]

It is explanatory drawing of the protection process of the created document.

[Fig. 2B]

It is explanatory drawing of an example of the structure of the protection document including a header and an encrypted data part.

[Fig. 2C.1]

It is explanatory drawing of another example of the structure of the protection document which stores a large amount of user information in a header and a cipher part.

[Fig. 2C.2]

It is explanatory drawing of still another example of the structure of the protection document which accommodates a security block in a header and a cipher part.

[Fig. 2C.3]

FIG. 2 is an explanatory diagram of an example of a header in a markup language corresponding to the structure of the protected document shown in C.2.

[Fig. 2D]

FIG. 5 is an explanatory diagram of an example of a graphical user interface (GUI) used by a user to set or create access rules.

[Fig. 2E]

It is an explanatory diagram of the directory structure including the clear folder and the protected (in use) folder. The clear folder is generally a folder for storing system files or files that are not planned to be protected, and the protected folder is in a protected format. A folder for data files and documents.

[Fig. 3]

FIG. 5 is an explanatory diagram of an embodiment of a method in which a document protection module that interacts with an operating system (eg, WINDOWS® 2000) and operates internally hides a protected document from the user.

[Fig. 4A]

It is a flowchart of the process which protects the document under preparation by one Example of this invention.

[Fig. 4B]

It is a flowchart of an example of the process of acquiring an access rule incorporated in the process of FIG. 4A in order to easily realize the document protection process.

[Fig. 4C]

It is a flowchart of the process of accessing a protected document by one Example.

[Fig. 5A]

It is a functional block diagram of a server device (access control) in which a server module exists in a memory space and is executed by one or more processors.

[Fig. 5B.1]

It is explanatory drawing of an example of access privilege to a user.

[Fig. 5B.2]

It is explanatory drawing of the content of the user key manager by one Embodiment of this invention.

[Fig. 5B.3]

It is a flowchart of a user key update process.

[Fig. 5B.4]

It is a flowchart of the server support process of protection document access by one Example.

[Fig. 5B.5]

It is a flowchart of the server support process of document protection by one Example.

[Fig. 5C]

It is a functional block diagram of a local server device that is similar in many respects to the server shown in Figure 5A.

[Fig. 5D]

It is explanatory drawing of the table of all the users with various access privileges managed by a central server.

[Fig. 5E]

The user only needs to contact the corresponding local server and is accessed by the local server so that it is not affected if another local server is down or disconnected from the central server for any reason. It is explanatory drawing of each table.

[Fig. 5F]

Rather than having three identical cache modules so that John can access them from anywhere in three locations, only one cache module is configured so that John can access only one of the three locations at a time. It is explanatory drawing of the accessibility for each user.

[Fig. 5G]

It is explanatory drawing of the access control management for dynamic cache by adding John to another cache module which can function for John who moved from another place.

[Fig. 5H]

It is explanatory drawing of the accessibility of the user which changes as a result of access control management for dynamic cache.

[Fig. 5I]

It is explanatory drawing of the accessibility of the user which changes as a result of access control management for dynamic cache.

[Fig. 6A]

It is a flowchart of a user authentication process embedded in a central server or a local server.

[Fig. 6B]

It is a flowchart of the dynamic configuration of the access control management process embedded in one or more local servers together with the central server.

[Fig. 6C]

It is a flowchart of the reconstruction of the local module processing by one Example used in FIG. 6B.

[Fig. 7A]

It is a functional block diagram of the client apparatus used for carrying out this invention.

[Fig. 7B]

It is a flowchart of offline access processing by one Example of this invention.

[Fig. 7C]

It is an explanatory diagram of the modification of the access rule contained in the protected document accessible by users A, B, C and D, in which user A requests offline access and is granted the request, and users B, C and D You cannot access protected documents offline.

[Explanation of symbols]

701 processor 702 client module 703 memory 704 Access Report 705 network interface 706 repository 707 local storage 708 Key Manager 710 User matching 711 Document protection module 712 cipher 714 offline access