Securing the Network Client*

 

Victoria Skoularidou^{1, 2} and Diomidis Spinellis¹

 

¹Department of Management Science and Technology,

Athens University of Economics and Business (AUEB),

Patission 76, GR-104 34, Athens, Greece

Tel: +30 108203682, Fax: +30 108203685

http://www.dmst.aueb.gr/dds/, mailto:dds@aueb.gr

 

²Development Programmes Dept., INTRACOM S.A.,

Hellenic Telecommunications and Electronics Industry,

19.5 Km Markopoulo Ave., GR-190 02, Peania, Greece

Tel: +30 106690347, Fax: +30 106830312

http://www.intracom.gr/, mailto:vsko@intracom.gr

 

Abstract

 

We enumerate and compare a number of security-enabling architectures for network clients. These architectures, either proposed as methodologies or currently implemented in software and/or hardware, are capable of protecting the client’s software integrity and its environment. The most important methodologies include the reference monitor model, firewalls and virtual machines. Software implementations are the Java sandbox and the code signing concept. Hardware that can be used includes smart cards. We describe their most important features and provide a review and comparative study based on a number of criteria. We believe that ongoing research can empower these mechanisms for protecting network clients in a more effective way.

 

Keywords

 

Security-enabling architectures, Network clients, Client software integrity.

 

1.         Introduction

Despite effort being expended to secure network clients, these are increasingly and continuously succumbing to viruses, worms, and Trojan horses.  As the same client is nowadays trusted to conduct financial transactions or store and process sensitive personal information, its users deserve to be assured of a higher level of security than what is currently the norm.  In this paper we review, from an architectural standpoint, methodologies and technologies that can be used towards this end.

 

According to (Ghosh, 1998) the security of Web-based systems should be ensured in four fronts: Web client, data transport, Web server and operating system security. In this survey paper, we focus on the network client side and examine a number of architectures and technologies that can be used for protecting the integrity of the client and its environment. With the term “client” we refer to web clients, e-mail clients, access clients (like ftp and/or telnet), and similar applications. These architectures have either being proposed as methodologies, presented in section 2, or are actual implementations (in software and hardware) currently in use and described in sections 3 and 4. Section 5 draws the lessons of this study and compares the security-enabling architectures that were studied.

 

2.         Methodologies

From the theoretical security models in existence, some have been realized in commercial product implementations while others were abandoned and exist only as concepts in the research community. In the first category we can identify the notion of firewall and virtual machine while the reference monitor model falls in the second one. We provide a description of these models in the following paragraphs.

 

2.1.       The Reference Monitor Security Model

The Reference Monitor was based on the abstract modeling efforts of (Lampson, 1971) and was also described by (Anderson, 1972). It is depicted in the figure below (Stallings, 1995):

 

 

 

 

 

 

 

 

 

Figure 1: The Reference Monitor Concept.

 

The reference monitor is a controlling element in the hardware and operating system of a computer that regulates the access of subjects (e.g. users, processes, etc.) to objects (e.g. files, programs, etc.) on the basis of their security parameters. It has access to the security kernel database that lists the access privileges of each subject and the protection attributes of each object. Any detected security violations and authorised changes, are stored in an audit file.

 

One major problem of the reference monitor concept is that it is too complex and requires the developer to start with a totally new operating system (and probably hardware) design (Lobel, 1986). Another problem is that early attempts to reproduce it in actual hardware and software met with only minimal success, primarily because of unexpectedly high overhead and/or system performance degradation. One historical example is the operating system MULTICS (Organick, 1972), developed in the late 1960s by MIT, Bell Labs, and Honeywell.

 

However, supposing that the reference monitor was implemented as a part of a system, then a network client could be protected in the following way: Let’s imagine that a UNIX system user navigates with his web browser into a number of web sites. According to the RM’s policy, as a subject, the only privilege he has is the capability of saving web pages, files, etc. in the directory “internet_files” of his mounted hard disk (the corresponding object). If a malicious applet is downloaded on his machine and tries to gain root privileges by e.g. executing a SUID program, it will simply fail since the reference monitor will deny access, according to the previous security policy. The same applies with the user’s mail client. If the user is only allowed to save attachments on his disk storage then a rogue program could not harm his system, as the reference monitor would prevent any compromise. 

 

2.2.       The Firewall Concept

Properly configured firewalls can constitute an effective type of network security. They prevent the dangers of the Internet from spreading into the internal network by restricting access at a centrally managed point. 

 

Firewalls are classified into three main categories (Cheswick and Bellovin, 1994): packet filters that drop packets based on their destination address and port, circuit gateways that relay TCP connections, and application-level gateways where special-purpose code is used for each desired application (making it easy to log and control all incoming and outgoing traffic).  

 

