REGISTER  |  SIGN IN
United States Patent Application20020178271
Kind CodeA1
Graham, Todd D. ; et al.November 28, 2002
Dynamic file access control and management
Abstract
A dynamic file access control and management system and method in accordance with the present invention may be a proxy file management system that includes one or more file system proxy servers that provide selective access and usage management to files available from one or more file systems or sources. The present invention may embody a secure transport protocol that tunnels distributed file systems, application independent usage controls connected to files on end-user computers, dynamically merging secondary content to a requested file, and applying bandwidth management to any of the foregoing. Embodied in the various implementations of the present invention is enhanced file security. Preferably, the proxy file management system is transparent to an end-user. A dynamic content management system may also be included that selectively adds content to requested files.
Inventors:Graham; Todd D. (Ann Arbor, MI), Hudson; Jonathan C.  (Grosse Pointe Farms, MI)
Correspondence Name and Address:McDermott, Will & Emery 28 State Street
David M. Mello
Boston
MA
02109
US
Series Code:989479
Filed:November 20, 2001
U.S. Current Class:709/229; 705/57; 705/59
U.S. Class at Publication:709/229; 705/57; 705/59
Intern'l Class:G06F 015/16; G06F 017/60
Claims

What is claimed is:
1. A dynamic file access control and management system configured to access one or more content sources including a set of files, said system comprising: A. a proxy system linked to said one or more content sources, said proxy system comprising an access control module configured to selectively obtain a file from said content sources as a function of an authorization of a user requesting said file and a set of access policies; B. a rights management module configured to generate a set of usage rights associated with said file as a function of a set of predefined usage policies associated with said file for said user; C. at least one client device having a client module configured to interface to a client operating system, said client module configured to selectively inhibit operating system functions with respect to said file as a function of said usage rights; and D. one or more communication means, via which said file and said usage rights are provided to said client device.

2. The system according to claim 1, wherein said file and said usage rights are provided to said client device via different communication means.

3. The system according to claim 1, wherein said files are static files.

4. The system according to claim 1, wherein said files are dynamic files.

5. The system according to claim 1, wherein said communication means includes a secure transform configured to encrypt and encapsulate said file as a function of a session ID into a message and said client is configured to extract said file from said message.

6. The system according to claim 1, wherein said proxy system further includes a user interface, configured to facilitate creation and editing of said access policies and said usage policies and association of said access policies and said usage policies with said files.

7. The system as in claim 1, where said client device is a device from a group comprising: 1) a personal computer; 2) a workstation; 3) a personal digital assistant; 4) an e-mail device; 5) a cellular telephone; 6) a Web enabled appliance; and 7) a server.

8. The system of claim 1, wherein said proxy system and at least one of said content sources are hosted on the same computing device.

9. A method of dynamic file access control and management comprising: A. accessing a file available from a set of content sources, as a function of an authorization of a user requesting said file and a set of access policies corresponding to said user and said file; B. generating a set of usage rights associated with said file as a function of a set of usage policies associated with said file for said user; C. communicating said file and said usage rights to said a client device of said user, said client device having a client module configured to interface to a client operating system; D. using said client module, selectively inhibiting operating system functions with respect to said file as a function of said usage rights.
Description


CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application is a continuation-in-part of commonly owned U.S. patent application Ser. No. 09/717,474, filed Nov. 20, 2000, entitled METHOD AND APPARATUS FOR THE REAL TIME MODIFICATION AND INTERPRETATION OF COMPUTER FILES, AND REAL TIME BANDWIDTH MANAGEMENT.

FIELD OF THE INVENTION

[0002] The present invention generally relates to computers and computer systems configured to access files or file storage or management systems.

BACKGROUND OF THE INVENTION

[0003] The Internet was originally conceived as a distribution network, and in the past six years, has become widely available to businesses and consumers. The more recent availability of inexpensive broadband access has ushered in a new wave of data sharing. This data sharing has created significant issues that arise due to the digital nature of Internet data--the ones and zeros that represent text, music and video on the Internet are much easier to access and modify than their physical counterparts. Two problems this causes are that privacy can be compromised, and content can be illegally duplicated (or "pirated").

[0004] Prior art has attempted to eliminate privacy and piracy issues, with limited success. The most basic means by which to protect data has been encryption--the sender modifies data in such a way that it is unintelligible to all but the intended recipient. This has meant reliance on relatively slow algorithms for processing the data to be encrypted and unencrypted. Recent prior art has dramatically reduced the computing power required to encrypt data. However, while encryption is necessary to maintain data security, it is useless if the data's security can be compromised once it has been unencrypted.

[0005] Other prior art has been developed to augment the security offered by encryption systems. Digital Rights Management (DRM) systems use various forms of encryption to allow rights holders, such as content owners, a way to persistently protect data. Prior art DRM systems offer unique means of deployment--for example, a DRM system can modify a file so that it can only be accessed once without an encrypted key. If an individual attempts to access the file again, the DRM system will disallow access until the individual has the correct key. This is just one example of how DRM can be deployed. Although prior art DRM solutions have been commercially available for some time, they have received limited acceptance because of the usability barriers they introduce. From a content-owner's perspective, these systems call for the time-consuming and costly process of modifying all of his or her data to comply with the system's rules. The content-owner faces this process every time he or she wishes to add more data to be protected. Consumers face even greater barriers--because of the rules introduced by DRM systems, a user may have to change his or her usage habits. For example, an MP3 listener may be required to switch his or her preferred playback program.

[0006] The deployment issues facing those using the Internet to share information are not exclusively inherent in Digital Rights Management systems. Companies may want to modify data in any number of ways attaching liner notes to digital music, linking a patient's record to a medical database, including version information on a book passed between an author and his editor--these are all examples of processes that add extra time and cost to file delivery on the back-end, and compatibility issues on the front end. As more entities connect more devices to the Internet at higher data transmission rates, cost and compatibility problems will only increase. The benefits gained from increased Internet connectivity will ultimately offset the losses. However, the increase in data flowing across both wired and wireless networks introduce further issues regarding speed, prioritization, and Quality of Service (QoS).

[0007] More now in wireless networks than in their wired counterparts, bandwidth is a precious commodity. Prior art has developed systems such as, but not limited to, Wideband Code Division Multiple Access and Global Packet Radio Service, that will fill wireless radio frequencies with circuit-switched and packet data in the most optimal way possible for the given spectrum. However, the bandwidth that will be available in Third Generation cellular networks will still not match that in wired networks. Additionally, applications developers face the challenge of not knowing the available bandwidth of their end-users, as it changes based on location, speed and several other variables. Both the wired and wireless world will face increased traffic and network congestion, as more applications are developed to push the limits of available bandwidth.

[0008] Beyond Internet applications, many enterprises also face issues with securing files available on or via their enterprise network. As a result, most enterprises ) today have deployed sophisticated network security products to protect their information from external threats. Technologies such as firewalls, intrusion detection and user authentication have gained an almost universal acceptance in the marketplace. At the same time, enterprises are also adopting a strong centralized file storage strategies that are built upon network storage devices.

[0009] While prior art perimeter and access technologies like firewalls and user authentication do an excellent job of keeping malicious users out of networks, they do little to address other threats. Another threat exists within users who have authorized access to the network. Through network storage devices, authorized users have direct access to sensitive enterprise information.

[0010] Even with the majority of enterprise information currently being stored on network storage devices, security has not been a driving force in their design. As a result, these devices have largely implemented simple and inadequate permissions such as read-only and read/write. This simplistic approach has lead to accidental and malicious exposure of enterprise sensitive data to unauthorized parties.

SUMMARY OF THE INVENTION

[0011] A dynamic file access control and management system and method in accordance with the present invention may be a proxy file management system that includes one or more file system proxy servers that provide selective access and usage management to files available from one or more file systems or sources. The present invention may embody a secure transport protocol that tunnels distributed file systems, application-independent usage controls connected to files on end-user computers, dynamically merging secondary content to a requested file, and applying bandwidth management to any of the foregoing. Embodied in the various implementations of the present invention is enhanced file security. Preferably, the proxy file management system is transparent to an end-user.

[0012] A proxy file management system in accordance with the present invention extends accepted network storage systems with a security infrastructure appropriate for large and rapidly changing network environments. The present invention includes an end-to-end approach to network file security, a robust and scaleable centralized proxy server, client policy enforcement services, and a secure protocol to manage network transmission. These services allow enterprise data to be easily managed and protected through the enforcement of a comprehensive and coherent file protection policy.

[0013] A proxy file management system in accordance with the present invention is preferably configured to achieve the following goals:

[0014] a. End-to-End Solution--The proxy file management system is a solution that is easily dropped into a network, offering total file sharing security on both an access and usage level, and on a transport level. Enterprises that deploy the proxy file management system never have to worry about also deploying a third-party package to gain full functionality and security.

[0015] b. Security--The security with which content is managed and distributed is of paramount importance to the proxy file management system. This includes the security of the interfaces and protocols of the client and server, as well as the deterministic and correct enforcement of policy.

[0016] c. Stability--Successfully usage of the proxy file management system in any environment is largely reliant on its ability to consistently and seamlessly deliver content to authorized users.

[0017] d. Flexibility--The proxy file management system includes the ability to flexibly represent the content management needs of the enterprise through policy. Thus, flexible and straightforward interfaces to content management systems is provided.

[0018] e. Compatibility--Administrators do not wish to introduce new services into their networks. For this reason, it is important to provide an infrastructure that can be integrated into their network with minimal cost. Therefore, the software modules of the proxy file management system are not only compatible with existing infrastructure (e.g., authentication services), but also implement accepted models (e.g., file system semantics).

[0019] f. Low Maintenance--The proxy file management system software operates with as little user or administrator involvement as possible.

[0020] The proxy file management system is an end-to-end client-server solution to protect information on a content source (e.g., a network storage device or system) from unauthorized access and usage. A proxy system (including a set of proxy servers) is disposed between one or more client devices and at least one content source. The proxy system offers a high level of flexibility in file access policy, wherein the policy can be evaluated at runtime, based on real-time environmental variables such as network status or time of day. The client (or end-user) device includes a client module (or program) that functions with the client device operating system (OS) to deliver application independent file usage controls and auditing. User authentication is performed by an authentication system and policy management is accomplished by a policy system.

[0021] The proxy system acts as a file server that mimics the structure and presentation of the content source, for which the proxy system is acting as a proxy. When a file is requested by an end-user of client device the proxy system appears (to the end-user) as a file server. To transfer the file from the content source, the proxy system appears to be a network file sharing client (to the content source). These representations occur simultaneously. When an end-user client device requests a file from the network file storage device, the request is received by the proxy system, which selectively provides the requested file as a function of information the proxy system obtains from authentication system and policy system.

[0022] Prior to requesting a file, the user preferably authenticates with authentication system. After authentication, when an end-user requests a file, the proxy system obtains verification of the authentication of the user from the authentication system and in cooperation with the policy system, the proxy system determines if the requesting user has the right to access the file. If access to the file is granted, the proxy system provides the file, in a secure and encrypted manner, with additional information (e.g., usage rights and encryption/decryption keys) to the end-user client device.

[0023] Communication between the client device and proxy system are treated according to a secure protocol configured to enable the secure transport of files and file related information across a network. The network may include any of a variety of types of networks, such as a local area network (LAN), wide area network (WAN), virtual private network (VPN), World Wide Web ("Web"), Internet, extranet, intranet, telephone network (including cellular telephone network), or some combination thereof. Any of the foregoing networks may include a variety of wired or wireless communication means. The files sought to be accessed may be any type of computer files, including any type of typical desktop application files, Web or Internet files, e-commerce files, music, audio, or video files, and so on. Such files may be provided by any of a variety of static or dynamic sources or devices, collectively represented as a content source.

[0024] In addition to, or as an alternative to, the proxy file management system, a dynamic file access and control and management system in accordance with the present invention may include a dynamic content management system (DCMS), which enables the real time modification and enhancement of computer files as they traverse a server over a network, such as the Internet. For example, the DCMS may be utilized to secure an MP3, attach tracking information to a patient's medical file, or ensure the privacy of an email between an attorney and his or her client. The DCMS also delineates protocols for the attachment of additional data relevant to the file being modified. The DCMS additionally provides a protocol for real-time bandwidth moderation and allocation through a client-server communication.

[0025] The DCMS modifies the operating system of a computer to detect and "hook" different types of files based on their header information, physical and binary structure, and other information, and determines which modifications, if any, to make on the file.

[0026] If modifications are necessary, the DCMS determines how to make them, and the information source or sources from which to draw supplemental information. This process occurs in the present invention in "real-time," so that data moving across the computer on which the DCMS resides is subject to little-to-no processing delay. The DCMS provides provisions for modifying the header information of a computer file, as well as appending additional information throughout the file. The DCMS additionally allows files to be "wrapped" (protected) with encryption and Digital Rights Management (DRM) packaging, or usage rights.

[0027] The DCMS allows a file to be "embedded" with information relevant to the file's destination. For example, a virtual "mall" may be embedded in an artist's song so that end-users can purchase tickets for that artist's upcoming concert.

[0028] The DCMS makes a modification to client devices which allows them to interpret files modified by the DCMS. This client-side modification changes system-level code to "hook" files that are opened on these devices. The hook then detects whether modifications made by the DCMS are present, and if so, goes through the steps necessary to interpret these modifications.

[0029] In any of the embodiments of the present invention, a protocol for dynamically allocating bandwidth may be included. It initiates communication between a server and a client, both which have software components of the present invention installed. By determining the data requirements of the end-user, and the capacity of the carrier, the present invention will dynamically allocate the maximum amount of bandwidth required to suite the constraints of both. Through the same protocol, the present invention can also, in real-time, set a different data delivery priority than the one currently used. For example, an individual attempting to download an e-book to a portable device using General Packet Radio Service (GPRS) may have his delivery delayed if all of the Circuit-switched data (CSD) in the available spectrum is being used for voice calls.

[0030] A system in accordance with the present invention includes a standard computer server across which data moves, a modification to the operating system of the server, a software application to interact with and control the server, and a modification to the operating system of a client device.

[0031] A system in accordance with the present invention consists of server software running as an application on a standard hardware configuration and client software either hooking into or running as a process on top of the operating system on a standard hardware configuration.

BRIEF DESCRIPTION OF THE DRAWINGS

[0032] The foregoing and other objects of this invention, the various features thereof, as well as the invention itself, may be more fully understood from the following description, when read together with the accompanying drawings, described:

[0033] FIG. 1 is top level block diagram of a proxy file management system in accordance with the present invention;

[0034] FIG. 2 is a block diagram of software architecture that may be implemented by the proxy file management system of FIG. 1;

[0035] FIG. 3 is a block diagram of the proxy server-side subsystem of FIG. 2;

[0036] FIG. 4 is a block diagram of the client-side software of FIG. 2;

[0037] FIG. 5 is a diagram of database relationships of the proxy file management system of FIG. 1;

[0038] FIG. 6A and FIG. 6B are diagrams of a content transform and its fields contents, in accordance with the present invention;

[0039] FIG. 7 FIG. 8, FIG. 9 and FIG. 10 are diagrams of file key payload formats and block formats in accordance of the present invention; FIG. 11
illustrates a flow of data in a conventional client-server environment;

[0040] FIG. 12 illustrates a flow of data in a client-server environment in accordance with the invention;

[0041] FIG. 13 is a system-level diagram showing the objects of the DCMS Server in accordance with an embodiment of the invention;

[0042] FIG. 14 is a diagram of an overall architecture of the system of the invention, in accordance with an embodiment of the invention;

[0043] FIG. 15 shows the steps in which information stored in the DCMS server database is converted to header information, in accordance with an aspect of the invention;

[0044] FIG. 16 is a block diagram of the DCMS server core plug-in architecture, in accordance with an embodiment of the invention;

[0045] FIG. 17 is an interaction diagram that illustrates the scenario when a file server attempts to read a static DCMS virtual file, in accordance with an aspect of the invention;

[0046] FIG. 18 shows the use of client-side plug-ins that are used to read DCMS-enhanced file, in accordance with an aspect of the invention;

[0047] FIG. 19 shows various embedded elements that are provided to a user along with a requested file, by way of the LiveEmbed.TM. component, in accordance with an aspect of the invention;

[0048] FIG. 20 shows data obtained from two packets using the variable data pipeline component, in accordance with an aspect of the invention;

[0049] FIG. 21 shows the packet and header structure of a DCMS file, in accordance with an aspect of the invention;

[0050] FIG. 22 shows the flow of information among a client, a DCMS Server and a Content Server, in accordance with the invention;

[0051] FIG. 23 shows one example of a table that holds data utilized by the DCMS Server to access information from Content Servers, in accordance with the invention;

[0052] FIG. 24 shows various components of the DCMS server that are used to wrap a file; and

[0053] FIG. 25 shows the DCMS client application stored in a host operating system's memory partition of a client computer, in accordance with an aspect of the invention.

[0054] For the most part, and as will be apparent when referring to the figures, when an item is used unchanged in more than one figure, it is identified by the same alphanumeric reference indicator in all figures.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

[0055] A dynamic file access control and management system and method in accordance with the present invention may be a proxy file management system that includes one or more file system proxy servers that provide selective access and usage management to files available from one or more file systems or content sources. The present invention may embody a secure transport protocol that tunnels distributed file systems, application independent usage controls connected to files on end-user computers, dynamically merging secondary content to a requested file, and applying bandwidth management to any of the foregoing. Embodied in the various implementations of the present invention is enhanced file security. Preferably, the proxy file management system is transparent to an end-user.

[0056] 1. System Overview

[0057] A proxy file management system in accordance with the present invention extends accepted network storage systems (and other content sources) with a security infrastructure appropriate for large and rapidly changing enterprise environments. The preferred embodiment of the present invention includes an end-to-end approach to network file security, a robust and scaleable centralized proxy server, client policy enforcement services, and a secure protocol to manage network transmission. These services allow enterprise data to be easily managed and protected through the enforcement of a comprehensive and coherent file protection policy. A proxy file management system in accordance with the present invention is preferably configured to achieve the following goals:

[0058] a. End-to-End Solution--The proxy file management system is a solution that is easily dropped into a network, offering total file sharing security on both an access and usage level, and on a transport level. Enterprises that deploy the proxy file management system never have to worry about also deploying a third-party package to gain full functionality and security.

[0059] b. Security--The security with which content is managed and distributed is of paramount importance to the proxy file management system. This includes the security of the interfaces and protocols of the client and server, as well as the deterministic and correct enforcement of policy.

[0060] c. Stability--Successfully usage of the proxy file management system in any environment is largely reliant on its ability to consistently and seamlessly deliver content to authorized users.

[0061] d. Flexibility--The proxy file management system includes the ability to flexibly represent the content management needs of the enterprise through policy. Thus, flexible and straightforward interfaces to content management systems is provided.

[0062] e. Compatibility--Administrators do not wish to introduce new services into their networks. For this reason, it is important to provide an infrastructure that can be integrated into their network with minimal cost. Therefore, the software modules of the proxy file management system are not only compatible with existing infrastructure (e.g., authentication services), but also implement accepted models (e.g., file system semantics).

[0063] f. Low Maintenance--The proxy file management system software operates with as little user or administrator involvement as possible.

[0064] FIG. 1 shows the preferred embodiment of a proxy file management system 100 in accordance with the present invention, which is an end-to-end client-server solution to protect information on a content source 160 (e.g., network storage device) from unauthorized access and usage. In this embodiment, a proxy system 110 (including a set of proxy servers) is disposed between one or more client devices 150 and at least one content source 160. The proxy system 110 offers a high level of flexibility in file access policy, wherein the policy is evaluated at runtime based on real-time variables. The client (or end-user) device 150
includes a client module (or program) that functions with the client device 150 operating system (OS) to deliver application independent file usage controls and auditing. In the embodiment of FIG. 1, user authentication is performed by an authentication system 130 and policy management is accomplished by a policy system 120.

[0065] In the preferred form, the proxy system 110 acts as a file server that mimics the structure and presentation of the content source 160, for which the proxy system 110 is acting as a proxy. When a file is requested by an end-user of client device 150 the proxy system 110 appears (to the end-user) as a file server. To transfer the file from the content source 160, the proxy system 110 appears to be a network file sharing client (to the content source 160). These representations occur simultaneously. When an end-user client device 150 requests a file from the content source 160, the request is received by the proxy system 110, which selectively provides the requested file as a function of information the proxy system obtains from authentication system 130 and policy system 120.

[0066] Prior to requesting a file, the user preferably authenticates with authentication system 130. After authentication, when an end-user requests a file, the proxy system 110 obtains verification of the authentication of the user from the authentication system 130 and in cooperation with the policy system 120, the proxy system 110 determines if the requesting user has the right to access the file. If access to the file is granted, the proxy system 110 provides the file, in a secure and encrypted manner, with additional information (e.g., usage rights and encryption/decryption keys) to the end-user client device 150.

[0067] Communication between the client device 150 and proxy system 110
are treated according to a secure protocol configured to enable the secure transport of files and file related information across a network 140. In the preferred form, network 140 may include any of a variety of types of networks, such as a local area network (LAN), wide area network (WAN), virtual private network (VPN), World Wide Web ("Web"), Internet, extranet, intranet, telephone network (including cellular telephone network), or some combination thereof. Any of the foregoing networks may include a variety of wired or wireless communication means. The files sought to be accessed may be any type of computer files, including any type of typical desktop application files, Web or Internet files, e-commerce files, music, audio, or video files, and so on. Such files may be provided by any of a variety of static or dynamic sources or devices, collectively represented as v 160 (and file repository 210, see FIG. 2).

[0068] 2. Proxy System 110

[0069] A proxy system 110 in accordance with the present invention includes a set of servers running server-side proxy file management functionality that applies flexible authorization and access control policies over managed content, such as files stored in a content source 160. The server-side proxy file management functionality may take the form of a content subsystem or program, described in more detail with respect to FIG. 2 and FIG. 3. Unlike current security services, policies in accordance with the present invention not only allow administrators to map users to allowable access, but to base access on run-time environmental conditions. Users can be flexibly organized within the system, wherein the policies associated with a user may vary from file to file. The policy infrastructure interfaces with widely deployed network services, so provides for easy integration into existing networked file systems.

[0070] The proxy system 110 acts as a secure proxy device or server to current content sources 160 (e.g., distributed file systems (DFS)). The proxy system 110 interfaces with and maintains authentication, access and usage control and security across computer network utilization of content sources 160. The proxy system 110 is preferably logically oriented between content source 160 and clients 150, or in such a way that direct access from the proxy server 110 to the content source is accomplished, preferably without direct access to content source 160 by client 150. The content source 160 being "proxied" may also be contained within the same physical space as the proxy subsystem software; in such a case the proxy process may be integrated with another operating system.

[0071] As mentioned, the proxy system 110 comprises is a suite of server-side software modules (e.g., the content subsystem 220 of FIG. 2) executing on one or more proxy servers, i.e., one or more computers other than the client device or system 150. The proxy system may be configured for any known for of operating system (e.g., the Berkeley Software Distribution (BSD) family of operating systems, Microsoft Windows.TM. and Sun Solaris.TM.). Preferably, the suite of server-side software modules is hardware independent.

[0072] Preferably, the proxy server suite of server-side software modules uses many of the standard functionality of commercial operating systems to accomplish its normal operations. These standard functions include hardware interfacing and standard data input/output. Certain functionality can be optimized to serve specific, specialized purposes. These modifications can include specialized networking functionality (e.g., based on the BSD sockets), customized process and thread libraries, and optimized device drivers for networking.

[0073] 3. Client 150

[0074] A client 150 includes a client device and a client module. A client devices in accordance with the present invention may be any of a variety of types of devices, including personal computer, workstation, server, personal digital assistant (PDA), telephone (including, cellular telephone), pagers, Web enabled appliances, or other network enabled devices. The client module 230 (see FIG. 2) acts on behalf of the user in obtaining credentials and managing security-related material from proxy system 110. This information is used over the course of a session to gain access protected content from content source 160, and to protect the content from exposure to adversaries on the network. In addition to protecting data from unauthorized users, the client module hosted on client 150 enforces use policies. Use policies limit the kinds of Is operations allowed on protected content. For example, a particular user may not be permitted to print an accessed file. Use policies are communicated to the client 150 at access time, and enforced over the lifetime of the user's session.

[0075] 4. Authentication System 130

[0076] The authentication system 130 integrates with currently existing and implemented third-party authentication services (or servers). These include, but are not limited to, solutions from Entrust, Microsoft, Intel, RSA, Novell, and Computer Associates. Integration with these third-party solutions is managed through a plug-in layer within the authentication system 130. This allows for the easy and rapid integration of current and future authentication mechanisms. These authentication services can be executed in application form (or process/thread form) on the same physical computer system as the proxy system 1 10, or a remote system. In the case of remote system communications, information is transmitted over a computer network utilizing, in the preferred embodiment, either UDP or TCP. Security protocols such as Diffie-Hellmen and Secure Socket Layer (SSL) are also supported to facilitate the secure transfer of sensitive information such as shared session secrets.

[0077] In situations where there is not a third-party authentication service deployed, the proxy system's authentication subsystem can be implemented to provide the required authentication. The preferred embodiment of the proxy system's 110 authentication subsystem understands the potential directions that future authentication systems might take. As such, the proxy system's 110 authentication subsystem (discussed with respect to FIG. 3) is able to work with a variety of additional authentication methods such as bio-metric and smart-card based solutions that may not explicitly use a client-server architecture.

[0078] 5. Content Source 160

[0079] The proxy system 110 utilizes a database or content source 160 for the storage of a variety of different forms of information (or files). This information includes policy, rule and user-related information, as well as auditing information. In the preferred embodiment, the storage system is a SQL-compliant database, such as PostgresSQL or Oracle. The contents of the content source 160, including the database, is protected so that it is only accessible to a subset of the proxy system 110
components that have been explicitly granted permission to access and manipulate the database. In the preferred embodiment, a username and a password are used to limit the access of the database to the authorized proxy system 110 components. In deployment-specific situations, the contents of the entire network content source 160 can be encrypted to further increase security. The content in the content source 160 is username and password protected to prevent unauthorized access to, or manipulation of, information within the database. In deployment-specific situations, the contents of the entire content source 160 can be encrypted to increase security.

[0080] The content source 160 includes a database application and the actual content (or database files). The database application and files can be executed and/or stored in a number of different locations. In the preferred embodiment, the database application is executed on the same physical device as the proxy system 110 and the database file is stored on the content source 160 for which the proxy is provided. Additional embodiments include, but are not limited to, database application and files stored on remote servers or the database file stored on the servers of the proxy system 110. In case of access to the database over a network, the communication between the authorized components of the proxy system 110 and the content source 160 is secured using commonly available solutions, such as SSL.

[0081] 6. Architecture

[0082] FIG. 2 shows an embodiment of a software architecture 200 that may be included in a proxy file management system, in accordance with the present invention. Within architecture 200 there exists a number of subsystems that work in concert to accomplish the goals of the preferred embodiment. Software architecture 200 in the preferred form is comprised of three distinct entities: a content repository 210, a content subsystem 220, and a client module 230. As is shown, content repository 210 is hosted on content source 160. Proxy system 110 hosts a content subsystem 220 and client device 150 hosts client module 230, which interact across any of a number of networks 140, as previously discussed.

[0083] Content repository 210 acts as a persistent store for protected content (e.g., content in content source 160). The content source 160 may be comprised of commercial-off-the-shelf (COTS) storage devices, and all communication with storage uses standardized interfaces (e.g., Network File System (NFS)). The content repository 210 is directly accessible only by content module 220 of proxy system 110.

[0084] A. Content Subsystem 220

[0085] The content subsystem 220 regulates access to files in the content repository 210 through the evaluation and enforcement of authentication and access control policies. The content module 220 executes on one or more dedicated hosts (e.g., servers), which together form the proxy system 110 of FIG. 1. The content module 220 can be characterized as providing or including the following services:

[0086] 1) Content Services 222--Access to protected content is governed by content services. These services enforce authorization and access control policies defined by system administrators and security personnel.

[0087] 2) Account Services 224--Based on provided credentials, account services 224 authorize each client requesting access to content. The assignment and distribution of perishable credentials (used later as proof of access rights) is managed by this service.

[0088] 3) Content Management Services 226--The definition of what and how content is protected is defined by system administrators and security personnel through the s content management services 226. Content management services provide interfaces for the definition, modification, and auditing of these configurations.

Content Service 222

[0089] The content subsystem 220 must be able to "speak" the computer protocols of the other devices and systems with which it interfaces, and to which it acts as a proxy, since the proxy system 110 is designed for use as a proxy to content source 160. In the case of content source 160, these protocols currently include, as examples, the NFS and Common Internet File System (CIFS). The files may be statically stored, dynamically created, files provided by a third party source, files containing real-time (or near-real time) information, or some combination thereof. The invention also contemplates, and is intended to operate with, other current and future file system derivatives and developments. The content subsystem 220 also contemplates future additions through a generic interface architecture.

