CA2202118A1 - Protected persistent storage access for mobile applications - Google Patents
Protected persistent storage access for mobile applicationsInfo
- Publication number
- CA2202118A1 CA2202118A1 CA002202118A CA2202118A CA2202118A1 CA 2202118 A1 CA2202118 A1 CA 2202118A1 CA 002202118 A CA002202118 A CA 002202118A CA 2202118 A CA2202118 A CA 2202118A CA 2202118 A1 CA2202118 A1 CA 2202118A1
- Authority
- CA
- Canada
- Prior art keywords
- applet
- applets
- access
- file
- domain
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 230000002085 persistent effect Effects 0.000 title claims abstract description 29
- 238000000034 method Methods 0.000 claims abstract description 22
- 238000012545 processing Methods 0.000 claims abstract description 12
- 230000008569 process Effects 0.000 claims description 3
- 230000008859 change Effects 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000004888 barrier function Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 230000035945 sensitivity Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
- G06F21/12—Protecting executable software
- G06F21/121—Restricting unauthorised execution of programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/629—Protecting access to data via a platform, e.g. using keys or access control rules to features or functions of an application
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/101—Access control lists [ACL]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2211/00—Indexing scheme relating to details of data-processing equipment not covered by groups G06F3/00 - G06F13/00
- G06F2211/007—Encryption, En-/decode, En-/decipher, En-/decypher, Scramble, (De-)compress
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/168—Implementing security features at a particular protocol layer above the transport layer
Abstract
A method of processing an applet comprising storing a file in a persistent storage medium (PSM), the file including an access control list, transmitting an applet from a server, the applet including at least one of applet identification data and a private key encrypted domain identifier and public key pair, a maximum file size indicator, and a specification of required operations, receiving the applet by an application engine, in the event the domain identifier is included in the applet, decrypting the domain identifier using the public key, checking at least one of the applet identification data and decrypted domain identifier against the access control list for a match, and in the event a match is found, allowing the operations specified in the applet on a file stored in a persistent storage medium which allow access to the applet as specified in the file access control list.
Description
File llP239CA
FIELD OF THE INVENTION
This invention relates to the field of computer networks and in particular to a method of processing computer applets in a secure manner.
BACKGROUND TO THE INVENTION
With the advent of object based programming, it has become possible to transmit applets via a network such as the internet to various computers connected to the network. An applet is a small self-contained application program which can cause a computer to perform a particular function, and contains both instructions for the computer to operate and data which is to be processed in its operation.
Various programming languages have been designed to create applets, such as Telescript, SafeTCL, Java, CyberAgents and ClearLake Agents. By the use of interpreters, the various applets can be hardware independent, that is, the same applet can be received and processed by computer hardware having different operating systems. For example, the same applet would be able to be received and processed by a MacIntosh operating system and by one of the Microsoft Windows operationg systems on an Intel processor based (e.g. IBM
personal computer) type operating systems.
It has been speculated that the programs and data that computers that receive applets use would provide all that a computer would need, to be able to be fully functional and which would result in a significantly less expensive computer than at present.
This is because the computer would be expected to use the network as a mass storage repository of programs and data. Programs would be paid for on a use basis, rather than on an up-front-payment and unlimited use basis.
However this presupposes that a user would be prepared to allow mass storage to be out of his control to store critical data, specially written programs, etc. For the reason of security, it had been believed to be desirable and/or necess~ry to provide a local mass storage associated with each or with most computers.
With the storage of data on a local mass storage device, the problem of security arises in relation to the reception from the network of applets, since those applets could access and transmit or corrupt files.
lo The security problem has been handled in one of two ways.
The first is to restrict the use of applets to a closed or managed system, wherein software components can be given domain names and all possible execution sites can be populated with lists of allowed domains.
For example, in the CyberAgents program, domains are used to control execution and security on remote sites.
A domain is a jurisdiction group of applets that share access rights.
The second way of handling security is to isolate the applets from important system resources, as noted earlier above. Applets received from an uncontrolled system network such as the internet have been restricted from being able to access mass storage devices, and have been relegated to providing fancy graphics and to providing a graphical user interface for client-server computing. Programs to create applets in open uncontrolled systems, are e.g. Telescript, SafeTCL
and Java. For example, Java can cause a computer to display a window and provide the content of the window and play sounds, but cannot write to the computer disk drive.
While use of either of these schemes produces the required security to ensure that rogue applets do not cause damage to a computer's resources, such as the files, they also place restriction on the usability of open system mobile applets. If a downloaded applet cannot access the disk drive to provide persistent local storage for the user, the usability of applets written using such an isolation scheme is very limited.
Operating systems approach security by providing usage rights over directories and files. By assigning the applet application engine to a user group, the applets executed by the application engine are restricted to accessing those files available to the application engine itself. While this provides security to other file system files outside the reach of the application engine, it does not provide security between applets. Similarly, some applet application engines, such as Sun's HotJava, provide access control lists.
These lists specify which subset of the application engines accessible files can be accessed by applets.
This provides extended security, but does not solve the problem of providing security to data between applets.
HotJava also specifies a method by which access to files can be granted to applets through the use of a dialog box to the user of the applet, wherein the user is required to enter a security authorization.
This provides greater security between applets but is intrusive and requires that the user understand the sensitivity and origin (virtual ownership) of data in each file.
If the application engine can determine the source of the applet, access rights can be set according to certain rules. Java can detect if an applet originates within a firewall (a software barrier to outside access to a local (internal) network); the HotJava Browser allows different security rights to applets loaded on each side of the firewall. Read and write access can be granted to internal applications only.
General Magic's Telescript technology provides a generic set of authorities and permits. Agents within a region all contain the same authority - this is similar to the concept of user domains. Each Telescript agent has only one authority. Permits control the execution of instructions or the access and usage of a resource. Telescript does not specify how a Telescript place negotiates usage rights for a resource with an agent of a certain authority, or stores the access rights for each resource instance.
The term "persistent storage" will be used in this specification as a generic term for all media which store or carry files, data or programs which are to be protected, and can include, but is not restricted to electronic random access memory, floppy or hard disk drives, buses, etc.
SUMMARY OF THE INVENTION:
The present invention provides secure access to persistent storage for distributed applet code within an open uncontrolled computing environment. It protects files from unauthorized use by unknown mobile applets while still providing access to the file system for these applets. This involves negotiating access rights for the unknown applet.
In accordance with an embodiment of the invention, a method of processing an applet is comprised of storing a file in a persistent storage medium (PSM), the file including an access control list, and transmitting an applet from a server, the applet including at least one of applet identification data and a private key encrypted domain identifier and public key pair, a maximum file size indicator, and a specification of required storage operations, receiving the applet by an application engine, and in the event the domain identifier is included in the applet, decrypting the domain identifier using the public key, checking at least one of the applet identification data and S decrypted domain identifier against the access control list for a match, and in the event a match is found, allowing the operations specified in the applet on a file stored in a persistent storage medium which allow access to the applet as specified in the file access control list.
In accordance with another embodiment, a method of providing an applet is comprised of receiving applets in an application engine, the applets comprising specifications of operations to be performed, and some of the applets being comprised of at least one of applet identification data and private key encrypted domains, processing the applets to an extent to which access to files contained in a persistent storage medium is not required, in the event applets are comprised of private key encrypted domains, decrypting the domains, checking at least one of the applet identification data and decrypted domains against a control list, and processing the applets which the at least one of applet identification data and decrypted domains match entries in the control list to access the files contained in persistent storage medium required by the applets.
In accordance with another embodiment, a method of processing an applet is comprised of storing an access control list which contains an identity of applets or domains that can have access to files stored in a persistent medium, and giving access to the access control medium by applets which contain an identity or a domain corresponding to an entry on the list.
In accordance with another embodiment, an applet application engine is comprised of an access control list, the engine and list stored in a memory of a computer, and apparatus for providing an applet comprising an identification of at least one of an applet identifier and a domain for comparison with the list and determination of a match, and apparatus for allowing access to an otherwise protected computer resource in the event of the match.
BRIEF INTRODUCTION TO THE DRAWINGS
A better understanding of the invention will be obtained by considering the detailed description below, with reference to the following drawings, in which:
Figure l is a block diagram of a network on which the present invention can be implemented, Figure 2 is a block diagram of a computer used in the network of Figure l, on which the present invention can be implemented, Figure 3 is a illustration of a representative applet which is used in the present invention, and Figure 4 illustrates a representative method of operation of the invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
Figure l illustrates an open and uncontrolled network, and is comprised of a server l, which interfaces a network 3, to which various computers 5 are or can be connected. The network 3 can be a wide area network, the internet, a telephone network, etc.
In operation, the server l applies applets to the network 3 for reception by one or more computers 5.
A computer which receives the applet, which is a complete object based program, processes it using the data contained therein. As noted above, in prior art open systems the applet was restricted from being able to access persistent storage.
Figure 2 illustrates the basic architecture of a representative computer system 5. A microprocessor 7, random access memory 8 (RAM), a keyboard 9, a network interface device 10 such as a modem, a hard disk drive 11 persistent storage device, and a display subsystem 12 to which a display 13 is connected, are connected to, or are in communication with, a bus 14.
In addition, random access memory 16 (RAM), which may be part of or merged with RAM 8, is connected or in communication with bus 14. RAM 16 contains a applet application engine, which is comprised of an interpreter for the particular applet language used, and a software command structure to cause microprocessor 7 to process the applets. For example, for the Java language, an applet application engine can be HotJava, available from Sun Microsystems Inc..
In operation of a prior art system, applets are received from the server 1 via the network 3 and network interface 10, are interpreted by microprocessor 7 using the interpreter in application engine 16 and the interpreted instructions are processed by microprocessor 7 to cause the display subsystem 12 to display graphics, etc. on display 13. The application engine will not access persistent storage media such as the hard disk drive 11, to avoid corruption etc. of files as described therein, and therefore cannot use data or other programs stored therein. Such a system is thus considerably limited.
In accordance with the present invention, the application engine 16 contains a public key decryption program 18 and an access control list 20 of authorized applets and/or domains which may be allowed to access persistent storage media.
In accordance with the present invention, when applets are received via the network interface, access rights to the persistent storage media are negotiated using the application engine 16. Arc~cc rights need not be restricted and access negotiated only to persistent storage media; any resource of the computer or S controlled or accessed by the computer can be restricted and access thereto negotiated.
~ceCc rights are negotiated by (a) authentication; the applet application engine verifies the identity or domain of all applets requesting access to persistent storage;
(b) usage rights negotiation; this involves verifying the applet's authority to read, write or append to a file. Methods to ensure that an applet has access rights to a particular file are described below.
It should be noted that in an open uncontrolled system, central authentication or domain management is not possible. For this reason, the negotiation of access rights is conducted between the application engine, the file and the applet;
(c) quality of service; maximum disk usage for an application is set. Limits are preferably placed on access rights which give the bounds within which the granted resource may be used.
By acting as an intermediary between the unknown applet and the disk resource, the application engine negotiates and enforces access rights. For disk files, this involves acting as an intermediary for all disk actions. If a target file will grow beyond a predetermined size, a write can be denied or the user can be asked for override permission, which effectively allows growth of the access rights by an incremented amount. The application engine can specify an override zone, above which the access right will not be allowed to grow.
As a safety meçh~nism, file versioning may be provided by the application engine to ensure that any modifications or deletions to files can be recovered in the event of damage to the file system. Access control list 20 is used by the application engine to specify what default and file specific access rights are for individual persistent storage objects (files).
Each applet should be associated with a server site that uniquely identifies the applet. If loaded lo from the World Wide Web, for example, this identity can be the universal resource locator (URL) of the applet.
When an applet creates a new file, it can specify which applets have which rights on the file.
Domains are groups of applets which share access rights. Using private key encryption and an encrypted message supplied by the applet, the application engine can ensure that an applet belongs to a specified domain. Applet files contain a header which contains the access control list for a set of domains and public keys for each domain.
Figure 3 illustrates an applet 22, which contains a payload 24 comprised of an object based application program including data, and a header 26.
The header 26 contains a public key or keys 28, and an 2s application control list 30. It also contains an identification of the applet (e.g. the URL if used on the World Wide Web), which can be encrypted at the server using a private key, for decryption under control of the application engine 16 using a public key 28. The header also contains an encrypted set of domains e.g.
domain messages, which can be decrypted using a public key 28.
An applet can belong to more than one domain at a time. It is the responsibility of the domain owners to ensure that the private key used to generate encrypted domain authentication messages is kept secure As noted above, the encrypted message may encrypt the applet identification using the private key This ensures that the encrypted message has not been copied from another applet in an attempt to borrow that applet's domain capabilities. Any attempt to clone the server applet to another machine and then be able to read domain owned files would then cause the encrypted message to not match the applet identification, invalidating the applet's domain within the application engine.
A combination of access methods is preferably used to provide secure persistent storage access to applets. Both applet identification and preferably domains are implemented as keys within the access control list for a file.
The language classes for file access in the application engine 16 for the particular language used, e.g. Java should be amended to allow access to the file system based on the applet's identification and domain.
Applets should be modified as indicated above with respect to Figure 3 to optionally include their domain, and by the use of public key encryption thereof and/or their identification. Each file with access rights associated with it is contained in the access control list 20 (Figure 2) in a file stored in RAM 16 accessible by the application engine, e.g. a browser program. The application engine retained in RAM 16 negotiates access rights for each loaded applet. Access rights contain quality of service information that defines how each resource can be accessed, including maximum size changes. Each change to the file system is checked to see if it would violate access rights. This includes the right to access, change or create a file and limits on the size of changes.
The structure of the access control list is preferred to be:
<Filename:... >
<<AccessMode,...>:<IDorDomain,...>;...>
where:
Filename Contains one or more file names, each of which may contain wild-cards lo Acc~c~sMo~e Is one of Read, Write, Append, Delete, NewFile, List, Query, (MMaxSize:x) IDorDomain Is either a URL specifying an applet, or a (DomainName:publicKey) pair For example, an entry where all files in the "/public" directory are readable, "/private" can have new files created by applet, URL
"http://www.foo.bar/applet.class" and applets of domain "MyDomain" have write access to the file "/private/foo.bar" with add mode set to 5000 bytes, could appear as:
/public/*
Read : *
/private/*
NewFile : *
/private/foo.bar Write, (MaxSize:5000) :
http://www.foo.bar/applet.class; (MyDomain: 987654321) A message send within the application engine would appear as shown in the flow chart of Figure 4, in which time runs from top to bottom of the figure.
In this example the applet requests to open the file to write 4000 bytes. The access control list (ACL) is queried by the application engine. The request is approved, and the file is opened. When 3500 bytes are added, the write to the file succee~. An attempt to write a further 1000 bytes does not succeed and they are not written, since they exceed the application engine's stored access rights (4000 bytes) for the applet over the file.
Thus it may be seen that this invention provides a method by which applets can access files stored on persistent storage media, or can access other computer system resources in an open system that would otherwise be protected, in a secure manner, without concern that a rogue applet has adopted the domain of another applet, or concern that a file can be stolen or corrupted. The method also provides protection against overrunning the storage media due to excessive file size production. Yet at the same time it allows more sophisticated functioning of a computer connected to an open system, since files and other resources at, controlled by or connected to the local computer can be used in processing of applets.
A person understanding this invention may now conceive of alternative structures and embodiments or variations of the above. All those which fall within the scope of the claims appended hereto are considered to be part of the present invention.
FIELD OF THE INVENTION
This invention relates to the field of computer networks and in particular to a method of processing computer applets in a secure manner.
BACKGROUND TO THE INVENTION
With the advent of object based programming, it has become possible to transmit applets via a network such as the internet to various computers connected to the network. An applet is a small self-contained application program which can cause a computer to perform a particular function, and contains both instructions for the computer to operate and data which is to be processed in its operation.
Various programming languages have been designed to create applets, such as Telescript, SafeTCL, Java, CyberAgents and ClearLake Agents. By the use of interpreters, the various applets can be hardware independent, that is, the same applet can be received and processed by computer hardware having different operating systems. For example, the same applet would be able to be received and processed by a MacIntosh operating system and by one of the Microsoft Windows operationg systems on an Intel processor based (e.g. IBM
personal computer) type operating systems.
It has been speculated that the programs and data that computers that receive applets use would provide all that a computer would need, to be able to be fully functional and which would result in a significantly less expensive computer than at present.
This is because the computer would be expected to use the network as a mass storage repository of programs and data. Programs would be paid for on a use basis, rather than on an up-front-payment and unlimited use basis.
However this presupposes that a user would be prepared to allow mass storage to be out of his control to store critical data, specially written programs, etc. For the reason of security, it had been believed to be desirable and/or necess~ry to provide a local mass storage associated with each or with most computers.
With the storage of data on a local mass storage device, the problem of security arises in relation to the reception from the network of applets, since those applets could access and transmit or corrupt files.
lo The security problem has been handled in one of two ways.
The first is to restrict the use of applets to a closed or managed system, wherein software components can be given domain names and all possible execution sites can be populated with lists of allowed domains.
For example, in the CyberAgents program, domains are used to control execution and security on remote sites.
A domain is a jurisdiction group of applets that share access rights.
The second way of handling security is to isolate the applets from important system resources, as noted earlier above. Applets received from an uncontrolled system network such as the internet have been restricted from being able to access mass storage devices, and have been relegated to providing fancy graphics and to providing a graphical user interface for client-server computing. Programs to create applets in open uncontrolled systems, are e.g. Telescript, SafeTCL
and Java. For example, Java can cause a computer to display a window and provide the content of the window and play sounds, but cannot write to the computer disk drive.
While use of either of these schemes produces the required security to ensure that rogue applets do not cause damage to a computer's resources, such as the files, they also place restriction on the usability of open system mobile applets. If a downloaded applet cannot access the disk drive to provide persistent local storage for the user, the usability of applets written using such an isolation scheme is very limited.
Operating systems approach security by providing usage rights over directories and files. By assigning the applet application engine to a user group, the applets executed by the application engine are restricted to accessing those files available to the application engine itself. While this provides security to other file system files outside the reach of the application engine, it does not provide security between applets. Similarly, some applet application engines, such as Sun's HotJava, provide access control lists.
These lists specify which subset of the application engines accessible files can be accessed by applets.
This provides extended security, but does not solve the problem of providing security to data between applets.
HotJava also specifies a method by which access to files can be granted to applets through the use of a dialog box to the user of the applet, wherein the user is required to enter a security authorization.
This provides greater security between applets but is intrusive and requires that the user understand the sensitivity and origin (virtual ownership) of data in each file.
If the application engine can determine the source of the applet, access rights can be set according to certain rules. Java can detect if an applet originates within a firewall (a software barrier to outside access to a local (internal) network); the HotJava Browser allows different security rights to applets loaded on each side of the firewall. Read and write access can be granted to internal applications only.
General Magic's Telescript technology provides a generic set of authorities and permits. Agents within a region all contain the same authority - this is similar to the concept of user domains. Each Telescript agent has only one authority. Permits control the execution of instructions or the access and usage of a resource. Telescript does not specify how a Telescript place negotiates usage rights for a resource with an agent of a certain authority, or stores the access rights for each resource instance.
The term "persistent storage" will be used in this specification as a generic term for all media which store or carry files, data or programs which are to be protected, and can include, but is not restricted to electronic random access memory, floppy or hard disk drives, buses, etc.
SUMMARY OF THE INVENTION:
The present invention provides secure access to persistent storage for distributed applet code within an open uncontrolled computing environment. It protects files from unauthorized use by unknown mobile applets while still providing access to the file system for these applets. This involves negotiating access rights for the unknown applet.
In accordance with an embodiment of the invention, a method of processing an applet is comprised of storing a file in a persistent storage medium (PSM), the file including an access control list, and transmitting an applet from a server, the applet including at least one of applet identification data and a private key encrypted domain identifier and public key pair, a maximum file size indicator, and a specification of required storage operations, receiving the applet by an application engine, and in the event the domain identifier is included in the applet, decrypting the domain identifier using the public key, checking at least one of the applet identification data and S decrypted domain identifier against the access control list for a match, and in the event a match is found, allowing the operations specified in the applet on a file stored in a persistent storage medium which allow access to the applet as specified in the file access control list.
In accordance with another embodiment, a method of providing an applet is comprised of receiving applets in an application engine, the applets comprising specifications of operations to be performed, and some of the applets being comprised of at least one of applet identification data and private key encrypted domains, processing the applets to an extent to which access to files contained in a persistent storage medium is not required, in the event applets are comprised of private key encrypted domains, decrypting the domains, checking at least one of the applet identification data and decrypted domains against a control list, and processing the applets which the at least one of applet identification data and decrypted domains match entries in the control list to access the files contained in persistent storage medium required by the applets.
In accordance with another embodiment, a method of processing an applet is comprised of storing an access control list which contains an identity of applets or domains that can have access to files stored in a persistent medium, and giving access to the access control medium by applets which contain an identity or a domain corresponding to an entry on the list.
In accordance with another embodiment, an applet application engine is comprised of an access control list, the engine and list stored in a memory of a computer, and apparatus for providing an applet comprising an identification of at least one of an applet identifier and a domain for comparison with the list and determination of a match, and apparatus for allowing access to an otherwise protected computer resource in the event of the match.
BRIEF INTRODUCTION TO THE DRAWINGS
A better understanding of the invention will be obtained by considering the detailed description below, with reference to the following drawings, in which:
Figure l is a block diagram of a network on which the present invention can be implemented, Figure 2 is a block diagram of a computer used in the network of Figure l, on which the present invention can be implemented, Figure 3 is a illustration of a representative applet which is used in the present invention, and Figure 4 illustrates a representative method of operation of the invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
Figure l illustrates an open and uncontrolled network, and is comprised of a server l, which interfaces a network 3, to which various computers 5 are or can be connected. The network 3 can be a wide area network, the internet, a telephone network, etc.
In operation, the server l applies applets to the network 3 for reception by one or more computers 5.
A computer which receives the applet, which is a complete object based program, processes it using the data contained therein. As noted above, in prior art open systems the applet was restricted from being able to access persistent storage.
Figure 2 illustrates the basic architecture of a representative computer system 5. A microprocessor 7, random access memory 8 (RAM), a keyboard 9, a network interface device 10 such as a modem, a hard disk drive 11 persistent storage device, and a display subsystem 12 to which a display 13 is connected, are connected to, or are in communication with, a bus 14.
In addition, random access memory 16 (RAM), which may be part of or merged with RAM 8, is connected or in communication with bus 14. RAM 16 contains a applet application engine, which is comprised of an interpreter for the particular applet language used, and a software command structure to cause microprocessor 7 to process the applets. For example, for the Java language, an applet application engine can be HotJava, available from Sun Microsystems Inc..
In operation of a prior art system, applets are received from the server 1 via the network 3 and network interface 10, are interpreted by microprocessor 7 using the interpreter in application engine 16 and the interpreted instructions are processed by microprocessor 7 to cause the display subsystem 12 to display graphics, etc. on display 13. The application engine will not access persistent storage media such as the hard disk drive 11, to avoid corruption etc. of files as described therein, and therefore cannot use data or other programs stored therein. Such a system is thus considerably limited.
In accordance with the present invention, the application engine 16 contains a public key decryption program 18 and an access control list 20 of authorized applets and/or domains which may be allowed to access persistent storage media.
In accordance with the present invention, when applets are received via the network interface, access rights to the persistent storage media are negotiated using the application engine 16. Arc~cc rights need not be restricted and access negotiated only to persistent storage media; any resource of the computer or S controlled or accessed by the computer can be restricted and access thereto negotiated.
~ceCc rights are negotiated by (a) authentication; the applet application engine verifies the identity or domain of all applets requesting access to persistent storage;
(b) usage rights negotiation; this involves verifying the applet's authority to read, write or append to a file. Methods to ensure that an applet has access rights to a particular file are described below.
It should be noted that in an open uncontrolled system, central authentication or domain management is not possible. For this reason, the negotiation of access rights is conducted between the application engine, the file and the applet;
(c) quality of service; maximum disk usage for an application is set. Limits are preferably placed on access rights which give the bounds within which the granted resource may be used.
By acting as an intermediary between the unknown applet and the disk resource, the application engine negotiates and enforces access rights. For disk files, this involves acting as an intermediary for all disk actions. If a target file will grow beyond a predetermined size, a write can be denied or the user can be asked for override permission, which effectively allows growth of the access rights by an incremented amount. The application engine can specify an override zone, above which the access right will not be allowed to grow.
As a safety meçh~nism, file versioning may be provided by the application engine to ensure that any modifications or deletions to files can be recovered in the event of damage to the file system. Access control list 20 is used by the application engine to specify what default and file specific access rights are for individual persistent storage objects (files).
Each applet should be associated with a server site that uniquely identifies the applet. If loaded lo from the World Wide Web, for example, this identity can be the universal resource locator (URL) of the applet.
When an applet creates a new file, it can specify which applets have which rights on the file.
Domains are groups of applets which share access rights. Using private key encryption and an encrypted message supplied by the applet, the application engine can ensure that an applet belongs to a specified domain. Applet files contain a header which contains the access control list for a set of domains and public keys for each domain.
Figure 3 illustrates an applet 22, which contains a payload 24 comprised of an object based application program including data, and a header 26.
The header 26 contains a public key or keys 28, and an 2s application control list 30. It also contains an identification of the applet (e.g. the URL if used on the World Wide Web), which can be encrypted at the server using a private key, for decryption under control of the application engine 16 using a public key 28. The header also contains an encrypted set of domains e.g.
domain messages, which can be decrypted using a public key 28.
An applet can belong to more than one domain at a time. It is the responsibility of the domain owners to ensure that the private key used to generate encrypted domain authentication messages is kept secure As noted above, the encrypted message may encrypt the applet identification using the private key This ensures that the encrypted message has not been copied from another applet in an attempt to borrow that applet's domain capabilities. Any attempt to clone the server applet to another machine and then be able to read domain owned files would then cause the encrypted message to not match the applet identification, invalidating the applet's domain within the application engine.
A combination of access methods is preferably used to provide secure persistent storage access to applets. Both applet identification and preferably domains are implemented as keys within the access control list for a file.
The language classes for file access in the application engine 16 for the particular language used, e.g. Java should be amended to allow access to the file system based on the applet's identification and domain.
Applets should be modified as indicated above with respect to Figure 3 to optionally include their domain, and by the use of public key encryption thereof and/or their identification. Each file with access rights associated with it is contained in the access control list 20 (Figure 2) in a file stored in RAM 16 accessible by the application engine, e.g. a browser program. The application engine retained in RAM 16 negotiates access rights for each loaded applet. Access rights contain quality of service information that defines how each resource can be accessed, including maximum size changes. Each change to the file system is checked to see if it would violate access rights. This includes the right to access, change or create a file and limits on the size of changes.
The structure of the access control list is preferred to be:
<Filename:... >
<<AccessMode,...>:<IDorDomain,...>;...>
where:
Filename Contains one or more file names, each of which may contain wild-cards lo Acc~c~sMo~e Is one of Read, Write, Append, Delete, NewFile, List, Query, (MMaxSize:x) IDorDomain Is either a URL specifying an applet, or a (DomainName:publicKey) pair For example, an entry where all files in the "/public" directory are readable, "/private" can have new files created by applet, URL
"http://www.foo.bar/applet.class" and applets of domain "MyDomain" have write access to the file "/private/foo.bar" with add mode set to 5000 bytes, could appear as:
/public/*
Read : *
/private/*
NewFile : *
/private/foo.bar Write, (MaxSize:5000) :
http://www.foo.bar/applet.class; (MyDomain: 987654321) A message send within the application engine would appear as shown in the flow chart of Figure 4, in which time runs from top to bottom of the figure.
In this example the applet requests to open the file to write 4000 bytes. The access control list (ACL) is queried by the application engine. The request is approved, and the file is opened. When 3500 bytes are added, the write to the file succee~. An attempt to write a further 1000 bytes does not succeed and they are not written, since they exceed the application engine's stored access rights (4000 bytes) for the applet over the file.
Thus it may be seen that this invention provides a method by which applets can access files stored on persistent storage media, or can access other computer system resources in an open system that would otherwise be protected, in a secure manner, without concern that a rogue applet has adopted the domain of another applet, or concern that a file can be stolen or corrupted. The method also provides protection against overrunning the storage media due to excessive file size production. Yet at the same time it allows more sophisticated functioning of a computer connected to an open system, since files and other resources at, controlled by or connected to the local computer can be used in processing of applets.
A person understanding this invention may now conceive of alternative structures and embodiments or variations of the above. All those which fall within the scope of the claims appended hereto are considered to be part of the present invention.
Claims (12)
1. A method of processing an applet comprising:
(a) storing a file in a persistent storage medium (PSM), the file including an access control list, (b) transmitting an applet from a server, the applet including at least one of applet identification data and a private key encrypted domain identifier and public key pair, a maximum file size indicator, and a specification of required operations, (c) receiving said applet by an application engine, (d) in the event the domain identifier is included in the applet, decrypting the domain identifier using the public key, (e) checking said at least one of said applet identification data and decrypted domain identifier against the access control list for a match, and (f) in the event a match is found, allowing said operations specified in the applet on a file stored in a persistent storage medium which allow access to the applet as specified in the file access control list.
(a) storing a file in a persistent storage medium (PSM), the file including an access control list, (b) transmitting an applet from a server, the applet including at least one of applet identification data and a private key encrypted domain identifier and public key pair, a maximum file size indicator, and a specification of required operations, (c) receiving said applet by an application engine, (d) in the event the domain identifier is included in the applet, decrypting the domain identifier using the public key, (e) checking said at least one of said applet identification data and decrypted domain identifier against the access control list for a match, and (f) in the event a match is found, allowing said operations specified in the applet on a file stored in a persistent storage medium which allow access to the applet as specified in the file access control list.
2. A method as defined in claim 1 including terminating performing of said operation specified in the applet in the event said operation would result in a file size in the persistent storage medium that exceeds said maximum file size indicated in the applet.
3. A method as defined in claim 1 including not performing said operation in the event a match is not found.
4. A method of processing applets comprising:
(a) receiving applets in an application engine, said applets comprising specifications of operations to be performed, and some of said applets being comprised of at least one of applet identification data and private key encrypted domains, (b) processing said applets to an extent to which access to files contained in a persistent storage medium is not required, (c) in the event applets are comprised of private key encrypted domains, decrypting said domains, (d) checking said at least one of said applet identification data and decrypted domains against a control list, and (e) processing those of said applets of which said at least one of applet identification data and decrypted domains match entries in said control list to access said files contained in persistent storage medium required by said applets.
(a) receiving applets in an application engine, said applets comprising specifications of operations to be performed, and some of said applets being comprised of at least one of applet identification data and private key encrypted domains, (b) processing said applets to an extent to which access to files contained in a persistent storage medium is not required, (c) in the event applets are comprised of private key encrypted domains, decrypting said domains, (d) checking said at least one of said applet identification data and decrypted domains against a control list, and (e) processing those of said applets of which said at least one of applet identification data and decrypted domains match entries in said control list to access said files contained in persistent storage medium required by said applets.
5. A method of processing an applet comprising storing an access control list which contains an identity of applets or domains that can have access to files stored in a persistent medium, and giving access to said persistent medium by applets which contain an identity or a domain corresponding to an entry on the list.
6. A method as defined in claim 5 including using an application control engine stored in a computer to inspect said applets, check said access control list and process said applets identified on said access control list to operate on a file stored in said access control medium.
7. A method as defined in claim 6 including checking an applet for a file size limitation specification carried by said applet, and failing to operate on said file in the event operation specified by the applet would result in a file size in excess of said file size.
8. A method as defined in claim 5 in which at least one of said identity and domain carried by the applet is private key encrypted and includes a corresponding public key, and including the steps of decrypting to authenticate said at least one of said identity and domain using the public key, said giving access step being carried out only in the event the decrypted said at least one of said identity and domain is authenticated.
9. An applet application engine comprising an access control list, said engine and list stored in a memory of a computer, and means for providing an applet comprising an identification of at least one of an applet identifier and a domain for comparison with said list and determination of a match, and means for allowing access to an otherwise protected computer resource in the event of said match.
10. The invention of claim 9, in which said computer resource is a persistent storage medium.
11. The invention of claim 9 further including a public key decryption means, said applet comprising a private key encrypted identifier or domain and public key, for decryption by said decryption means.
12. A computer software applet comprising a private key encrypted authentication code defining a domain of said applet.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US63880796A | 1996-04-29 | 1996-04-29 | |
| US08/638,807 | 1996-04-29 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2202118A1 true CA2202118A1 (en) | 1997-10-29 |
Family
ID=24561525
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002202118A Abandoned CA2202118A1 (en) | 1996-04-29 | 1997-04-08 | Protected persistent storage access for mobile applications |
Country Status (3)
| Country | Link |
|---|---|
| CA (1) | CA2202118A1 (en) |
| DE (1) | DE19717900C2 (en) |
| GB (1) | GB2312767A (en) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| IL123512A0 (en) | 1998-03-02 | 1999-03-12 | Security 7 Software Ltd | Method and agent for the protection against hostile resource use access |
| US6223287B1 (en) | 1998-07-24 | 2001-04-24 | International Business Machines Corporation | Method for establishing a secured communication channel over the internet |
| CN1227858C (en) * | 1998-08-21 | 2005-11-16 | 维斯托公司 | System and method for enabling secure acess to service in computer network |
| CA2256934C (en) * | 1998-12-23 | 2002-04-02 | Hamid Bacha | System for electronic repository of data enforcing access control on data retrieval |
| GB0012791D0 (en) * | 2000-05-25 | 2000-07-19 | Breakertech Inc | Mobile node-lock |
| WO2003003173A1 (en) | 2001-06-26 | 2003-01-09 | Sealedmedia Limited | Digital rights management |
| JP2004302516A (en) * | 2003-03-28 | 2004-10-28 | Ntt Docomo Inc | Terminal device and program |
| US7546956B2 (en) | 2004-04-30 | 2009-06-16 | Research In Motion Limited | System and method of operation control on an electronic device |
| US8045958B2 (en) | 2005-11-21 | 2011-10-25 | Research In Motion Limited | System and method for application program operation on a wireless device |
| DE602006006787D1 (en) | 2006-02-27 | 2009-06-25 | Research In Motion Ltd | Method for personalizing a standardized IT policy |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5414844A (en) * | 1990-05-24 | 1995-05-09 | International Business Machines Corporation | Method and system for controlling public access to a plurality of data objects within a data processing system |
| DE69323926T2 (en) * | 1992-05-15 | 1999-09-30 | Addison M Fischer | Method and device for the security of a computer system with program authorization data structures |
-
1997
- 1997-04-08 CA CA002202118A patent/CA2202118A1/en not_active Abandoned
- 1997-04-28 DE DE19717900A patent/DE19717900C2/en not_active Expired - Fee Related
- 1997-04-28 GB GB9708608A patent/GB2312767A/en not_active Withdrawn
Also Published As
| Publication number | Publication date |
|---|---|
| DE19717900C2 (en) | 2000-05-25 |
| GB9708608D0 (en) | 1997-06-18 |
| DE19717900A1 (en) | 1997-10-30 |
| GB2312767A (en) | 1997-11-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Wright et al. | NCryptfs: A Secure and Convenient Cryptographic File System. | |
| US7330981B2 (en) | File locker and mechanisms for providing and using same | |
| US6272631B1 (en) | Protected storage of core data secrets | |
| US8959593B2 (en) | System for providing mobile data security | |
| US8341406B2 (en) | System and method for providing different levels of key security for controlling access to secured items | |
| US9461819B2 (en) | Information sharing system, computer, project managing server, and information sharing method used in them | |
| US8307067B2 (en) | Protecting encrypted files transmitted over a network | |
| JP4777651B2 (en) | Computer system and data storage method | |
| EP1860590B1 (en) | Posture-based data protection | |
| US10666647B2 (en) | Access to data stored in a cloud | |
| CN109923548A (en) | Method, system and the computer program product that encryption data realizes data protection are accessed by supervisory process | |
| EP1320015A2 (en) | System and method for providing manageability to security information for secured items | |
| JP2003228519A (en) | Method and architecture for providing pervasive security for digital asset | |
| WO2003050662A1 (en) | Software safety execution system | |
| JP2003228520A (en) | Method and system for offline access to secured electronic data | |
| EP0972234A1 (en) | Method and apparatus for providing security for servers executing application programs received via a network | |
| US6990582B2 (en) | Authentication method in an agent system | |
| JP3917125B2 (en) | Document security system | |
| CA2202118A1 (en) | Protected persistent storage access for mobile applications | |
| JP4084971B2 (en) | Data protection apparatus, data protection method and program used in electronic data exchange system | |
| JPH09251426A (en) | File ciphering system and its control method, and cipher file reception system and its control method | |
| US8321915B1 (en) | Control of access to mass storage system | |
| JP3905170B2 (en) | Processing system and client device | |
| JP2005309846A (en) | Database protection system | |
| JPH10105470A (en) | Method for authenticating file access |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |