Addressing Security Issues in Programming Languages for Mobile Code
1 Department of Information & Communication Systems, University of the Aegean,
Research Unit, 30 Voulgaroktonou St., Athens GR-11472, GREECE
tel: +30-1-6456688, fax: +30-1-6448428, email: (sgritz, jiliad)@aegean.gr
2 Department of Informatics, Technological Educational Institute (T.E.I.) of Athens,
Ag.Spiridonos St., Aegaleo, GR-12243, GREECE
tel: +30-1-5910974, fax: +30-1-5910975, e-mail: email@example.com
A new era is dawning for the Internet; mobile code has evolved enough in order to deliver the quality of services that a remote user may ask for. However, security concerns arise when a user downloads and executes code from various sources of the Internet. These security issues are currently being dealt with, for most of the programming languages that offer the mobile code capability. Each programming language is surrounded by a different security scheme. In this paper, the potential security risks of mobile code are discussed and the details of the proposed security mechanisms of Java, Safe-Tcl and ActiveX are presented. Finally a comparison of the security models is given, centered upon the efficiency and flexibility of current implementations as well as upcoming extensions.
The concept of mobile code is not a new one. Mobile code consists of any software that travels on a heterogeneous network, crossing protection domains, and is automatically executed upon arrival at the destination. The explosion in the use of the World Wide Web we are currently experiencing coupled with the rapid evolution of the JAVA, Safe-Tcl and ActiveX programming languages has promoted the use of mobile code and at the same time raised some important security issues.
JAVA is a general-purpose class based, object-oriented language that has been developed and distributed by Sun Microsystems. JAVA programs written on one type of hardware or operating system can run unmodified on almost any other type of computer. In other words, JAVA applets can be executed within a JAVA enabled browser, running on virtually any operating system at the host machine of the user. However, security concern becomes especially strong in such an environment, since the presence of downloaded executable content makes the local computer vulnerable to a potential attack from the possibly untrusted source of the executable. JAVA has undergone major alterations with respect to both its content (libraries, capabilities, structure) and its security mechanisms during the past few years. Recent versions promise that through its new designed security mechanism, it provides a secure environment for downloadable executable content that under specific circumstances can make use of a system’s resources without compromising their availability and integrity.
Safe-Tcl, a special purpose language, is based on Tcl, a procedural, high-level, scripting language designed to be simple, portable, easily embeddable and extensible, and whose efficiency was a minor design issue. Safe-Tcl makes it possible for people to execute programs written in the Tcl language without knowing their origin or trustworthiness. It deals with potential security problems by restricting the behavior of programs so that they have fewer capabilities than the users who invoked them. According to Tcl’s designer J.Ousterhout, the proposed Safe-Tcl security model has two particular strengths: It separates untrusted code from trusted, with clear and simple boundaries between environments having different security properties, and provides mechanisms for implementing a variety of security policies.
ActiveX is a set of technologies that integrates software components in a networked environment using a variety of programming languages. It is not a language itself. ActiveX has been developed by Microsoft. It provides a large variety of functions in supporting the development of integrated network applications. The security scheme it uses is mainly based on the use of digital certificates. This security scheme relies on the existence and interoperation with a Trusted Third Party infrastructure; the latter is responsible for generating, revoking and distributing public keys and digital certificates to ActiveX software developers. Digital signatures can form a solid basis for the implementation of a security scheme for mobile code. However, complimentary functions and services have to be delivered by such a security scheme in order to provide a complete security solution. ActiveX lacks these functions and is therefore vulnerable to attacks. The open architecture of ActiveX allows for adjustments to the security scheme it uses, so it may evolve to be a secure environment for mobile code.
This paper addresses the security problems associated with JAVA, Safe-Tcl and ActiveX programming languages and provides some solutions for them. In section 2, the problems that would arise when running untrusted programs without providing a secure environment are investigated. Sections 3,5 and 7 provide a brief overview of the JAVA, Safe-Tcl and ActiveX programming languages focused particularly on the manner these languages address downloadable executable content security issues, and section 4,6 and 8 takes a closer look at the solution provided by the JAVA, Safe-Tcl and ActiveX security models. Current implementations as well as upcoming extensions of the three security models are presented in section 9, where their efficiency and flexibility are evaluated. Finally in section 10 concluding remarks are presented.
Security is the practice by which individuals and organisations protect their physical and intellectual property from all forms of attack and pillage. Computers and network configurations are providing new services and access levels; consequently new opportunities for unauthorised interaction and possible abuse arise.
Hostile applets are a kind of Web-embedded Java or ActiveX programs that perform such hostile activities against Web users, or Tcl scripts delivered via e-mail, that manage to harm the destination hosting machine or application, while being executed there. An important part of creating a secure and safe environment for a program to run in is identifying the assets that we are concerned about and providing the classes of potential attacks that may occur. Therefore any program can , :
attack the Integrity of the system. Deletion or modification of files, modification of currently used memory, killing processes and threads are some of the harmful consequences of such an attack.
violate the user’s Privacy. This can be achieved by sending private or company data to another system via the network.
limit system resources Availability. It may occupy system assets, making them unavailable for legitimate purposes, by creating thousands of windows, creating high priority processes hence using all CPU time, allocating large amounts of memory, using up all available file pointers.
achieve user’s Annoyance. It may display misleading information, causing the user to violate security without noticing, or annoy him by displaying obscene pictures on screen, or by playing unwanted sounds.
By implication, one has to carefully consider what system resources and to what extent may be made available to a downloaded executable content, from within a browser, without endangering the system’s security and at the same time guaranteeing the usefulness of the executable content.
JAVA is a general purpose, object oriented language inheriting its characteristics from C++ and Smalltalk. One of the major design goals of JAVA is portability. A JAVA program is portable not only in source code but also in compiled binary code. As a result, the same JAVA binary can be used on all processors. This is achieved through the JAVA Virtual Machine (JVM), a software program that simulates an imaginary virtual machine , . The virtual machine insulates the application from differences between underlying operating systems and hardware and ensures cross platform compatibility among all implementations of the JAVA platform.
The JAVA compiler compiles JAVA code to an architecture independent object file format, namely the class file. To execute JAVA class files, known as bytecodes, a runtime environment is needed which interprets these bytecode instructions of the virtual machine and executes the assembler instructions appropriate for the particular processor. This runtime environment is usually provided by a Web browser, into which the JVM is built.
JAVA’s security model is focused on protecting users from hostile applets downloaded from untrusted sources across a network. To accomplish this goal, JAVA provides a customisable sandbox in which JAVA programs run. This model restricts applet’s actions in a dedicated area of the web browser. Within its sandbox, the applet may do anything it wants but cannot gain access to the user’s file systems, network connections or other resources.
Applets are loaded from the network by the applet ClassLoader which receives the bytecode instruction stream and converts it into internal data structures that represent the applet’s classes. The Class Loader invokes the Bytecode Verifier  before running a newly imported applet. The verifier subjects each applet class to a number of tests: Checks the bytecode to ensure that it does not forge pointers,  violate access restrictions or access objects using incorrect type information as well as any other actions that could allow or lead to partial corruption of the security mechanism or to a partial replacement of the system with its own code. The Security Manager is an abstract class that enforces the boundaries around the sandbox. Whenever an applet tries to perform an action which could corrupt the local system, the JVM first asks the security manager if this action can be performed safely. If the security manager does not approve a security exception is raised and an error message is written to the JAVA console.
JDK1.2 includes a set of new features ,  which introduce another modus operandi for the Java security system. JDK 1.2 will consist of the following new protection mechanisms: security policy, access permissions, protection domains, access control checking, privileged operation and Java class loading and resolution.
The security policy introduced by JDK1.2 is instantiated at JVM startup and may be altered a posteriori via secure methods. Permissions, in JDK 1.2, are no longer granted to classes but to protection domains. The latter consist of all the objects that correspond to a principal who has been authorised by the system. One of the future adjustments pertinent to the protection domains is the inclusion and usage of user authentication and delegation information, in order to be able for a piece of code to have different permissions when executed by different principals. User authentication information inclusion and usage has already been tested and performed to a certain degree .
Safe-Tcl was developed by M.T.Rose and N.Borenstein. It is based on J.Ousterhout’s Tool Command Language (Tcl), which is a high-level interpreted scripting language .
The Tcl interpreter is a C library package that can be incorporated in a variety of applications. Safe-Tcl is a mechanism that initialises a Tcl interpreter to a safe subset of Tcl commands so that Tcl scripts cannot harm their host machine or application.
Safe-Tcl, like JAVA, is safe with respect to memory usage: it has no C-style pointers, bound checking in array references is enforced, and storage is managed automatically by the Tcl interpreter. An interpreter consists of a set of Tcl commands, a set of variable values, and an execution stack, thus encapsulating completely the execution of a Tcl script. This mechanism makes it possible to isolate scripts with different security properties. Finally, the facilities available to a Tcl applet (that is Tcl script, often called tclet) script are determined by the set of commands defined in its interpreter. Different interpreters can have different command sets with different security properties.
Safe-Tcl addresses security by controlling the execution of Tcl scripts by using a padded cell approach. The padded cell approach assumes that the process evaluating Safe-Tcl program, will always have within it two interpreters (often called the dual-interpreter mechanism), one trusted, for full Tcl, and one untrusted - restricted for Safe-Tcl. A program being evaluated by the Safe-Tcl interpreter will not be allowed to directly interact with the rest of the application, or to have access to the full Tcl interpreter except via the mechanisms defined as part of the Safe-Tcl language. Accessing the file system, opening network connections, invoking subprocesses, loading shared library binaries, creating toplevel windows are some of the actions that cannot be directly accessed by an applet.
The primary mechanism used by Safe-Tcl to provide restricted access to features that are essentially unsafe is command aliases. An alias is the association between a command in the untrusted interpreter and another command in a fully-trusted interpreter. Whenever the first command is invoked by a script in the untrusted interpreter, the second is the one that is actually executed instead. To be more precise, the Tcl procedure that corresponds to the command in the trusted interpreter receives all the arguments from the command in the untrusted interpreter and after being executed, its result is returned to the trusted interpreter as the result of the local command.
The trusted interpreter is responsible for managing the aliases of the untrusted interpreter. It can create and delete aliases at any time, as well as any other variable of the untrusted interpreter, and it defines the names of the "source" and "destination" commands for each alias. It also has the capability to initiate the execution of scripts in the untrusted interpreter.
From the above description of the mechanisms used in Safe-Tcl stems one of the most important strengths of the security model that is proposed: Safe-Tcl does not prescribe any particular security policy, but rather provides mechanisms for implementing a variety of security policies. More precisely, there is a "base policy" that an applet gets by default, and additional policies which provide non-trivial functionality to applets that is still safe, to some degree. Since a security policy consists of the commands available in safe interpreters using the policy, it is possible to implement highly restrictive security policies for scripts of unknown origin, by providing no aliases at all in their interpreters.
ActiveX is not a programming language by itself. From a programmer’s point of view, it is a visual control framework, which uses Component Object Model  as the underlying infrastructure. COM comprises of the infrastructure that is necessary for implementing high level software services, such as those provided by OLE. ActiveX provides the methods necessary in order to package a COM component and present it to applications such as browsers. However, the use of ActiveX is not limited only to browsers.
ActiveX is O/S-dependent. The binaries have to be compiled separetely for every machine and Operating System. ActiveX provides support for the Windows, and Unix platforms.
ActiveX controls are components that one can insert in a Web page; they can also be used in custom applications, developed with any ActiveX-aware application development platform, in order to reuse the functionality of these controls. Java and Safe-tcl lack this functionality feature.
ActiveX may be used in a complimentary way to Java. One can use ActiveX controls through Java (Sun Java/ActiveX bridge)  , and ActiveX provides a bridge to Java so that other programming languages from multiple vendors can use Java applets as reusable components.
The security scheme that surrounds the use and deployment of ActiveX relies on existing security infrastructures, such as Trusted Third Parties (TTP). ActiveX makes extensive use of the latter in order to provide for secure code distribution.
When a software developer wishes to deploy his ActiveX code, he can use his digital certificate in order to sign the code before deploying it. When a user receives a signed piece of ActiveX code he has to decide whether he will allow the execution, depending on the level of trust towards the software developer and the TTP that issued his certificate. However, there is no kind of sandbox for the code to be executed in; it is possible for the code to take complete control over the machine’s resources, without any restriction whatsoever, should the user decide to allow the execution of that piece of ActiveX code.
Besides digitally signing the ActiveX code, a software developer has to decide whether to mark the code as “safe for initializing” and “safe for marking”. Marking the code as “safe for initializing” means that the control will not cause, directly or indirectly, any harm to the user’s machine, no matter the parameters it is called with. By marking the code as “safe for scripting” the software developer asserts that his code will not cause, directly or indirectly, any harm to the user’s machine, no matter how the code is handled by the scripts contained in any Web page. Asserting whether a piece of ActiveX code executes safely when called with specific parameters and used from specific scripts and Web pages is an easy task. Evaluating this safety for all the possible parameters that may be passed to the code and for all the scripts and Web pages that may use this code is a rather impossible task to perform.
Having the user decide whether to provide an ActiveX control with full access to his system or deny the execution of the code altogether should not be considered as a safe practice. The user may elect to trust a certain software developer, though he should be considered untrustworthy. Besides that, an ActiveX control may contain bugs undetected by the software developer; it may even be falsely marked as “safe for scripting” or “safe for initialization”, by mistake of the software developer. In all these cases, the value of the digital signature as a means to protect the user from hostile code is totally discarded.
The security infrastructure upon which the support for digital signatures in ActiveX is built is called Microsoft Authenticode. Commercial firewalls are incorporating this infrastructure in order to let network administrators control the entry of ActiveX code in their networks, depending on the signatures the code carries.
The JDK is the official JAVA implementation from Sun. The JDK 1.1 includes a new JAVA core API, built out of the java.security package that allows for digital signatures (NIST DSA) on JAR files which enable the packaging of class files, message digests (SHA and MD5) , key management, certificate management and access control. The JAVA Cryptography Architecture is designed to provide implementation independence meaning that a new algorithm can be added later on without much difficulty and can be utilised in the same fashion as existing ones.
Since the ability to encrypt the data prior to being transferred is very important, APIs for data encryption are contained in a JAVA Cryptography Extension, as an add-on package to JDK.
Recently, new policy enforcement methods, secure code distribution and Java firewall blocking methods have been found and some of them implemented. These are briefly presented in the following paragraphs.
Once the code is authenticated to the system, that is associated with a principal, then the code is subject to the policy defined for that principal. To enforce this policy, three secure methods have been proposed :
Capabilities: Unforgeable pointers which can be safely given to user code
Extended stack introspection: Information about the principals can be included in the stack
Name space management: Restricting or changing an applet's namespace
Fundamentally, a capability is an unforgeable pointer to a controlled system resource. To use a capability, a program must have been first explicitly given that capability, either as part of its initialisation or as the result of calling another capability. The Java runtime would have to be modified in order to make private all the methods which handle system resources directly or indirectly. It is only the capabilities themselves (the referenced objects) that should have access to these methods.
Systems that support "capabilities" have been researched. One of these is the Java Electronic Commerce Framework , which provides a security platform, complementary to the one that JAVA is using right now, which is able to implement complex trust relationships between entities.
Extended stack introspection
This policy enforcement method has already been implemented in commercial browsers, and in the JDK1.2. There are three primitives that must be implemented for this method: enablePrivilege(target), disablePrivilege (target) and checkPrivilege(target).
Every system resource must be associated with a target. Before the system allows the use of a system resource, it should perform a checkPrivilege on the specified target. When a thread, associated with a principal, asks for a system resource it should perform an enablePrivilege on the specified target. The security policy will then decide whether that principal is entitled to use this target and the system will or will not grant the privilege to the code. After the thread has finished using this system resource it must execute a disablePrivilege. If the programmer omits the latter, the privilege should be discarded automatically. This can be done by storing the enabled privilege in a hidden and protected field of the method that created it.
Name space management
It is a method to enforce a security policy by replacing or hiding the classes that are visible by a program. There has to be a mapping between the applets (and their respective signers) and the namespaces that each applet will be able to see. Hiding a class from the namespace means that the applet may not be able at all to use it, while replacing the class with another (possibly a subclass of the latter) provides a means for controlling even more the way that the applet will call and use the methods contained in the aforementioned class.
When granting or denying a right to an applet one considers the source (signature-based) of the applet. Mehta N. et al  propose a complementing logging infrastructure which will allow the end-users and the network administrators to define dynamically a security policy for an applet, based on the past actions performed by that applet.
Secure code distribution  is one of the security issues that concern the Java community. There are various approaches to authentication for secure code distribution. One of them is the signed applets. The Java class file format is extensible. It is possible to add new attributes to the latter, without influencing the current structure or workflow of the classloaders. These new attributes can contain signatures for the applet which can be verified by the user. After the verification the security manager may grant certain rights to the applet, depending on the trustworthiness of the author or of the person who has signed the applet. Secure code distribution is already supported by Javasoft's JAR specification.
The methods and tools needed in order to define a system-wide policy have not yet been developed. It is up to the user to define the policy used against a certain piece of JAVA code, based on the digital signatures it carries. The end-user should be able to see and define only a part of the policy, enforced upon a piece of JAVA code. In an organisation, a network-wide policy should be designed by the network administrator and the administrators of the local networks.
A central repository, possibly a Directory, could be used in order to store the security policy. The later will be formed by three entities : the network administrator, the administrators of the local networks of the organisation and the end-user. The policy each of these entities will define will be based on the signer of JAVA code and on the Certificate Authority which certifies the signer’s signature. The network administrator must be given the right to decide on matters such as whether JAVA code may be downloaded to computers inside the organisation’s network and whether it may access computers other than the one it is downloaded to. The local network administrators should be able to define in which computers JAVA has the right to access the hard disks or other magnetic storage devices and also define disk quotas; they should also have the right to define which users should be able to download and execute JAVA and to which computers. Finally, the end-user should be left with few choices to make on the JAVA-related security policy. He should have to answer to questions such as “Grant game-related privileges to this code?”, forming thus the lower layer of the security policy. Web browsers have to be modified in order to consult the security policy repository before executing a piece of JAVA code.
An organisation may wish to ban all Java incoming traffic from the Internet, but wishes also to deploy and use Java applets internally, in it’s own domain. This may be achieved by blocking the Java applets at the firewall. However, up to now, no solution has proven to be complete.
Blocking Java applets at the firewall can be performed by implementing a number of strategies in order to assure that applets do not penetrate the internal network, or if they do, they are not executed at all at the local machines. This can be performed by rewriting the <applet> tag by a proxy, wherever this is found, blocking the CAFEBABE signature  and reject all files which have an extension ".class".
If one decides to implement the aforementioned strategies, he should take under consideration that they do not provide a complete solution for confining the use of Java in a network domain  and that there is a possibility of accidentally blocking useful information, e.g. files containing the CAFEBABE signature but are not Java classes or files that contain the "<applet>" string but do not call any Java applets (could possibly be a Java security paper, in HTML format) or even blocking files that end in ".class" but do not consist of Java classes.
The Princeton Group has released a product called JavaFilter  which may be used in a complementary way, when trying to block all Java traffic from specific hosts, or even from every host except specific ones. The latter will be possible as soon as wildcards will be implemented in JavaFilter.
A security issue that remains unsolved is how one can be informed whether a certificate is revoked or not, without having to download the most recent Certificate Revocation List, which can be large enough in order to prevent the user from downloading it. M. Naor et al  propose a solution which minimizes the communication costs and increases the update rate.
Safe-Tcl supports safe interpreters and aliases but it allows only a single security policy consisting entirely of the builtin commands mentioned in section 6.
Future releases are intended to include standard authentication and encryption mechanisms to provide more control over the execution of scripts, as well as mechanisms to prevent denial-of-service attacks. These intentions are described in the following paragraphs.
If the source of an applet is unknown, the receiving application must assume the worst and restrict actions that the applet may take. However, if the application can deduce something about the author of an applet, then it may be able to grant more privileges to the applet. In other words, if the application can determine that an applet is one of the approved ones, it can make additional security policies available to the applet. There exist a variety of authentication mechanisms for verifying the origin of a mobile code segment, most of which involve encryption of some sort.
Authentication mechanisms can be used to distribute new security policies . For example, an untrusted applet may carry an encrypted trusted security policy with it, so when an application executes the applet, it can safely load the security policy even though it doesn’t trust the applet. In that way, authentication makes it possible for a variety of applets and applications to take advantage of new policies developed and distributed by experts.
Safe-Tcl mechanisms can also be used to prevent denial-of-service attacks. More precisely, aliases can be created and used instead of commands that are associated with system resources and particularly with graphical user interfaces. The basic idea is to handle many of such attacks, with a kill key that the user can press at any time to destroy the applet . With this approach an application need not worry about many denial-of-service attacks, since as soon as they occur the user will notice and kill the offending applet.
However, in order to prevent denial-of-service attacks in non-interactive applications, where the user is not able to notice the attack, a familiar mechanism to operating systems is intended to be used. To be more precise, mechanisms to monitor CPU usage in Safe-Tcl will be implemented. Safe-Tcl’s approach to CPU controls is to invoke a scheduling function in the trusted interpreter once the untrusted interpreter has executed a predefined number of commands, which can abort the applet. For interactive applets the scheduling function can check to see if the kill key has been pressed, whereas for non-interactive applets the scheduling function can implement an upper limit on CPU usage, as well as on memory allocation.
An ActiveX code should not be considered as “safe for scripting or initialising” just because a software developer has marked it as such. Special provisions have to be made in order to enforce the safety of the execution of ActiveX code. One solution could be to incorporate, in a safe manner, the functions that access critical system resources in the browsers and have the ActiveX code access these functions through the libraries provided by the browser.
Another security issue that has to be confronted with is the lack of software memory protection. Research is being performed on implementing the necessary infrastructure in order to produce code that may carry proofs  that it does not violate memory safety rules. If compilers are implemented that can attach such proofs to pieces of code, then these compilers should be able to use digital certificates, in order to sign the generated proofs that will be carried by the code.
Another security issue that remains unsolved is how one can be informed whether a certificate is revoked or not, without having to download the most recent Certificate Revocation List, which can be large enough in order to prevent the user from downloading it. M. Naor et al  propose a solution which minimizes the communication costs and increases the update rate.
There is no single language that is best suited for all uses on the Web, and will make security trivial. No security model will ever manage to offer total safety and creating safe environments for executing applets will always be difficult. However, the above described languages make it possible to create environments where applets with different levels of trustworthiness can be executed with an acceptable level of risk, and that’s the reason for them appearing to have an edge over other programming languages for mobile code, in terms of security.
JAVA programming language revolutionized the programming world within nine adjectives; the third one was Secure. With the JavaSecurity API, JAVA 1.1 is building on the foundation of previous versions and afford us more flexibility to do what we want. One may claim that as far as security is concerned, JAVA work has concentrated on providing low-level security in a preferment manner, as opposed to Safe-Tcl which has focused on the higher-level aspects of security, but only in the specialized context of email. The security scheme applied in ActiveX provides a solid ground for the development of other, complimentary, security services in order to form a complete security solution. It is claimed by those who vote for JAVA that the security model it offers is more complete than the one proposed by Safe-Tcl and ActiveX since mechanisms like namespace protection and bytecode compilation go a long way towards safety and efficiency .
On the other hand Safe-Tcl has several advantages over JAVA that simplify the creation of safe environments. The first is simplicity of the proposed model. As mentioned in the previous paragraphs, it is just a generalization of the user space - kernel space model that has been used successfully in operating systems for several decades. The second is that data and code are grouped together with similar security properties, which reduces the amount of code that must be aware of security issues. Finally, security policies are separated into well-defined modules that do not depend neither on host applications nor on untrusted applets, making it easier to analyse the properties of a security policy, and to reuse policies.
The security scheme of ActiveX is quite configurable, due to the nature of ActiveX itself. A variety of application development platforms, tools and off-the-shelf available security solutions may be integrated to ActiveX. The integration of ActiveX and Java  could probably be the first step towards a common security approach to the threats that mobile code faces. ActiveX could make use of the extended security features of Java, in order to deliver a more complete security scheme.
The Sunscript group is working on Tcl-JAVA integration, since Tcl has several properties that complement JAVA nicely. To be more specific, two new products were recently released named Jacl and Tcl Blend . The first is a new JAVA implementation of Tcl 8.0, that can be used to write extensions for Tcl in JAVA code that will be cross-platform across UNIX, Windows and the Macintosh. The second is a new package for Tcl 8.0 that loading and interacting with the JAVA virtual machine.
The integration of these three platforms could lead to a security integration. Java and Tcl are already close to that; the security scheme of ActiveX can incorporate many security features and functions of the other two. Once a combined security scheme is implemented, mobile code will gain in functionality, safety and security.
 D.Balfanz, L.Gong, (1997) "Secure Multi-Processing in Java".
 D.Balfanz, E.W.Felten, (1997) "A JavaFilter", available at http://www.princeton.cs.edu/sip
 "Java Security", available at
 Borenstein N, Rose M.T., (1993) “MIME Extensions for Mail- Enabled Applications: application/Safe-Tcl and multipart/enabled-mail”
 Microsoft’s Component Object Model, available at http://www.microsoft.com/com
 Goldstein T., (1996) "The Gateway Security Model in the Java Electronic Commerce Framework", JavaSoft, available at http://www.javasoft.com/products/commerce/jectf_gateway.ps
 L.Gong, M.Mueller, H.Prafullchandra, R.Schemers, (1997) "Going Beyond the Sandbox: An Overview of the New Security Architecture in the Java Development Kit 1.2", Proceedings of the USENIX Symposium on Internet Technologies.
 L.Gong, (1997) "New Security Architectural Directions for Java", Proceedings of IEEE COMPCON.
 Gritzalis D., (1991) Information Systems Security, Greek Computer Society Publications (in Greek).
 ActiveX Bridge for Java, available at http://www.javasoft.com/javaone/sessions/slides/TT18/tt18_23.htm
 Martin D., Rajagopalan S., Rubin A., (1997) "Blocking Java Applets at the Firewall", Proceedings of the SNDSS 1997 Symposium on Network and Distributed System Security, pp.123-133, IEEE Computer Society Press.
 Mehta N.V., Sollins K.R., (1998) "Expanding and Extending the Security Features of Java", Proceedings of the Seventh USENIX Symposium