[0090] The content subsystem 220 is responsible for all connection and state management. This is accomplished through a system of thread and socket pools that are designed to minimize the need for "on-the-file" resource allocation. State is maintained based upon the needs of the individual protocols and users being serviced. Connection recovery, keep-alive status, and error/flow control is also part of this management. Additionally, since the proxy file management system supports both read and write file operations (at a very basic level), file locking and write management of the respective file system is mimicked.

[0091] Information is stored on the content source 160 and may be either encrypted (i.e., protected) or unencrypted (i.e., plain-text). To the proxy subsystems, it is not important whether or not the files at content source 160 are encrypted or unencrypted. However, in cases where physical security is an issue, it is believed that all files will be stored on the content source in an encrypted form. Therefore, if a malicious party were to physically tamper with the content source they would be unable to gain access to the information stored thereon.

[0092] Encryption of the files as they are delivered from the proxy system 110 to the end-user client device 150 is also implemented within the content subsystem 220. Encryption is preferably implemented through a generic interface, which allows for the simple migration between encryption algorithms. The preferred embodiment, the content subsystem 220 utilizes the Advanced Encryption Standard, known in the art, as the default encryption algorithm, but different encryption algorithms may be used.

[0093] The network file storage system 160 is also utilized, in the preferred embodiment, for high-speed caching of frequently used content that the proxy system 110 accesses on a regular basis. The proxy system 110 also uses the content source to store METAFILES. The METAFILES are implemented on a one-to-one relationship with all the directories (or folders) on the content source 160. The METAFILES (discussed below with respect to Table 3) are plain-text files that contain information pertaining to all the files stored within the related directory. This information includes a long-term encryption key cache for the files stored within the directory. Policy information is also stored within the metafile.

Account Services 224

[0094] The account services module 224 of the proxy system 110 content subsystem 220 includes an authentication subsystem 320, shown in FIG. 3, including an authorization interface 322 and authentication service 324. The authentication subsystem 320 is implemented to manage all security aspects of the proxy system 110. The authentication subsystem 320 is designed to create a trusted environment within a (potentially) hostile environment through the utilization of currently implemented generic authentication and/or authorization information. The two major sections within the authentication subsystem 320 are key management and authentication management.

[0095] The content subsystem 220, in the preferred embodiment, requires a form of authentication to understand who users are when files are requested. The most common way to currently gain this information is through a pre-existing "login" authentication mechanism. Most enterprises today have some form of login system in place from a major third-party provider, such as authentication system 130. Current scenarios require that a user enter a username and password (i.e., credentials) when the user turns on their computer, or begins to use the computer after a pre-specified amount of idle time has lapsed.

[0096] When an end user enters its username and password, this information is transmitted to a central server computer (as part of authentication system 130) that determines if the user has presented the correct credentials. If the correct credentials have been presented, the user is allowed to access the computer or network, as the case may be. The authentication process between client 150 and authentication system 130
generates what is herein referred to as a "shared secret." A shared secret is an artifact of the authentication process that only the enterprise authentication service 130 and the client 150 know. When these credentials are presented, the proxy system 110 does not intercede with the authentication process. However, once the authentication process has been completed (as determined by the client), the proxy system 110
communicates directly with the enterprise authentication service 310 of FIG. 3 to gain a contextual understanding of identity of the user.

[0097] Included in this process is the transmission of the client/authentication service shared session secret to the proxy system 110, for use by the authentication service 324 of the account services module 224; FIG. 3 provides greater detail. User credentials are also passed from the authentication service to the proxy system 110
authentication subsystem. The shared session secret and user credentials are stored in separate caches and are assigned a globally unique entity identification number (EID). The EID is assigned directly to the credential management cache, with a reference to the shared secret cache. This EID serves as the interface through which users are further identified and with which they are interacted.

[0098] User shared session secrets and credentials are stored in temporary caches. This eliminates the requirement for input/output intensive database operations. Since the shared session secrets and credentials are only valid for short periods of time, and are also available (in an acceptable form) from the enterprise authentication service, there is no need for a long-term storage strategy for the shared session secret or the credentials.

Content Management Service 226

[0099] The final major subsystem of the content subsystem 220, in the preferred embodiment, is the management services module 226. The management services module 226 implements the interface for specifying system settings, specifying policy, editing users and groups, and retrieving auditing information.

[0100] The management services module 226 maintains the status and configuration of the content subsystem 220. This includes all the information supplied by system administrators during the "First Run Configuration" set-up, as well as all information regarding the configuration and operating of the proxy system 110 in future uses. This information includes usernames and passwords for administrative users of the proxy system 110, network addressing information for the content source 160 and the proxy system 110, and statistical/log output information. Also included in configuration editor of the proxy system 110 are interfaces to control the usage preferences for all other proxy system 110 subsystems such as authentication server/services information and user store data. Included in the system configuration system is the ability to push information to remote servers. This information may be designed to alert administrators of the system that there are software and informational updates available to them, for example.

[0101] The management services module 226 is directly involved in the implementation and application of policies. When a file is requested by an end-user, it is routed through the content service module 222. The content service module 222, in turn, contacts the management services module 226 to determine if the user has access privileges on-the-file. The management services module 226 evaluates the user/file specific policy from the METAFILES and database, and returns either a "yes" or a "no" to the content subsystem 220. If the answer regarding access is a "yes," then usage policy is also delivered to the content service module 222 from the management services module 226.

[0102] FIG. 3 shows a detailed view of modules that may comprise the content system 220, as well as some of the services, modules and entities with which it interfaces. As discussed previously, the content system 220
implements management functions, performs user and administrator authorization, and delivers content to client devices 150. The content system 220 may be executed on one or more hosts providing or accessing the following services:

[0103] 1) Enterprise Authentication Service 310--As previously discussed, target enterprises may use a wide variety of authentication systems 130
or infrastructures. Hence, it is necessary to integrate the dynamic file access control and management solution with existing authentication services. Where available and desirable, existing enterprise authentication services 310, hosted on authentication system 130, are directly accessed by account service module 224 to obtain identity-proving credentials. Note that there may be multiple authentication services from which identity information may be mapped.

[0104] 2) Authorization Interface 322--Included as part of the account services module 224, this interface includes, as one example, a GSSAPI generic authorization interface, and implements the basic primitives used to distribute credentials used for content access. The proxy server-side implementation of this interface preferably allows simultaneous authentication protocol instances.

[0105] 3) Authentication Service 324--Included as part of the account services module 224, the authentication service 324 creates (via the authorization interface distributes) credentials used to gain access to the protected content. The form of credentials and guarantees provided by this service is a reflection of the security requirements of the target enterprises.

[0106] 4) Repository Access Service (or Interface) 350--Inaccessible by hosts/processes external to the proxy system 110, the access service 350
provides access to the raw content stored in the content repository 210. Access optimization (e.g., caching strategies) and content transforms are implemented by this service. The natively supported NFS protocol is used to access and modify the NAS file- system.

[0107] 5) Access Service (or Server) 332--Included as part of the content services module 222, all content acquisition is achieved through the access service 332. Clients communicate content requests with associated authentication information. Access policies are acquired (and potentially cached) by the access service 332. As is consistent with defined policies, content is returned to the client 150. The content is delivered under an appropriate (and possibly policy defined) set of security guarantees (e.g., confidentiality, integrity, etc.).

[0108] 6) Content Gateway 334--Included as part of the content services module 222, content updates are managed by the content gateway 334. Using a protocol similar to the access service 332, updated content is pushed to the content repository 210 through the repository access interface 350. Policy determines the conditions under which an update should be accepted. Note that care must be taken to ensure synchronization between the access service 332 and content gateway 334.

[0109] 7) Transport Services 336--Included as part of the content services module 222, content and state information (e.g., file-specific keying material, usage policy) is communicated to and from the client 150
through the transport service 336. This service provides a set of security and delivery guarantees. An overview of this service is presented below (in Security).

[0110] 8) Account Manager 342--Included as part of the management services module 226, the identification and authentication requirements of client 150 and administrator entities are maintained through the account manager 342. This service maintains the tables and synchronization of entity information, and potentially maps the enterprise authentication service credentials to universally unique identifiers.

[0111] 9) Policy Editor 344--Included as part of the management services module 226, all content access policies are maintained via the policy editor 344. This service performs internal policy consistency validation, rights revocation, and synchronized policy updates. The definition of this service is determined largely by the definition of the supported policies identified below (in Policy).

[0112] 10) Audit Manager 346--Included as part of the management services module 226, the audit manager 346 specifies and enforces all policies relating to the auditing of content access. Auditing information is efficiently recorded to an ASCII file. Stored auditing information is exported off-line to a database format, and viewing using several auditing tools supported by the auditing management interfaces.

[0113] 11) Management Interface 348--Included as part of the management services module 226, administrators specify all entity, policy, and auditing configuration through the management interface 348. Simplicity of this user interface is a key consideration.

[0114] 12) Entity Database 360--Entity information used by authentication services is stored in the entity database 360. The definition of the fields and tables of this database is the result of the analysis of the support forms of authentication.

[0115] 13) Policy Database 362--Access and usage policies are retained in the policy database 342. Policies included in this database describe the access and usage restrictions to be placed on entities. Note that this does not map policy to content, only specifying the specifics of policies to be applied. These policies are similar to reusable policies defined in the IETF Policy Working Group's Policy Common Information Model, known in the art. The format of both the entity and policy is presented below (in Policy).

[0116] B. Client Module 230

[0117] In the preferred embodiment, the client module 230 evaluates the usage policy inside the kernel of the client's OS. These usage rights can include all aspects of a user's interaction with a file, including, but not limited to: copy/cut/paste, printing, screen capture, launch application control and auditing. Since policy is enforced within the kernel of the OS, malicious users are prevented from compromising the usage policy at runtime because direct access to the kernel is not possible without crashing the system.

[0118] The usage rights are enforced through the trapping of kernel-level OS calls that are tied to a process list. This trapping is accomplished through an understanding of the APIs and other system-level calls that are supplied by an operating system to an application. These APIs and system calls allow for an application to run correctly under an operating system and to take advantage of the functionality that the operating system has to offer. The client module 230 is between the application and operating system, which allows the client module 230 to understand what the application requests from the OS, and modify to these requests an needed to control how information is used.

[0119] When a call is made to the client's OS that has been identified as potential source of data movement, the client module 230 intercepts the call between the application and the OS. As the interception occurs, a list of tagged processes (open files, visible windows, executing applications) is checked to see if the system call will result in protected information being acted upon. If it is determined that the request's source was not acting on a process relating to the applicable usage policies, then the call is allowed to proceed without any further action by the client module 230. However, if it is determined that the call will result in a protected file being acted on, then the usage rights of that particular file are evaluated from within the kernel. If the call is within the allowed functionality set forth in the usage policy, then it is allowed. If the call is not allowed, then the call is blocked and the user is notified.

[0120] When an application is launched and a protected file is opened, the file's usage policy is evaluated, decrypted and securely presented to the application's process thread. The user is not presented with anything new within the application. However, if they attempt to engage in an action that is not permitted by the usage policy, they are prevented from doing so, and the administrator of the system has the ability to, for example, make a dialogue box appear informing the user of the violation, and provides the necessary contact information to have the policy changed, if so desired.

[0121] Additionally, the client module 230 can provide a very granular level of file access and usage auditing. This feature is very valuable to organizations that must spend capital to conduct repetitive security audits. It also allows for a strong chain of accountability in the event that information is compromised from within an organization. Certain events in an audit log can also provide a real-time alarm to system administrators and managers. The auditing capabilities are defined by the enterprise deploying the proxy file management system 100, but they can extend from limited access logging all the way to inter-application action (e.g. menu selections) auditing.

[0122] The client module 230 is designed to be the final line of defense against unauthorized use of enterprise information. Its focus is on the enforcement of usage policy applied by the proxy system 110, and the highly specific auditing functionality. The client module 230 OS kernel-level control of files gives enterprises unparalleled power in their ability to avoid costly application compatibility rewrites and upgrades, as well as a level of security not currently found in traditional file systems.

[0123] In the preferred embodiment, client module 230 enforces authorization and access control policies by redirecting OS primitives, as previously described. Hence, on each client device 150 a set of proxy file management system 100 libraries is installed. The client module 230
can be characterized as providing the following services:

[0124] 1) Account Service 232--Accounting services module 232 communicate identity-proving credentials to the proxy system 110. In response, the proxy system 110 provides perishable credentials used to later gain access to protected content.

[0125] 2) Content Services 234--Content services module 234 provides access to protected content from content source 160. Access policy is enforced at the client 150 through a set of enforcement services.

[0126] FIG. 4 illustrates the modules of client device 150, including client module 230. Client module 230 enforces usage policies at each user host. All enforcement occurs within the kernel 440 of the host operating system. Client module 230 provides the following services:

[0127] 1) Authentication Interface 410--Possibly through an existing authorization interface (e.g., Windows login), this authentication interface 410 obtains the identity or rights proving credentials used to infer access rights. As convenient and desirable, additional authorization interfaces (e.g., smart-cards, proximity devices, etc.) may be accommodated.

[0128] 2) Authentication Service 422--As part of the account service module 232, authentication service module 422 obtains the time-sensitive identity-proving credentials. Authentication service module 422
communicates with the enterprise authorization service (through authentication interface 410) to obtain credentials. Credentials are cached in a protected and possibly encrypted memory or storage device.

[0129] 3) Authorization Interface 424--As part of the account service module 232, the GSSAPI generic authorization interface 424 implements the basic primitives used to obtain credentials used for content access. This interface provides an API for client authorization.

[0130] 4) Applications 450--Applications accessing protected content are not modified in any way in the preferred embodiment. However, the ability to access, modify, or manipulate content will be governed by associated policies., with the context of the application.

[0131] 5) Enforcement Mechanisms 442--As part of the content service module 234, usage policies are enforced by the redirection of operating system calls to proxy file management system defined enforcement software. Redirected system calls will be performed where access is consistent with received usage policies.

[0132] 6) Access Server 444--As part of the content service module 234, access server 444 performs all cryptographic and protocol operations necessary to gain access to protected content at content source 160. The access server 444 provides the proxy system 110 with an access request. Credentials obtained by the authorization service 422 (or some byproduct of the credentials) are provided as necessary to the proxy system 110.

[0133] 7) Content Gateway 446--As part of the content service module 234, content updates are communicated to the proxy system 110 through content gateway 446. The operations performed by this service are largely similar to the access server 444, save that the modified content is delivered to the server for further processing.

[0134] 8) Transport Services 448--Content and state information (e.g., file-specific keying material, usage policy) is communicated to and from the proxy system 110 through the transport service 448. The content is securely transmitted to the client. Once obtained, a plain-text version of the content is presented to the enforcement mechanisms 442. The set of security and delivery guarantees implemented by this service is described below (in Security).

[0135] 9) OS Primitives 430--These are the OS basic primitives, known in the art, upon which applications are built. System calls are redirected to the enforcement mechanisms 442 and applied as is necessary to content in accordance with applicable policies.

[0136] In the preferred form, client module 230 is an OS software plug-in that provides two key features of the overall proxy file management system 100. The first feature is the enforcement of usage policy, the second is detailed auditing. The client module 230 is also responsible for the client-side communications through the proxy file management system 100 secure protocol, described in further detail below.

[0137] An exemplary focus of client module 230 is with Windows 32
platforms, such as the Windows NT/2000/XP platform, due to a high level of adoption in corporate networking environments as a client system 150. The client module 230 can be deployed via downloadable installer, compact disc, or as part of a network install/image push system. Once the client module 230 is installed, the end-user is not required to interact with it, nor do they even need to know that it is there; it can be completely transparent. As previously discussed, the authentication information required by the proxy file management system 100 are derived from assets that are already in place on network user systems (such as computer user login).

[0138] This client-side security perimeter is implemented such that it is independent and transparent to all application programs executing on the end-user's computer 150. Thus, in the preferred embodiment, there is no requirement that application developers to integrate the client module 230 within their software. The client module 230 executes correctly, enforcing all proxy file management system client-side requirements, with ambivalence for all other processes and applications executing under an end-user's operating system.

[0139] Users normally access files on content source through the Microsoft Network Neighborhood window or content management software, with the present invention the file browsing process is not changed in anyway from the user's perspective, i.e., users continue to use Network Neighborhood or content management software, and other standard applications to access remote storage drives and directories. Once the proxy file management system is deployed, there is either a new storage device or a new storage device is available that is proxy file management system enabled or a current storage device becomes proxy file management system enabled. Access to the proxy file management system enabled content source 160
requires that the end-user machine 150 have the client module 230
installed. This measure is a first defense against external individuals who penetrate the network and internal users with no reason to use the proxy file management system.

[0140] The distributed file system functionality is accomplished through a file system driver. The file system driver manages all communications with the client 150 and proxy system 110. In the preferred form, the file system driver is a filter-type driver; it does not implement a new type of file system semantic, rather it interfaces with existing file systems (such as FAT and NTFS) and adds additional functionality beyond that offered by the existing file system. In the case of the client module 230
filter driver, rights and encryption management and the proxy file management system secure transport protocol is implemented. All distributed file system communications are resolved through the filter driver, and thus, through the proxy file management system secure transport protocol.

[0141] This filter driver allows the client module 230 to intercept and modify file requests to and from file servers as required. This filter driver is responsible for encrypted file access and management. All aspects of management such as key storage is handled within encrypted memory spaces where the key is only known to the kernel-mode client module 230. If required, the client module 230 file system driver delivers the files to the underlying file system (such as FAT or NTFS) in an encrypted format. This is to prevent individuals from simply saving a file from a server secured by proxy management file system 100 to an unsecured desktop system, and circumventing the usage rights. The client module 230 file system driver also makes provisions for virtual memory management and non-static memory storage.

[0142] When a user with the client module 230 seeks to access a content source 160 protected by the proxy management file system 100, they are automatically "logged in" to the proxy system 110. Network users never have direct access to the content source 160, as the proxy system 110 is logically between the two. This login process is accomplished without any interaction from the user, as it is automatically accomplished when the user logs in to their client device 150. This login and authentication lets the proxy system 110 know who the user is and what files they are allowed to access and under what circumstances (as defined in the policy for the user and file). Additionally, all communication between the end-user's client device 110 and the proxy system 110 is accomplished using the proxy file management system secure transport protocol, so the security across the network 140 is guaranteed.

[0143] When the user requests a file, the access policy is evaluated by the proxy system 110. If access is granted, then usage rights are applied to the file and it is securely sent across network 140 where the user can open it in their usual application (typically, on client device 150). Unlike traditional digital rights solutions, the application being used to interact with the secure file does not need to be rewritten, thanks to OS level integration of client module 230.

[0144] The usage rights are supplied from the proxy system 110 through the proxy file management system secure transport protocol. This particular packet is received from the proxy system 110 by, and managed from within, the client module 230 file system driver component. The usage rights for a particular file are transferred from the client module 230 file system driver to a physical location in memory that is encrypted and shared by the client module 230 components. The client module 230 connects between the application and OS. This connection allows the client module 230 to understand what the application requests from the OS, and apply modifications to these requests an needed to control how information is used.

[0145] In other embodiments, client 150 (and client module 230) need not obtain usage rights information from the proxy system 110, so need not have a direct link to the proxy system. The content (i.e., one or more files) may be provide via any of a variety of means, after being prepared by a proxy system 110. And, the rights associated with the file may also be provided via any of a variety of means, and need not be provided by the same means as the file itself. For example, the file may be provided via a smart card, floppy disk, or CD ROM, and the usage rights may be e-mailed via a path that does not include proxy system 110. Files and rights may be e-mailed among clients, without the proxy system 110
intervening.

