Java virtual machine
Manufacturing cheap, resilient, and stealthy opaque constructs
POPL '98 Proceedings of the 25th ACM SIGPLAN-SIGACT symposium on Principles of programming languages
Core Java 1.1: volume II—advanced features
Core Java 1.1: volume II—advanced features
Inside Java 2 platform security architecture, API design, and implementation
Inside Java 2 platform security architecture, API design, and implementation
Implementing remote procedure calls
ACM Transactions on Computer Systems (TOCS)
Introducing trusted third parties to the mobile agent paradigm
Secure Internet programming
Java 2 Network Security
On the (Im)possibility of Obfuscating Programs
CRYPTO '01 Proceedings of the 21st Annual International Cryptology Conference on Advances in Cryptology
Zero-Knowledge and Code Obfuscation
ASIACRYPT '00 Proceedings of the 6th International Conference on the Theory and Application of Cryptology and Information Security: Advances in Cryptology
Software DisEngineering: Program Hiding Architecture and Experiments
IH '99 Proceedings of the Third International Workshop on Information Hiding
Non-Interactive CryptoComputing For NC1
FOCS '99 Proceedings of the 40th Annual Symposium on Foundations of Computer Science
Access control for ad-hoc collaboration
Access control for ad-hoc collaboration
| Hi-index | 0.00 |
A security threat that affects the Java environment (as a typical environment where code is made available to the user machine) is the reverse-engineering and code-understanding of the architectureneutral bytecode format. A natural protection strategy is to hide parts of the execution in trusted locations (e.g., servers). However, the implementation and automatization of such an approach (beyond the abstract idea) is a challenging problem. In this paper, we present a novel software protection strategy and its automatization (implemented architecture) which materialize the above idea. It is employed in protecting the binary source of Java class files. Our software protection strategy partitions "programmer selected" classes of an application into server classes and client classes. Server classes contain the actual class code and run only on trusted systems (which we call servers but they can be other dedicated machines). Client classes, on the other hand, are assumed to perform most of the task (but the sensitive part) and execute on user systems; they must interact with their corresponding server class in order to execute the sensitive code and provide the behavior of the original class. We propose and implement DISSECT (DIStribution for SECurity Tool), an architecture based on the above partitioning (dissection) strategy, for Java 1.1. The tool relieves the developers from actually writing distributed applications by distributing the application automatically, according to designated sensitivities of application portions. We note that the remote execution of classes may increase the overhead. Thus, we have conducted initial experiments to understand the impact of partitioned classes on performance.We report initial performance results which show the overhead and demonstrate when it is low or non-existing, when it is high, and when we actually gain performance by partitioning.