Chapter 2 Related Work
2.1 Software Protection Schemes
2.1.2 Software Protection and Simulation on Oblivious RAMs
A machine is oblivious if the sequence in which it accesses memory locations is equivalent for any two inputs with the same running time. In this paper [Goldreich96], the key problem of learning about program from its execution has been formulated, and the problem of software protection is reduced to the problem of on-line simulation of an arbitrary program on an oblivious RAM. It provides theoretical treatment of software protection.
It is showed that if the one-way functions exist, this software protection scheme is robust against a polynomial-time adversary who is allow to alter memory contents during execution in a dynamic fashion.
2.2 Java Language and Remote Method Invocation
Mobile code technology enables the code to be downloading dynamically from a remote server and executed in the local machine. Here we present the Java language, which is most popular mobile code technology in the current Internet environment.
The RMI (Remote Method Invocation) which enables cooperation between machines on the network in the Java environment is also discussed.
2.2.1 Java Language
Java applications, or applets, are different from ordinary applications in that they reside on the network in centralized servers. The network delivers the applet to your system when you request them.
The Java language changes the passive nature of the Internet and WWW by allowing architecturally neutral code to be dynamically loaded and run on a heterogeneous network of machines such as the Internet. Java provides this functionality by incorporating the following features into its architecture. These features make Java the most promising contender for being the major protocol for the
Internet in the near future.
2.2.2 Remote Method Invocation
Distributed systems require that computations running in different address spaces, potentially on different hosts, be able to communicate. The development of Remote Method Invocation (RMI)[Sun96a] enables software developers to create distributed Java-to-Java applications, in which the methods of remote Java objects can be invoked from other Java virtual machines, possibly on different hosts. With the RMI technology, a Java program can make a call on a remote object once it obtains a reference to the remote object, either by looking up the remote object in the bootstrap-naming service provided by RMI, or by receiving the reference as an argument or a return value.
The Java remote method invocation system described in this specification has been specifically designed to operate in the Java environment. While other RMI systems can be adapted to handle Java objects, these systems fall short of seamless integration with the Java system due to their interoperability requirement with other languages. For example, CORBA presumes a heterogeneous, Multilanguage environment and thus must have a language- neutral object model. In contrast, the Java language's RMI system assumes the homogeneous environment of the Java Virtual Machine, and the system can therefore take advantage of the Java object model whenever possible.
Chapter 3
The Proposed Authorization and Protection Model
As the speed of network transmission becomes faster and faster, many jobs tend to be processed by tightly connected computers. A network-computing environment can be established by the mobile code technologies. In this environment, the computational and storage resources may be spread on different locations instead of a single computer.
In mobile code systems, the software is composed of many applets. The applet is a piece of software that can be downloaded dynamically from the remote machine and executed in the local machine, and the cooperating of these applets can process the job. In the environment, an authorization and protection is proposed which provides security for the software by delegating some critical execution services to a trusted and protected party.
3.1 System Model
The execution of software can be viewed as the following three parts, incoming flow information, transformation process, and outgoing flow information. For an outgoing information, if the information flows through an applet, we can say that this
applet participates in the transformation process for the outgoing information.
Therefore, if we remove some applets that participate in the transformation process, the execution will be stopped without help of the missing applets.
3.1.1 The Proposed Protection Model
With the RMI (Remote Method Invocation) technology for Java language that enables cooperating of computers on the network, we proposed a model that protects the software with the help of a trusted, protected computational proxy servers instead of tamper-resistant hardware devices installed in the user’s environment. In this model, applets of the software is partitioned into general and privileged applets. The users can get only general applets and the privileged applets will be forced to be executed in a protected environment.
Trusted Computational
Proxy
User A pple t contr olling proce ss A pple t contr olling proce ss
c ommon applet pr ivilege d a pplet Global vie w of
the sof twa re
Figure 3.1 The proposed protection model
The trusted computational proxy provides computation services for privileged applets. Only a trusted proxy has the capability to get privileged applets and execute them. The proxy executes the applets and returns the result to the user. Since some of the applets are forced to be executed in the proxy server, an unauthorized user cannot benefit from the software with only part of the applets. There can be more than one proxy, and each proxy executes part of privileged applets. Then the compromise of one proxy will not leak all privileged applets. In the proposed model, applets to be downloaded are encrypted by applet keys, and the applet keys for each applet are different. These keys are only available to trusted proxies or authorized users.
System Components
In this model, there are six major components:
Software Vendor: The company who develops the software.
Certificate Authority: The party who issues public and private keys.
Software Authentication Center: An accredited organization that authenticates the software developed by software vendors, and signing legitimate parts of the software.
Applet Server: The server who stores applets provided by software vendors. When a host wants to execute an applet, it first downloads the applet from an applet server.
Trusted Computational Proxy: The server that provides computational services of privileged applets for users.
User: The user who uses the software.
Software Authentication
Center
User Trusted
Proxy
Software Vendor
Applet Server
Network
Certificate Authority
Figure 3.2 System components
3.1.2 Licenses for the Software
In our model, there are two kinds of licenses, publication license and execution license. The publication license gives the right for software vendor to distribute an applet and the execution license gives the right for user or proxy to download and execute an applet.
Publication license
For each applet, there is a publication license associated with it. The publication license is issued and signed by software authentication center, and every applet provided by software vendor, which must have a legal publication license.
A publication license consists:
1. Serial number
2. Software vendor information
3. Software authentication center information 4. Applet information (ID, version)
5. Message digest of the applet (optional) 6. Issuing and expiration time
7. Other information
The license is signed by the center’s private key. When a user or a proxy downloads an applet from the applet server, it verifies the applet by the center’s public key and also checks the message digest and expiration time of the applet.
The message digest of an applet is optional. For some applets, we give the message digest to an authorized user in another way instead of placing it in the publication license. This helps to reduce unauthorized use for the applets. We will discuss this later.
When the software vendor releases a new applet, it first sends it and the related information about the applet (for example, specification or source code) to the
software authentication center. The software authentication center checks the applet, and if there is no problem with it, the center issues a publication license of this applet and sends back to software vendor.
For some applets, sometimes it is not easy to verify them in the first time. In this case, the center can set a shorter expiration time in the publication license for such an applet. It issues new licenses periodically to the software vendor and will stop the process if any problem of the corresponding applet found in the future.
Then the software vendor updates new publication licenses on all applet servers see Figure 3.3. The expiration time for each publication license depends on the policy for the software authentication center. Generally, longer expiration time can be assigned if an applet from a software vendor is more trusted or easier to be verified.
Software
Figure 3.3 Publication license updating
Execution license
The user or proxy must get an execution license to execute the corresponding applet. The execution license is issued and signed by software vendor.
The execution license consists:
1. Serial number
2. Execution capabilities for applets of the software
3. Delegation capabilities for applets of the software (For user only) 4. User or proxy’s information
5. Software vendor information 6. Issuing and expiration time 7. Other information
The execution capability of an applet determines whether a user or a proxy can download the applet. The delegation capability determines whether a user cans delegation the execution of an applet to the proxy. Delegation here means delegate the execution to a trusted party if a user cannot execute it directly. If the user has the execution capability of an applet, he can get some extra information of the applet from software vendor, for example, applet key or message digest of the applet. To execute the privileged applets that have to be executed in the proxies, a user must have the delegation capability for these applets.
The execution and delegation capabilities for a user dependent on how many applets the user has been authorized to use. If the user is interested in only some features of the software, software vendors can issue the license with the capabilities for only the applets providing these features.
3.1.3 Using the Software
The user can purchase the execution license to the software he interested in from the software vendor. Once the user received the execution licensed offered by software vendor, he can begin to use the software. In this section, we describe the related issues when a user is using the software.
Applet Downloading
In the mobile code system, the applets are dynamically downloaded from a remote server and executed in local machine. Applet downloading is necessary before execution if there are no previously cached applets in a proxy or user’s computer. The applet server controls the access for those applets to be downloaded.
The client (proxy or user) sends the request of the applets needed to be execution associated with his execution license. If the license consists of the execution capability with respect to the applet and the license is valid, the request will be accepted, and otherwise it will be denied.
When a user or a proxy received an applet from the applet server, he can decrypt it with the corresponding applet key. The verification process verifies the validity of an applet, which includes the correctness and the effectiveness of the downloaded applet.
Applet Server
applet PL applet PL
applet Decrypt applet
Verif y PL Verif y applet
Client
downl oad applet
system resources Virt ual Machine
reques t applet
Figure 3.4 Applet downloading and verification
Execution of the software
After a user downloads the applets from an applet server, he can begin to execute them. Since privileged applets are forced to be executed by the proxies, therefore the user has to bind these applets first before execution. In the binding phase, the user sends his execution license to the proxy server he wants the execution to be delegated. Both user and proxy mutually authenticate the execution licenses with
each other. The execution then proceeds by executing the applets corresponding to the capabilities listed in user’s execution license.
If there are more than one proxy participated in the execution, the user will be required to explicitly make connections to each of them and authenticate with each other.
At the first time for using the software, the user asks to software vendor for a list of available proxies. Then he chooses the proxy for computational service and register himself at this proxy. Registration for execution licenses will be discussed in the next section.
3.1.4 License Registration and Revocation
Once an execution license has been issued to a user, the user can use the software with the capabilities listed in the license. However, sometimes the software vendor may wish to revoke the license for a user if illegal behavior of the user has been found.
Moreover, with the registration and revocation, the license can be easily expired by the number of executions. The proxy records the number of executions for the user, and if it exceeds the limitation described in the user’s execution license, further execution will be refused.
Registration
Registration is required for the first time when a user wants to use the service provided by a proxy. The execution license will only be valid for the proxy if there is a corresponding registry ( is software vendor’s private key) in
the proxy. When a user wants to delegate the execution to a proxy, the proxy checks both the user’s execution license and the registry. The license without a corresponding registry will be considered as invalid. The following is the steps for registration:
Steps 1: User sends a request associated with his execution license to software vendor for registration at a proxy.
Step 2: Software vendor checks the validity for user’s license. Go to Step 3 if the user’s license is valid otherwise stop.
Step 3: Software vendor sends a message (signed by software vendor) to the new proxy for adding user’s record at the proxy, where
is the serial number for the license.
Step 4: Software vendor updates its own registry for the user.
Revocation
To revoke an execution license in a proxy, the software vendor simply tells the proxy to remove the registry for the user and then removes the registry located in the software vendor itself. Then the user’s execution license will be revoked because no
registries can be found on the proxy.
3.2 Illicit Dissemination and Unauthorized Use of the Software
A serious problem in software protection is the illicit dissemination of the software. As we mentioned earlier, such problem is even more serious in mobile code systems. Although the applets in the applet server are encrypted, an authorized user who gets the applet may decrypt and illicitly disseminate it to another unauthorized user. Moreover, a trusted computational proxy may also be compromised. The more applets a user can get, the more information he will be able to gain from the software. However, it is very difficult to control the software once it has been illicitly distributed, since the software is just a binary sequence of data.
Common protection schemes with authentication processes embedded in the software failed to stop the problem from smart crackers. Therefore something must be done to reduce the problem that the applets of authorized users or proxies illicitly disseminated to unauthorized users.
3.2.1 Discouraging Illicit Dissemination
Common methods preventing or reducing such problem use the technique of digital watermarking. With this technique, software vendor can hide some embedded data into the software for the purpose of identification and copyright, in
order to discourage unauthorized copying and dissemination. Many papers have been proposed for this area [Bender96] [Berghel96] [Brassil95] [Choudhury94]. It is useful for tracing the software that has been illicitly distributed. When the uniquely marked ownership for a consumer is embedded in the software, he tends to be unwilling to distribute the software to the network because the copyright violation may be found by software vendor.
3.2.2 Discouraging Unauthorized Use
Here we propose a scheme to reduce the problem of software piracy in another point of view by discouraging unauthorized users to use the illicitly disseminated software instead of discouraging illicit dissemination.
The modified version of applet is be harmful to users executing it, since it may contain malicious code such as a Trojan horse or a Virus. The malicious code accessing user’s system resources such as the file system, the CPU, the network, and the graphics display may cause unpredictable effects from stealing user’s privacy to damaging resources in user’s environment. Therefore, users usually refuse to execute unknown or untrusted code from the network. In JDK 1.1 (Java Development Toolkit)[Sun96b][Gong97], the code signing feature is provide and the user who downloads the applet can verify the code signed by the author. If the applet is not trusted, execution will be restricted in a sandbox with only limited system resource provided, as shown in Figure 3.5.
sandbox
valuable resources JV M
Internet
rem ote code
“trusted”
others
local code
Figure 3.5 JDK 1.1 Security Model
Based on this nature, our proposed scheme discourages the unauthorized use in mobile code systems by preventing unauthorized users to verify the applets downloaded from the network. In Figure 3.5, the user tries to download the applets from the applet server without an execution license will be refused. However, an authorized user may disseminate the applets he has to the unauthorized user. We apply the technology of undeniable signature [Chaum90] to make an authorized user not been able to proof that his applet is valid to other users. The software vendor or software authentication center cannot deny those applets signed by them and has to be responsible for the applets if any problems due to the applets are found in the future.
Unauthorized user
User Applet Server
?
Access deniedDownload and verif y the applet
applet will be unverif ible
Sof tware Com pany get an
execution license
Figure 3.6 discouraging the unauthorized use of software
Nontransferable Message Digest
In our scheme, a user cannot convince to another user that the message digest he has is valid. The unauthorized use of software is discouraged by the nontransferable message digest, which applies the undeniable signature scheme proposed by [Chaum90]. The protocol for requesting a nontransferable message digest is shown in Figure 3.7. A large prime, p, and a primitive element, g, are made public, and used by a group of signers. The signer has a private key, x, and a public key,
. For a message m, the signer first computes = . A user has to get the signature with his execution license. If he has the execution capability for the applet, he can get the corresponding message digest from the signer.
User Signer
=
=
confirm that choose random number a and b (less than p)
=compute
verify EL
= −
compute
Figure 3.7 Nontransferable message digest
3.3 Security analysis
In this model, the software may be compromised if 1. The proxy server is compromised
If a proxy is compromised, all privilege applets in this proxy will be also compromised. So a proxy has to be trusted by the software vendor and has to be secure from been cracked. A proxy can be software vendor itself or another trusted party. There can be several proxies, and each proxy owns execution licenses for a part of privileged applets. Such that the software can be secure if not all proxies are compromised.
2. User can reconstruct the protected part of applets successfully.
Although some privileged applets are executed in the proxy and other applets executed by user have to dependent on the other privileged applets, a user still can try
Although some privileged applets are executed in the proxy and other applets executed by user have to dependent on the other privileged applets, a user still can try