[0146] 7. First Run Configuration & Maintenance

[0147] The proxy file management system 100 is designed to be granted an initial set-up from a system administrator ("sysadmin") individual. The proxy file management system 100 first run configuration is designed to gather all the necessary information for the proper function of the system as a whole. The proxy file management system 100 configuration and maintenance is assisted through automatic scripts that are able to gain information about a network and its resources with limited input from an administrator. Ongoing maintenance of the proxy file management system 100 is preformed after the first run configuration has been completed.

[0148] A graphical user interface (GUI) is provided to the administrator for configuration and maintenance. The user interface supports and implements standard visual interface objects. These include, but are not limited to, buttons, labels, fields, dialog/message boxes, graphical representations and a variety of information presentation techniques such as scroll bars and drag/drop. The user interface gains its functionality through a set of APIs delivered through the management subsystem 226
component of the content subsystem 230 of the proxy system 110. This API allows for the interface to gain the information required to display the relevant information, in real-time, in addition to allowing the interface to deliver the user's input back to the unexposed code.

[0149] In the preferred embodiment, the interface is implemented in an Internet-based environment, currently delivered over a Web connection and browser. Preferably, the browser supports Macromedia Flash. However, the user interface is such (both with regard to the graphical nature and API set) that it could be easily implemented in (or "ported" to) a variety of different delivery mediums and languages, including, but not limited to, Win32 executable, Mac.TM. OS application, Java-based application, and so on.

[0150] 8. Security

[0151] While the security model of the proxy file management system 100 is largely defined by Policy (see Policy), there are three areas which require an explicit statement of security goals: authentication, content distribution, and management. The authentication process obtains identity-proving credentials from an existing or proxy system 110
authentication service. The content distribution service distributes file oriented content to clients. The management services provide interfaces that are used to define proxy file management system entities and policy specifications.

[0152] A clear definition of the types of security relevant to the proxy file management system 100 is a prerequisite to the specification of a security model. The following gives a brief definition of the different guarantees supported by the proxy file management system and component protocols. Content can take any digital form in the following definitions (e.g., message, file content, etc.).

[0153] 1) Confidentiality--ensures that no entity except the intended recipient can gain access to content. The strength and lifetime of provided confidentiality is a byproduct of the selection of cryptographic algorithms and the design of key management services.

[0154] 2) Integrity--ensures that any modification of content can be detected by the receiver. It is expected that any modification will be discarded by the receiver, and such occurrences should be recorded by the system auditing services.

[0155] 3) Authentication--guarantees that the sender/creator of the content can be unambiguously identified. The mechanisms provided by existing file-system services (e.g., owner identification) may be insufficient to meet the needs of proxy file management system environment.

[0156] 4) Non-repudiation--guarantee stating that a sender should not be able to falsely deny content assertion. Typically a byproduct of authentication, non-repudiation is frequently used to provide proof of malfeasance. Note that this guarantee not only applies the creation/modification of content, but also as a means of tracking access to sensitive data.

[0157] 5) Timeliness--guarantee stating that content was created/distributed at a known time. Note that the granularity of this (possible drift in identified time bounds) is a byproduct of the system timing source and system configuration.

[0158] An important aspect of the security model is a definition of the adversary. An adversary is an entity attempting to circumvent the security provided by the proxy file management system 100 services. Note that an adversary need not be malicious; clients may diverge from the system specification by omission or unintentional misuse. Specifically, we assume that an adversary may observe all communication passing between the client 150 and the proxy system 110, arbitrarily modify messages passing on the network 140, or arbitrarily delay or reorder messages passing between the client 150 and proxy system 110. Moreover, we assume that an adversary has a large (but not infinite) computing power at his disposal. Further, we assume that the adversary cannot observe or modify communication between the content service 222 and repository 210, nor modify the policy 370 database or entity 360 (see FIG. 3) database directly, except through management interfaces 348. We assume that the basic cryptographic algorithms (e.g., AES) are fundamentally sound (e.g., cannot easily be broken by an adversary).

Authentication Security

[0159] The security of the authentication process may be largely defined by existing authentication services as previously mentioned. However, where existing services fail to meet defined security goals, it is necessary for the proxy file management system 100 to provide additional authentication infrastructure. Additional infrastructure may take the form of COTS services. However, any solution must provide interfaces to GSSAPI, in the preferred embodiment.

[0160] Any authentication service should provide mutual authentication; that is, both the server and client should be able to unambiguously identify the entity with whom they are communicating. Moreover, both end-points must be able to ensure that there is not a man-in-the-middle (e.g., that all communication is available only to end-points). Both client 150 and proxy system 110 server should ensure live-ness, i.e., the current session is occurring in real-time. Such guarantees will prevent an adversary from mounting replay attacks.

[0161] An artifact of the authentication protocol is a shared secret (e.g., key) known only to the client 150 and authentication service. This secret (or some byproduct of it) must be communicated to the content distribution service. Note that policy should determine the length of time the secret is considered valid. Authentication artifacts should be refreshed (i.e., replaced) once the validity lifetime expires. However, one may mitigate authentication costs by taking advantage of previously established session state.

[0162] Authentication (and the secret itself) can be classified as either weak or strong. Weak authentication is derived from knowledge known by the client 150 and one or more external parties (e.g., password). Hence, weak authentication provides limited guarantees of client identity. For example, since the authentication system 130 server knows the client 150
password; it may arbitrarily and capriciously act on behalf of the client 150. Strong authentication is built upon knowledge known only by the client (e.g., a private key). The kinds of security required for a particular file protected by the proxy file management system is defined by policy. The cost of providing strong authentication may be significantly higher than weak authentication. Hence, users may selectively apply strong authentication policies for only content that strictly requires it.

Content Distribution Security

[0163] As one would expect, content distribution security is of paramount importance. However, note that the kinds of security appropriate for each enterprise (or each distribution) may differ. Therefore, some means of communicating context sensitive security requirements is necessary. The attacks previously identified are all relevant to the content distribution. Counter-measures combating man-in-the-middle, replay, and message reordering attacks must be provided by the proxy system 110. Note that the use of each counter-measure impacts the throughput and latency characteristics of the system. Hence, through policy, it is necessary to allow the specification of the strength of security appropriate for each file.

[0164] An increasingly important limitation of existing information services is their inability to combat denial-of-service (DOS) attacks. These attacks flood information services with bogus or nonsensical requests. As a result, the service is overwhelmed by processing bad requests. The proxy file distribution system are preferably used within a controlled network. DOS attack tend do be a lesser concern than those identified previously. DOS attacks are not addressed in detail herein.

[0165] The proxy system 110 server enforces access policies. These policies map credentials or entities onto a set of access rights. In the preferred embodiment, access rights are defined to be semantically identical to the POSIX read, write, and execute bits. Note that the credentials and entities will be network agnostic; i.e., to support heterogeneous networks, a universal entity name-space is used. Access policies further define the conditions under which access is allowed. These conditions state under what environmental conditions access is allowed. An in depth statement of the policies and model used for authorization is defined below (in Policy).

[0166] Use policies are distributed to and enforced by the client module 230 enforcement mechanisms. Client module 230 restricts kinds of operation that may be performed on the content by proxying operating system calls, as defined above.

Management Interface Security

[0167] The management interfaces of the proxy system 110 provide administrators with the ability to define and alter the behavior of the proxy file management system 100. For ease of implementation, this is performed through a simple HTML based user interface, described above. Depending on the embodiment, the management interfaces may provide a single point of failure for the proxy file management system. In such a case, any entity with access to these interfaces would be able to arbitrarily alter system behavior. Hence, careful design of interface security is necessary.

[0168] The central security issue with the management interfaces is the definition of the entities which have access. This is typically implemented by defining administrator credentials to be given to special entities within the network. As HTML is used as the common interface, it is likely that the existing Web security tools be used for this purpose. For example, the use of X.509 certificates is highly desirable; most browsers and Web servers support the Secure Socket Layer (SSL) protocol. Hence, the certificates will be used with COTS security services implemented in existing tools. Note that the SSL (and Transport Layer Security (TLS)) are highly flexible. The protocol implemented should be the strongest security policy supported (e.g., mutual authentication, strong keys, sound cryptographic transforms).

[0169] Access to the management interfaces must also be defined with respect to read and write rights. Moreover, access to each management interface (e.g., entity, policy, and auditing) should be mapped to potentially different credentials. Access to one interface should not imply access to all. A master administrator should be granted read and write access all interfaces. Some consideration should be given to the means by which the master administrator should be allowed s access (e.g., only from the local terminal).

[0170] 9. Policy

[0171] Policies, in the proxy file management system, define to whom and under what conditions access to protected content is granted. The policy 550 farther refines access by stating constraints placed upon the use of received content. Policy maps the relationships between the central system objects; entities, policies, and content. FIG. 5 describes the entity relationship between these policy objects. Note that the content information is stored on the file-system itself, rather than in the database.

[0172] An entity 510 is an object to which access rights and restrictions are assigned. Entities can be users or groups (or specializations thereof). Users are entities that are authenticated by the authentication framework. Groups are collections of entities. Each group can contain one or more users and groups. Hence, the organization of entities in entity database 360 can reflect the enterprise in which the proxy file management system 100 infrastructure is used (e.g., the definition of users and groups can model the hierarchy of users, departments, offices, etc.). A brief description of the entity database is presented in Table 1, which defines the characteristics of all entities participating in the proxy file management system 100 infrastructure. All external references (in other databases) to entities use the entity identifier (eid).