Application-level gateways can provide a centralized point for monitoring the behavior of an electronic mail system and they can analyze and record traffic and content looking for information leaks. Their principal disadvantage is the need for a specialized user program for most services provided. Also, the use of such gateways is easiest with applications that make provision for redirection, such as email, otherwise new client programs must be provided.

 

2.3.       The Virtual Machine Concept

A Virtual Machine is a piece of computer software designed to reproduce a specific set of computer behaviors and capabilities other than the ones native to the computer or operating system on which the software itself is running. Some virtual machines are emulators; Others produce behaviors and capabilities of a machine that doesn't necessarily exist as an actual piece of hardware but may only be a detailed specification. More modern examples include the specification of the Java Virtual Machine (JVM) (Lindhorn and Yellin, 1997) and the Common Language Infrastructure (CLI) of the Microsoft .NET initiative. These allow diverse computers to run software written to that specification; the virtual machine software itself must be written separately for each type of computer on which it runs. Other virtual machines let one operating system run on top of another on the same machine like (VMware Inc, 2000).

 

The virtual machine design has two advantages: a) system independence, since any application will run the same in any virtual machine, regardless of the hardware and software underlying the system, and b) security, because the virtual machine has no contact with the operating system, hence there is little possibility of a program damaging other files or applications. The virtual machine can be used to sandbox applications since it stands between the real hardware or another operating system layer (the virtual machine is often an operating system). This, of course, has a downside concerning efficiency, because operating system calls and privileged instructions of programs running in a virtual machine have to pass through the virtual machine layer. Thus, virtual machines like JVM and VMware also provide a restricted environment in which programs may operate. Errant applications should only be able to cause damage to the virtual machine, thus leaving the real system intact.

 

3.         Software Implementations

Here, we present network client security architectures currently implemented in software that allow the secure execution of downloadable executable content (i.e. mobile code).

 

3.1.       The Java Sandbox

The Java Sandbox is Java’s security model, by which any untrusted Java applet must abide. It is a technological solution to prevent malicious code behavior, thus protecting a network client from possible attacks. For example, if a user downloads via her Web browser an applet that tries to erase her hard disk, it will fail because the sandbox restricts its operation, since it is untrusted. The Java sandbox is enforced by three technologies:  the Bytecode Verifier, the Applet Class Loader, and the Security Manager (McGraw and Felten, 2000). 

 

The Java sandbox is quite complicated but it is one of the most complete existing security models. The problem is that the three technologies comprising the model work in concert to prevent an applet from abusing its restricted privileges. They are highly interdependent and non-overlapping. Because each one provides a different function, a flaw in one can break the whole sandbox (McGraw and Felten, 1997). So, their design must be solid, and their implementations must not be flawed. The complexity of the functions that each technology provides makes a correct implementation a difficult goal to attain. The Java security problems found to date are a direct result of flaws in these functions implementations (Ghosh, 1998).

 

3.2.       Code Signing

Modern component-based software is a lot harder to secure because: a) someone cannot assume that all the modules are trustworthy, b) someone cannot assume that all the modules are written well enough to work in every possible configuration, and c) the operating system is not there to deal with (a) and (b), since modern components talk to each other directly, not through the operating system, so any built-in safety features simply do not apply. Several general methods for dealing with this security problem have been tried, like Code Signing. The programmer signs components and the user decides, based on the signatures, which components to allow on his computer. Sun’s Java and Microsoft’s ActiveX Controls provide code-signing features.

  

The Java sandbox very simply and strictly prevents Java applets downloaded from the network from using sensitive system services. The security policy for untrusted applets is black-and-white (Ghosh, 1998): if applets are downloaded across a network connection, they must abide by the strict constraints of the sandbox; if they are loaded from the local file system, they are completely trusted and given free rein of the system, as Java applications do. 

 

To provide greater flexibility to run Java applets in a trusted environment, JavaSoft has provided the ability to sign applets using JDK’s 1.1 Crypto API. It provides the ability to digitally sign applets with unforgeable proof of identity (Gritzalis et al., 1998). In this way, applets access system resources based on who signs them. The black-and-white security policy for executing applets in JDK 1.1 changed to a shades-of-gray model in JDK 1.2 where more fine-grained access control is supported.

 

ActiveX is a framework for Microsoft’s software component technology that allows programs encapsulated in units called controls to be embedded in Web pages (Ghosh, 1998). Unlike Java, ActiveX is language independent but platform specific. The controls can be written in several different languages but can be executed only on a 32-bit Windows platform. Since ActiveX controls have the ability to execute much like any other program on a computer, they may be used to forge e-mail, monitor Web usage, send files over Internet, write files, interact with other programs, etc.

 

Microsoft’s response to addressing ActiveX technology security problems is Authenticode (Microsoft Corp., 2001). This does not prevent ActiveX controls from behaving maliciously but it can be used to prevent automatic execution of untrusted ones. Authenticode can provide two checks before executing ActiveX controls: it can verify a) who signs the code, and b) if the code has been altered since it was signed. Authenticode provides verification of the identity of the person who signed the control and integrity checks of the software to ensure it has not been altered since it was signed. However, the signature provides no assurance that the control will not behave maliciously. Authenticode technology works solely on a trust model and there is no middle ground to let the control execute in a constrained environment where it can be observed before granting full access.

 

The key difference in security between ActiveX controls and Java applets is that ActiveX security is based wholly on the trust placed in the code signer, while Java applet security is based on restricting the behavior of the applet (Ghosh, 1998). One is a human judgment-based approach to security, while the other is a technology-based approach using the sandbox solution. Java applets signing has been also introduced by JavaSoft as a policy based on trust and human judgment. Signed applets have the ability to access system resources based on who signed them, but untrusted ones can still execute, albeit with the sandbox limitations.

 

4.         Hardware Implementations

So far, security-enabling architectures that were proposed as methodologies or are based on software implementations were examined. In this section, we describe hardware-based ones.

 

4.1.       Smart Cards

A smart card stores and processes information through the electronic circuits embedded in silicon in the plastic substrate of its body. There are two basic kinds of smart cards (Chen, 1998): An intelligent smart card contains a microprocessor and a memory chip and offers read, write, and calculation capability. A memory card contains only a memory chip, is meant only for information storage and can only undertake a predefined operation. Smart cards can carry all necessary functions and information on the card, so they do not require access to remote databases at the time of the transaction. Their benefits of increased storage, security and portability have made them very popular against magnetic stripe cards, that are not so secure, require a host system to store and process all data and cannot make data universally accessible (Coleman, 1998). By putting sensitive information like passwords and encryption keys into a central point like the card and, thus, outside of the client’s environment, the client becomes less vulnerable to malicious attacks. On the other hand there also exist problems: if a hacker takes the control of the client he could force the card to do something the client does not want like giving his credit card information to a malicious site (Balfanz and Felten, 1999).

 Typically any application requiring authentication can benefit from a smart card. Smart cards can be used for authentication and as a secure, convenient portable storage mechanism. With the advent of the Java Card (a smart card capable of running Java bytecodes) limitations like the portability of applications and the flexibility of downloading applications into the card are eliminated, since a single Java application can run on all smart cards (Coleman, 1998). Since one of the fundamental problems in securing computer systems is the need for tamper-resistant storage of keys, smart cards can provide this functionality so that the private key of the network client can be placed on it and the access control on the card is offered via a proper Personal Identification Number (PIN). Smart cards provide also the ability to upgrade security solutions when they become compromised, e.g. if a hacker cracks the security of smart-card enabled digital satellite systems new cardlets – Java Card applications) could be sent.  

 

The fact that smart cards now employ public key encryption to both encrypt data and digitally sign messages to provide unforgeable proof of identity, makes them ideal for integrating into them applications like social security card, access control to Web sites or online databases, digital signatures for e-mail and Web transactions, public keys for encrypting data transactions, credit/debit cards, e-cash, etc. (Ghosh, 1998). Smart cards importance has been identified by major credit card organizations like Visa, which has recently announced its Chip Migration Plan (Visa International, 2001) involving the substitution of credit cards with new ones with a microchip, more suitable for e-banking and e-commerce applications.

 

5.         Review and Comparison

After presenting the various types of security-enabling architectures, in this section we review them and use them as a basis for a comparative study.

 

First, we identify the protection these mechanisms offer against specific security threats. Generally, security threats to computer systems, fall into the following broad classes (Gritzalis and Spinellis, 1997), (Meyer et al., 1995):

·        Leakage (Disclosure): The acquisition of information by unauthorized recipients (loss of confidentiality or privacy).

·        Tampering (Modification): The unauthorized alteration of information (loss of integrity).

·        Resource stealing: The unauthorized use of system facilities.

·        Repudiation: Loss of attribution.

 

Table 1 summarizes the protection against these security threats offered by the described technologies. Malware and user ignorance have been added, since they also comprise serious threats to a computer system:

Table 1: Protection against security threats.

Apart from the level of protection and the security service these mechanism provide, we also compare them against a number of non-functional characteristics (Sommerville, 2001), summarized in Table 2:

·        Complexity. It is not enough to just allege that a certain methodology provides security. On the contrary, security attributes need to be easily verified thus should not be complex. Simplicity is a fundamental hint of computer systems design (Lampson, 1983).

·        Ease of use. This is another important attribute, since usually system administrators and users do not want to use awkward systems. 