Naor M., Nissim K., (1998) "Certificate Revocation and Certificate Update", Poceedings of the Seventh USENIX Symposium
 NEcula G.C., Lee P., (1996) “Safe Kernel extensions without run-time checking”, Proceedings of the Second Symposium on Operating Systems Design and Implementation
 Ousterhout J.K., (1996) "The Safe-Tcl Security Model".
 Ousterhout J.K., (1997) "Scripting: Higher Level Programming for the21st Century".
 Schneier B., "Applied Cryptography", J.Wiley & Sons.
 Sun Microsystems, (1997) Frequently Asked Questions - Applet Security, at http://java.sun.com/sfaq/
 Sun Microsystems, (1997) "Secure Computing with Java: Now and the Future", at http://java.sun.com/marketing/collateral/security.htm
 "The Java Virtual Machine Specification", (1997) available at http://java.sun.com/docs/books/vmspec/
 "Jacl and Tcl Blend", (1997) available at http://sunscript.sun.com/java/
 D.S.Wallach, D.Balfanz, D.Dean, E.W.Felten, (1997) "Extensible Security Architectures for Java", Proceedings of the 16th Symposium on Operating Systems Principles.
 Weiss M., Johnson A., Kiniry J., (1996) "Security Features of Java and HotJava".
 Yellin F., (1995) Low Level Security in Java, at http: //java.sun.com/sfaq/verifier.html
 X.N.Zhang, "Secure Code Distribution", (1997) IEEE Computer, June 1997, pp.76-79.
Stefanos Gritzalis received a BSc in Physics and an MSc in Electronic Automation, both from the University of Athens, Greece. He is also pursuing a PhD degree on Distributed Systems Security, with the Department of Informatics of the University of Athens. Currently, he is an Assistant Professor with the Department of Informatics of the Technological Educational Institute (TEI) of Athens, and a Research Associate with the Department of Information & Communication Systems of the University of the Aegean, Greece. He has been involved with many national and EU funded R&D projects in the areas of Computer Security and Distributed Systems and he has authored two books (in Greek) and more than 10 technical papers and international conference presentations. His research interests include Distributed Systems, Computer Systems Security, and Operating Systems.
John Iliadis is pursuing his thesis statement with the Department of Informatics of the Technological Educational Institute (TEI) of Athens, Greece. He is also an Assistant Researcher at the Department of Information & Communications Systems of the University of the Aegean, Greece. His research interests include Computer Systems Security and Distributed Systems.