1TABLE 1
Entity Database Field Description eid Globally unique identifier 512- a byte string uniquely identifies this entity. The identifier is used as a reference handle throughout the system. entityType Entity Type 518 - this enumerated type defines the kind of entity defined in the record. The entities types are: server, user, administrator, group, and nobody. The administrator entity is a special user with the ability to modify policies. The "nobody" type defines a special group to which all users and groups in the system implicitly belong. name Common entity name 514- the name of the entity. For example, a common user may be named "Bill Smith". Groups will be assigned a name representing the defined community (e.g., Engineering, Marketing, etc.) revoked Revocation flag 516 - this flag indicates that the rights associated with this user or groups have been revoked. Any access associated with this entity will be rejected when this flag is set to TRUE. authType Authentication type 520 - this enumerated type identifies the kind of authentication appropriate for this entity. This policy states that a user must be authenticated by the identified service before they are allowed to assume the entity. Not that this implies that the same physical user or group will be represented by a distinct entity for each acceptable authentication type (e.g., Engineering/ Kerberos, Engineering/RSA). gid Group membership identifiers (multi-valued) 522 - this list of identifiers (where each id refers to a entity record) identifies the groups to which this entity belongs. Note that membership is restricted to only group entities.

[0173] Policies 550 state the conditions under which access to content is granted. These conditions identify system predicates that must be satisfied for access to be allowed. For example, administrators may wish to limit the number of simultaneous viewers, or restrict access to business hours. Policies 550 also state the restrictions to be placed on content if access is granted. Enforced by the client module 230, access restrictions further define the operations permitted by the user on received content. For example, administrators may wish to prevent printing of a document. Access condition and restrictions are designed to be extensible; the introduction of new (condition and restriction) types will not require any modification of the database. However, new management interfaces and enforcement mechanisms must be created. A brief description of the policy database is presented in Table 2, which defines the policies to be enforced by the proxy file management system infrastructure. External references (in other databases) to policies use the policy identifier (pid).

2TABLE 2
Policy Database Field Description pid Policy Identifier 562 - a word (e.g., four byte) uniquely identifying the policy. The identifier is used as a reference handle throughout the system. name Policy Name - a unique plain-text identifier used to reference the policy in user interfaces and auditing information. This name is assigned by the administrator during policy creation. accConds Access Conditions (multi-valued) 564 - the access conditions state the conditions under which access will be allowed. Each condition consists of: a) condType 572 - this (enumerated) condition type defines the kind of condition being measured. For example the time- of-day type defines a condition that evaluates the period (as measured by wall clock time) during which access should be permitted. b) param1, param2, . . . 574 - the parameters of the condition. The interpretation of condition parameters is dictated by condType. In the above example, the parameters may be assigned as follows: param1 = 8 am, param2 = 5 pm. Hence, the condition dictates that access should only be allowed between 8:00 am and 5:00 pm. accRestr Access Restrictions (multi-valued) 566 - the access restrictions state how the client module 230
should further restrict the use of content after access is allowed. Each such restriction consists of: a) restType 576 - this (enumerate) restriction type defines the kind of restriction to be enforced. For example the printable type defines a restriction that state to whom this document may be mailed. b) param1, param2, . . . 578 - the parameters of the restriction. The interpretation of parameters is dictated by restType. For example, in the above example, the first parameter may be assigned to TRUE. Hence condition dictates that printing of the content should be allowed.

[0174] Protected content is stored in the files and directories of the protected file-system (i.e., network attached storage system 160). Note that each proxy system 110 server follows the naming conventions of the exported distributed file-system interface (e.g., AFS, NFS). Hence, content is identified by the fully resolved DFS path-name. For example, (assuming an NFS interface) the file /usr/local/proxysystem.text on the server hotbox.proxysystem.com is uniquely identified by the name:

hotbox.proxysystem.com:/usr/local/proxysystem.tex

[0175] This name is used throughout the proxy file management system 100. A content identifier is a hash of this name (using a collision resistant hash function, e.g., MD5). All references to this content in the content policy database 370 use the content identifier.

[0176] Content is further organized by the hierarchical structure of the file-system, where the traditional parent/child relationships are used in the evaluation of policy. Specific to each directory and described below, the METAFILE defines the relationships between proxy file management system objects. It is this information which defines the how policies are enforced over content.

Policy Enforcement

[0177] As noted in the architectural overview, there are two distinct domains of enforcement in the proxy file management system infrastructure. The proxy system 110 content subsystem 220 enforces access policy, and the client module 230 enforces use policy. Access policies are only accessible through the management interfaces 348 (see FIG. 3). Hence, the security (e.g., confidentiality and authenticity) of access policy is determined by the facilities provided by the management interfaces 348. Use policies are communicated to the client 150 at the point at which access is given. Hence, the means by which use policies are communicated to clients must guarantee authenticity. Moreover, the delivery must be confidential to avoid exposure of potentially sensitive enterprise policy.

[0178] Access policies state the conditions under which access to content is allowed. Denial is always assumed; failure to specify a policy indicates that the entity does not have access to content. Hence, proxy file management system policies represent a closed world. This design requires all content access be explicitly stated. The advantage of this position is that errors of omission are not possible. Given the amount of information that must be managed, this conservative approach is generally preferred.

[0179] Access policies are enforced as follows. Initially, the request information (entity, content, and access types) is mapped to a set of content policies. If no such content policy exists, the request is denied. If such a content policy does exist, then the associated policy conditions are evaluated, and access allowed if all such conditions are satisfied. As dictated by configuration, information relating to the access attempt is passed to the auditing service. The enforcement mechanism performs the evaluation algorithm defined in the preceding paragraph for every group in which the entity is a member (and recursively for every group that the group is a member).

[0180] Note that there may be several content policies matching a single request. For example, where a user named Bob may be denied access, his membership in the Engineering group may allow it. Therefore, modulo acceptance, all relevant policies must be evaluated. The usage policy given to the client will be the union of those defined in all accepting policies. It is expected that protected content share a small number of policies (exhibits reference locality). Hence, the use of result caching can significantly reduce evaluation costs.

[0181] Various types of file-system semantics may be enforced or supported (e.g., Unix, CIFS, or AFS-like semantics). In accordance with such file system semantics, the read access policy is evaluated for the parent directory, and execute access policies for all parent directories from the file to the root. While this may negatively affect policy evaluation performance, it is necessary to maintain similarity with existing file-systems. Note that usage policies are not relevant to this evaluation. Hence, only one satisfying policy need be found (rather than all accepting policies).

[0182] Use policies enforced by the client module 230 define which operations may be performed by the client 150 on received content. The access restrictions in the access accepting policy (policy that allows access to the content) are communicated to the client at the point at which the content itself is transferred.

Policy Semantics

[0183] The following attempts to capture the semantic of proxy policy management system policy in algorithmic form. This section uses the following notation throughout. The set of all user entities defined in the entity database is denoted E (where e.sub.i is a single user). The set of groups defined in the entity database is denoted G (where g.sub.i identifies a single group in G). The membership of any group g.sub.i is a subset of the G and E (g.sub.iG U E, E.andgate.G=.O slashed.). The set of content protected by the proxy system 110 is denoted C (where c.sub.i is a single protected file or directory). An access request a.sub.i is a combination of one or more read, write and execute rights encoded in binary form. The set of all policies is denoted P (where p.sub.i is one policy in the policy database). The set of access conditions (restrictions) of p.sub.iare denoted p.sub.i (p.sub.i.sup.d(p.sub.i.sup.r- ). The set of content policies CP (where cp.sub.i identifies one such policy) maps the tuple (c.sub.i, e.sub.i, a.sub.k) onto one policy in P (i.e., (c.sub.i, e.sub.i, a.sub.k.fwdarw.p.sub.n). Note that for any tuple (c.sub.i, e.sub.i, a.sub.k), there may exist zero of more content policies. The semantics of the policy is described through the following evaluation algorithm.

[0184] Given: An access request (c.sub.i, e.sub.j, a.sub.k), where c.sub.i is the content.

[0185] Algorithm: The conditions 1 and 2 (described below) are tested for (c.sub.i, e.sub.j, a.sub.k) and (g.sub.q, e.sub.j, a.sub.k), where g.sub.q is all groups in the transitive closure of .epsilon. from e.sub.j in G). If access is granted by some non-empty set of policies, the conditions are tested (r.sub.i, e.sub.j, read) where r.sub.i is the parent directory of c.sub.i, and (r.sub.j, e.sub.j, execute) for every directory r.sub.j on the c.sub.i's path to the root.

[0186] Access is granted only if all requests such are satisfied.

[0187] 1. Condition 1: (non-revocation)

[0188] The user e.sub.j has not been revoked (as indicated by the revocation flag in the entity database). No further processing is attempted where the requesting user's rights have been revoked (no exceptions consulted).

[0189] 2. Condition 2: (policy)

[0190] There exists some content policy cp.sub.l=c.sub.i, e.sub.j, a.sub.m.fwdarw.p.sub.n such that all p.sub.n.sup.d.epsilon. p.sub.n are satisfied and a.sub.m a.sub.k (bitwise and--request rights are a subset of policy rights).

[0191] The usage policy is created as follows: given all satisfying policies P' for c.sub.i, a.sub.k (where u.sub.j for p.sub.i), the usage policy u given to the client is: 1 k = 1 P ' u j

[0192] The resulting usage policy is encoded and delivered to the client as dictated by the evaluation, and denial otherwise.

[0193] 10. Content Storage and Communication Protocols

[0194] This section describes the format and operation of the protocols used to distribute content within the proxy file management system 100. The security of the protocols described in this section are predicated on the following assumptions. Violation of any of these assumptions may expose the proxy system 110 server to a number of attacks.

[0195] 1) A known key (signified throughout as the session key) only to the authorized client 150 and proxy system 110 is established through the authorization interface 322 (see FIG. 3). This key is not exposed by either party.

[0196] 2) Both the client 150 and proxy system 110 have a common source of timing information. The timing source should be sufficiently synchronized. Thus, the global time reported at any instant to each entity should not differ by more than an timing tolerance delta (.delta.). This implies that the clock drift must not differ significantly.