·        Incorporation into existing applications.  How easily these mechanisms could be ported into existing systems.

Table 2: Non-functional characteristics of the described technologies.

These technologies can be combined in order to provide more fine-grained protection. E.g., in the case of a Java Card, the Java sandbox and/or the code signing mechanism need to operate in order to prevent malicious Java Card applications from being downloaded to a smart card. Similarly, if a firewall lets applets to be executed on the client’s machine the Java sandbox and/or code signing features should be also used to prevent a possible malicious behavior.

 

6.         Conclusions

There exist a lot of technologies for securing network clients. Ongoing research in sandboxing applications can be found in (Prevelakis and Spinellis, 2001) and (Fu et al., 2000) while (NSA, 2001) investigates architectures for providing operating system security mechanisms. Firewall vendors should consider more the ease of configuration while virtual machines need to be enhanced in order to provide better performance. Code signing is an improvement in controlling software origin but the fact that it is based on human judgment poses the need to use it in combination with sandboxes. Smart cards seem to be a very promising technology for client protection. Protecting network clients becomes an imperative as users rely more and more on them in order to conduct sensitive operations (e.g. e-commerce transactions). We believe that in the forthcoming years research in this area will empower their security.

 

7.         References

Anderson, J. (1972), Computer Security Technology Planning Study”, ESD-TR-73-51, HQ Electronic Systems Division (AFSC), L. G. Hanscom Field, Bedford, Mass., October 1972, vols. 1, 2. 

Balfanz, D. and Felten, E. (1999), "Hand-Held Computers Can Be Better Smart Cards", Proceedings of the 8th USENIX Security Symposium, Washington, D.C., USA. 

Chen, Z. (1998), “Understanding Java Card 2.0”, Javaworld Magazine.

Cheswick, W. and Bellovin, S. (1994), “Building Internet Firewalls”, Addison-Wesley, USA.

Coleman, A. (1998), “Giving currency to the Java Card API”, Javaworld Magazine.

Fu K., Sit E., Smith K., and Feamster N., (2000), "MAPbox: Using Parameterized Behavior Classes to Confine Untrusted Applications", 9th USENIX UNIX Security Symposium, Denver, Colorado, USA.

Ghosh, A. (1998), “E-Commerce Security: Weak Links, Best Defenses”, Wiley Computer Publishing, USA.

Gritzalis S., and Spinellis D. (1997) "Addressing Threats and Security Issues in World Wide Web Technology", 3rd International Conference on Communications and Multimedia Security, pp. 33-46, Athens, Greece.

Gritzalis, S., Aggelis, G., and Spinellis, D. (1998), “Programming Languages for Mobile Code: A problems viewpoint”, 1^st International Network Conference INC ’98, pp. 210-217, Plymouth, UK.

Lampson, B. (1971), “Protection”, 5^th Princeton Conference on Information Science and Systems, Princeton.

Lampson, B. (1983), "Hints for Computer Systems Design", 9th ACM Symposium on Operating Systems Principles, Bretton Woods, New Hampshire, USA.

Lindhorn, T. and Yellin, F. (1997), “The Java Virtual Machine Specification”, Addison-Wesley, USA.

Lobel, J. (1986), “Computer Security and Access Control: Foiling the System Breakers”, McGraw-Hill, USA.

McGraw, G. and Felten, E. (1997), “Understanding the keys to Java Security”, Javaworld Magazine.

McGraw, G. and Felten, E. (2000), “Securing Java”, Wiley Computer Publishing, USA.

Meyer K., Schaeffer S., Baker D., and Manning S. (1995) "Addressing Threats in World Wide Web Technology", 11th Annual Computer Security Applications Conference, pp. 123--132".

Microsoft Corp. (2001) “Code Signing with Microsoft Authenticode”, MSDN Library Online.

NSA (2001), “Security Enhanced Linux”, available on-line at http://www.nsa.gov/selinux/.

Organick, E. (1972), “The Multics System: An Examination of Its Structure”, MIT Press.

Prevelakis, V. and Spinellis, D. (2001), USENIX 2001 Technical Conference, USENIX Association.

Saltzer J., Reed D., and Clark D. (1984), "End-to-end arguments in system design", ACM Transactions on Computer Systems, Vol. 2, No. 4, pp. 277-288.

Sommerville I. (2001), "Software Engineering, 6^th Edition", Addison-Wesley, USA.

Stallings, W. (1995), “Network and Internetwork Security: Principles and Practice”, Prentice-Hall, USA.

Visa International (2001), “Chip Migration Plan”, available online at http://www.visa.com.

VMware Inc. (2000), “VMware GSX Server”, available at http://www.vmware.com/pdf/gsx_whitepaper.pdf.