[0197] 3) All cryptographic algorithms should be sound. Hence, it must be intractable to obtain plain-text from cipher-text without the encryption key, invert the collision resistant hash functions, etc.

[0198] 4) An adversary may only acquire information from messages sent between the client client 150 and proxy system 110. This implies that neither the client 150 or proxy system 110 can be compromised, i.e., the back-door assumption. Note that the compromised client 150 must never be to able increase the access rights given to a compromised user.

NAS Storage Format

[0199] Files stored on the NAS storage system 160 are stored in the NAS-native file-system format in plain-text. However, encryption costs are mitigated by storing the encrypted images of recently accessed files in a proxy file management system 100 directory tree mounted off the root directory of the NAS file-system 160. This prevents the loss of data following a catastrophic failure and allows existing backup software to operate normally. Moreover, this limits the possible data loss caused by bugs in the content subsystem 220 or client module 230.

3TABLE 3
METAFILE Format Name Length Description record-length 16 bits total record length filename-hash 16/20 bytes hash of filename - not pathname ownerid 32 bits entity identifier of file owner flags 16 bits first two bits are encrypted bit and valid bit; others unused for now and reserved for future use encryption-algorithm 16 bits (enumerated) identifies both the algorithm and the key length key-data 256 bits only higher order bits contain the key; rest ignored key-lifetime 32 bits time-stamp at which the long term should be discarded initialization-vector 256 bits seed initialization vector used by the encryption algorithm. Multiple IVs are used to allow random access to the file. unused 20 bytes (for any future needs) number-of-policies 16 bits number of policy definitions to follow (designated as in the following field policy tuples bits 32 bits of gid and 32 bits of pid (values from entity and policy databases).

[0200] Each directory on the NAS maintains a single file (e.g., METAFILE) describing the information associated with the files of that directory. The METAFILE is stored in the plain-text directories and includes a single record for each file. The METAFILE record format described in Table 3 above, wherein each field describes the policy and recent keying information for stored protected content. Note that associations between policies and files are recorded in the policy tuple fields.

[0201] Files are (re)encrypted at the block level at the NAS with a new key when they are first accessed or following a change in policy or access rights. The (encrypted) blocks are transmitted without any subsequent encryption to the client. The key used to encrypt the file is distributed to the client as defined by the file payload, as discussed below. To simplify,

[0202] 1) Each file is encrypted by a long term key that is invalidated following a change in policy or when the long term key lifetime is reached (stored in the METAFILE).

[0203] 2) Invalid keys are replaced and the file re-encrypted on access.

[0204] 3) The long term encryption key delivered to clients under the session key at access time through the file key payload.

[0205] For reasonable-size directories, the length of the METAFILE is expected to be no more than one or two blocks. Hence, updating the policy for all files in a directory should be very fast (<20-30 ms or so at current disk speeds). Doing a recursive update for the entire file system will take longer, depending on the depth of the recursion. However, this cost should be within a reasonable factor of doing recursive chmod. A record for each sub-directories is maintained in the parent directory METAFILE (or in itself for the root directory). The only important information about a directory is the access policy information (i.e., usage policies are not meaningful).

[0206] On a file creation, the METAFILE will automatically inherit the policies of the parent directory. The {gid, pid} tuples will be copied into the new record for the file. The encryption key is invalidated on any change of policy on a file by clearing the valid bit). The file is re-encrypted by the proxy system 110 and a new key installed in the record for the file on subsequent access (rather than immediately). The records are need not be sorted as memory operations are fast and the METAFILE is expected to be 1 or 2 blocks. Disk access time dominates any memory operations.

[0207] The cipher modes (e.g., CBC) used in encryption require that all bytes prior to requested plain-text be decrypted. Hence, operations such as fseek( ) may require that the entire file be decrypted to recover the plain-text. This is stark contrast to the performance needs of clients. The following construction is used to mitigate these costs by encrypting each proxy system 110 block independently;

[0208] 1) Each file is separated into blocks of size b.sub.f (where b.sub.f is a configured block size stored with the file. So, a file f that contains blocks f.sub.0, f.sub.1, . . . , f.sub.n, where n is [.vertline.f.vertline./b.sub.f].

[0209] 2) The initialization vector i.nu..sub.f assigned at key creation time. The initialization vector for each block is calculated by XORing i.nu..sub.f with the block number. Hence the i.nu.s for the blocks of f are (i.nu..sub.f.sym.0, i.nu..sub.f.sym.1, i.nu..sub.f.sym.n). Because i.nu..sub.f is constant, and the block number is unique for each block, each block will have a unique initialization vector.

Message Transform

[0210] Any of a variety of secure transforms known in the art may be used with the proxy file management system, such as IPSEC and SSL, as examples. Alternatively, the following "lightweight" transform may be used, which allows for greater bandwidth management than those known in the art.

[0211] Shown in FIG. 6A, the proxy file management system 100 content transform 600 provides sufficient context to determine the freshness, integrity and ordering of a client or server message. All communication between the client 150 and proxy system 110 use the content transform 600. This transforms encapsulates the security and contextual information needed for communication between proxy file management system entities. The purpose of the single transform is to simplify processing; each new message is processed by the single transform processor. FIG. 6B describes the fields of the message content transform.

[0212] Note that the file-system data is encapsulated in the message payload field. This field is treated as opaque data throughout this section. The following section describes the format and processing of the different payloads. A further advantage of this approach is that the authenticity and integrity of a message can be assessed with knowledge of the semantics (payload type). This increases the speed with which proxy file management system software can discard invalid messages. The following describes the input and output processing of the message content transform.

[0213] The delivery guarantees provided by IP (e.g., UDP, TCP) are not secure. Hence, the transport layer must provide both ordering and reliability guarantees. This is accomplished through a sliding acknowledgment window protocol supported by the sequencing fields of the content transform (i.e., SeqNo, AckNo).

Message Output Processing

[0214] 1) The payload, flags, SeqNo, AckNo, source, destination, and time-stamp are filled into the message.

[0215] 2) The time-stamp is acquired from the local timing source and placed in the time-stamp field.

[0216] 3) The payload data is acquired from the appropriate source. Further processing of the payload is performed as dictated by the flags. Where multiple flags are set, they are perform in the order stated below.

[0217] a) Signature Flag--indicates the payload has been signed by the source.

[0218] b) Encryption Flag--where encryption is enabled, the payload is encrypted as follows: the initialization vector is calculated by truncating a hash of the concatenated time-stamp and source identifier (the hash algorithm used is identifier in the hash algorithm id field). For example, IV=h(sid, ts). The entire payload is encrypted under the calculated IV and the session key shared by the source and destination.

[0219] The result of the applied transforms is placed in the payload field. Where no transform is applied, the plain-text is placed in the payload field.

[0220] 4) The hash algorithm id is placed in the appropriate field.

[0221] 5) An keyed hash is calculated using the construction defined in RFC 2104. This construction calculates the HMAC using session key shared by the source and destination and hash algorithm identified in the algorithm field. All bytes preceding the HMAC length field are used as input to the HMAC generation. The length and HMAC value are placed in the appropriate fields.

[0222] 6) The completed message is transmitted to the destination.

Message Input Processing

[0223] 1) The payload ID, flags, length, SeqNo, AckNo, source and destination IDs, hash algorithm and HMAC length fields are extracted from the message and validation. If any field contain an invalid value, the message is ignored.

[0224] 2) The time-stamp is extracted from the message (denoted m.sub.s). A message is ignored if the following relation is true (where .delta. is a message reordering tolerance, .epsilon. is a clock skew tolerance, and c is the current time reported by local timing source);

[0225] a) l.sub.s-m.sub.s>.delta.

[0226] b) .vertline.m.sub.s-c.vertline.>.epsilon.

[0227] These tests validate that no previously message is accepted beyond the configured clock tolerances.

[0228] 3) An HMAC is calculated over all fields through the last byte of the hash algorithm ID. The result is compared to the transmitted value, and the message is rejected where the values are not identical.

[0229] 4) The payload is extracted and the reverse payload transforms are performed. If properly formed and processed (e.g., decrypted correctly, signature validated), the resulting payload data is then passed to the payload processing software.

[0230] 5) If the payload is properly processed, the received timestamp is recorded in the last received timestamp state variable.

Payload Formats

[0231] Payload data encapsulates the file-system communication between the client 150 and proxy system 110. Note that payload data is obtained only from the successfull completion of the transform input processing defined in the previous section. Payload data is driven by the (authentic) payload designator of the transform. This information is passed to the payload processing software, and further processing of the payload types is defined in the following subsections.

[0232] 1) File Key Payload Format (AERE_FILE_KEY)

[0233] The file key payload communicates the file and policy information associated with an accessed file. Sent following a file open( ) call, this transform gives sufficient information for a client to recover the file plain-text from encrypted file blocks. Note that this transforms requires that the encryption flag in the message transform be set. Failure to set this bit would result in the exposure of the key data, and indirectly expose the protected content. FIG. 7 and FIG. 8 depict the transform contents.

[0234] 2) Block Format (AERE_BLK_XFER)

[0235] The block transform is used to transfer file blocks between the client and server. Each block is delivered to the transport layer in encrypted format. Hence, it is not necessary to encrypt the data for transfer. The integrity and authenticity of each block is guaranteed by the encapsulating content transform. The fields of the block transform are detailed in FIG. 9.

[0236] 3) Status Transform (AERE_STATUS)

[0237] Status transforms are used to communicate state changes and debugging information between clients 150 and proxy system 110. Status messages are used as a signaling protocol between clients 150 and proxy system 110 server (i.e., to communicate proxy file management system infrastructure events). Hence, these transforms are used independently of the distributed file-system protocols, each of which contains is own signaling mechanisms. The fields of the status transform are detailed in FIG. 10.

[0238] 11. Alternative Embodiment

[0239] In addition to, or as an alternative to, the proxy file management system described above, a dynamic file access control and management system in accordance with the present invention may be