Introduction

Introduction

In the age of hacktivism, malware and cyber-warfare, increasing numbers of publications are being produced by computer security specialists and systems administrators on technical issues arising from illegal or inappropriate on-line behaviours. Technical advances - in the ability of information systems to detect intrusions, denial of services attacks and also to enhance network monitoring and maintenance - are well documented and subject to constant research and development.

To date, however, there has been limited research into a range of other issues impacting on information systems (IS) security and its management. From a forensic computing (FC) perspective IS security management emerges as part of a much broader debate on the risks and challenges posed by digitalisation for legal, technical and social structures (Broucek & Turner, 2001a, 2001b). This perspective highlights that IS security management cannot be addressed by technical means alone. Indeed the development of effective security management relies on recognition of the need to balance a complex set of technical, legal and organisational issues (Lichtenstein & Swatman, 2000).

This chapter explores one of these issues, "user education" and identifies its relevance for, and interrelationships with, other IS security management issues. This exploration is conducted through an examination of the two most common Internet applications used in organisations: electronic mail (e-mail) and World Wide Web (WWW) browsers. By identifying common security weaknesses in both types of applications, the chapter examines how the security management problems are compounded by common online user behaviours. Retaining a FC perspective, the chapter makes recommendations for improving IS security management.

Part One

At a technical level, systems administrators are very aware of the security risks and security weaknesses prevalent in Internet applications and, in particular, in e-mail and WWW browsers. Significantly, while technical solutions are available (at a cost) to alleviate most of the major security challenges, the manner in which most users continue to utilise these applications compounds organisational IS security problems. While technical responses may be able to treat some of the symptoms of inappropriate and/or illegal user behaviours, they do little to treat the causes of these or future problematic behaviours (Broucek & Turner, 2002b). The focus here is on "user education", however, it is important to note that most technical solutions employed to detect intrusions, denial of services attacks and/or to engage in network monitoring/maintenance are not currently designed to collect forensic data (Broucek & Turner, 2002a).

As a result, user education of security risks and weaknesses must be treated as an important element in developing effective IS security management practices. For the purposes of user education of security management issues in an organisational context, users can be categorised in three major groups:

1. Employees lacking awareness of the implications of their online behaviours for organisational security;

2. Employees who are security conscious but who, in taking steps to protect their on-line privacy, remain unaware of the implications of these behaviours for organisational security; and

3. Employees who may deliberately exploit technical and managerial weaknesses to engage in inappropriate and often illegal online behaviours.

For all three types of users, targeted education, training and raising awareness emerge as critical to minimising these risks and improving IS security management practices and policies.

The following section examines some of the major security weaknesses of e-mail, their relationships with employees online behaviours and their implications for IS security and employees privacy.

E-Mail

Electronic mail (e-mail) has emerged as a major communication tool in academic, business and social environments. However, e-mail - or more technically Simple Mail Transfer Protocol (SMTP) as defined by RFC821 (Postel, 1982) and the proposed new standard RFC2821 (Klensin, 2001) - remains inherently insecure as a communications medium. As a result e-mail per se is not suitable for the transfer of any information that has to be kept secret. Significantly, most employees and many corporate managers remain unaware that e-mail, unless encrypted, is transferred in plain text, and that during its transfer from sender to receiver journeys through numerous computer systems that could provide points of access to the content of the e-mail. More worryingly, most e-mail systems in use still deploy the very efficient, but simple Post Office Protocol version 3 (POP3) (Myers & Rose, 1996). In most instances POP3 based e-mail clients send passwords in clear unencrypted text across computer networks, thereby enabling sniffing/spoofing type security breaches. Although partial solutions for both these weaknesses are available in the form of TLS/SSL capabilities of e-mail clients (Hoffman, 1999; Newman, 1999), their acceptance is very slow and often hindered by the lack of support for such capabilities in common e-mail software. For example, the version of SMTP daemon sendmail distributed by SUN Microsystems with their operating system Solaris 8 does not support TLS/SSL.

These security weaknesses are further compounded by the fact that, as has often been observed, many employees do not bother to have separate passwords for e-mail and other systems that they use in the course of their work. This "one password for everything" approach means that POP3 e-mail client sniffing/spoofing type security breaches may become access points for all organisational information systems.

Awareness of these security weaknesses in e-mail has led many systems administrators to enhance security and restrict access to organisational e-mail systems. From the user's perspective this has led to the perception of organisational e-mail systems as being "unfriendly." This is mainly because these systems tend not to be accessible outside the organisational "firewall" and/or because organisational policy prohibits their utilisation for private communications. As a result of the increasingly important social dimension to e-mail usage most employees solve this "problem" of lack of anytime/anywhere access to e-mail by subscribing to one of the numerous free Web-mail services, e.g., hotmail.com, yahoo.com, excite.com, etc. This user response to the need for e-mail access introduces further risks for organisational IS security management.

As was mentioned above, the tendency of employees to adopt the "one password for everything" approach means that the same password is used on organisational e-mail systems as well as on private Web-mail accounts. This dramatically increases the possibility of password sniffing/spoofing type security breaches. Web-mail services also appear susceptible to a higher incidence of direct or double-click attachment-based viruses that can easily migrate to the organisational information systems as a result of employee online behaviours. More significantly, most of these free Web-mail systems also allow the checking of POP3 e-mail accounts. Employees using these services are rarely aware that in doing so they may be allowing unauthorised access to organisational information.

From the authors' own experiences in network administration within a university environment, it is evident that more than 70% of current students opt for a free Web-mail account in addition to their university e-mail accounts. From class discussions the main reason given by students was the concern that university administrators could gain access to their university e-mail accounts, making them feel concern that their personal e-mail would be read. Following open discussions of the security weaknesses and risks of Web-mail accounts with a class of 30 postgraduate students, all but one opted to stop utilising Web-mail and to use the University e-mail system providing POP3 access internally and SSL protected Web based access from outside of university firewall.

Finally, it is also worth noting how, at a time when legal principles providing for privacy and data protection in the on-line environment have become increasingly common and users privacy expectations have continued to grow, there has been an exponential growth in inherently insecure digital communications that provide individuals with little or no privacy (Broucek & Turner, 2002b).

WWW Browsers

Web browsers, like e-mail, have become central to the development of the information age. But they also exhibit many security weaknesses that combine with users' online behaviours to compound IS security management problems. These include:

• Web browser history and cache files being kept on local drives:

  Generally users are unaware of this and its implications for their privacy, including the ease with which the sites they have visited can be viewed. This problem becomes even more significant for privacy in environments where computers are shared;

• Extensive use of cookies:

  This is problematic because many sites now do not work if cookies are disabled in browsers. This raises issues not just because of the privacy of the user, but also because organisational information is disclosed through the TCP/IP address and through other details available from browsers;

• Possible disclosure of information about computers running the browsers:

  The majority of browsers, if not "hardened," enable the collection of information about themselves and the underlying software and hardware they run on. This can be used by hackers for collecting information about computers and software. This "fingerprinting" generates information that can subsequently be used to find systems vulnerabilities that hackers can exploit to hack into these systems;

• Corporate users assuming that being behind corporate firewall/cache/proxy means that their true identity is not exposed to browsed Internet sites:

  This is often not the case because many corporate installations pass through the HTTP_X_FORWARDED_FOR environment variable;

• Active pages - using Java applets, Java scripts, ActiveX technologies:

  Introducing executable elements into Web pages creates potential risks for the spread of malware, viruses, etc.;

• Data collected from browsers can be used for Internet user profiling and consequently for targeted advertising and context:

  For example, a person that once visits "porn site" will later on be targeted by receiving "e-mails" advertising "porn sites," they may be subject to pop-up screens redirecting them from browsing legitimate site to sites considered to be inappropriate and often illegal.

Having highlighted the major weaknesses of browsers, it is perhaps worth mentioning that from a forensic computing perspective, it is these very weaknesses that are often exploited to create the invaluable resources that form the basis for forensic investigations.

Access to Internet through Web browsers creates further privacy issues for both users and IS management. Many organisations use proxy/cache for speeding up, controlling and monitoring access to Internet by using proxy authentication. Proxy authentication and monitoring can create amongst users the perception of a modern form of "Panopticon" (Dishaw, 2002). In particular, this perception can be created if such monitoring and/or authentication are introduced without proper policies, and if the purpose of their introduction is not explained to users. Proxy authentication is often used only for statistical purposes, however it often can create a "big brother" type of surveillance fear amongst the users. Unfortunately, current available proxy authentication tools and proxy authentication implementations in major Web browsers do not support any sophisticated forms. As a result, passwords used for proxy authentication travel across the wire in "BASE64 uuencoded" format that is close to plain text. These issues have been further compounded by some implementations of proxy authentication requiring users to use the same password as for their e-mail.

Part Two

In the context of the above discussion, this part of the chapter aims to generate recommendations for improving user education as a component of IS security management practices. From a forensic computing perspective these recommendations remain conscious of the need to balance improved security for the organisation and the privacy of employees, without compromising the potential for future forensic investigation of inappropriate, criminal, or other illegal online behaviours.

Clearly a major element in any organisational IS security management approach must be to provide detailed explanations and demonstrations to users of how their online behaviours with these two applications could potentially damage the organisation. As part of this education, it will be important to address head-on employees' privacy concerns and to introduce transparent and documented procedures for any investigations over particular behaviours. Users must also be made aware that using anonymous e-mails, proxies and anonymizers will not prevent future forensic investigations from being able to track and trace their online activities. It is also imperative that the risks associated with computer viruses are explained, along with the potential fallibility of current antivirus software. In particular, the importance of not running or opening files (usually referred to as "double clicking") received via e-mail from unknown or unreliable sources should be explained.

In addition to explanations and demonstrations it is important that organisations put in place IS security management policies that balance employee privacy concerns with the need for improved security. These policies must be transparent and developed in cooperation with employees. Where deterrents to inappropriate online behaviours are introduced, they should be explained and discussed. If organisations feel the need to have the option of monitoring online behaviours or conducting forensic investigations, then staff should be informed of the procedures and the results of any investigations or monitoring. Creating a "big brother surveillance" perception amongst employees may well be counter-productive in terms of IS security and/or wider organisational goals (Dishaw, 2002). Effective IS security management will increasingly rely on informing users of the risks and allaying privacy concerns they may have as the need for monitoring and forensic investigation become increasingly common.

Conclusion

This chapter has highlighted a series of security and privacy problems with e-mail and Web browsers, and suggested how improved and targeted user education can significantly improve IS security management within organisations. With the dramatic growth in malware and cyber-attacks that looks set to continue, it has become increasingly important that organisations improve their IS security management policies and practices through a balanced and cooperative approach.

Security Administration Software

Security Administration Software

Security administration software includes intrusion detection, management software for security software and vulnerability checking.

An Intrusion Detection System (IDS) monitors traffic in a network and/or user behavior in a host computer to identify possible intruders and/or anomalous behavior and/or misuse (Stallings, 2000, Chap. 9).

Network security software in host computers and in other network nodes, like routers, configurable switches, is often controlled by management software. An example is the distributed IDS described in Heberlein, Mukherjee, and Levitt (1992). Management software is also available for multiple installations of Cisco Secure PIX Firewalls (Cisco PIX 500 Firewalls, 2002). The Digital Immune System described in Stallings (2000, Chap. 9) as well as security software developed and delivered by F-Secure (F-Secure Enterprise Solutions, 2002) are also centrally managed and updated.

A major vulnerability of password protection is insufficient password quality. Passwords can be too short or easily guessed or cracked. A potential intruder could run a password cracker on the encrypted passwords stored in a computer. A system administrator should often do the same, disable user accounts with bad passwords, and urge users to use only good passwords. A freeware password cracker, L0phtCrack, can be downloaded from @stake Research Labs (2002)

Intrusion into a computer in a TCP/IP network occurs through open ports. Intrusion prevention thus requires administration based on regular vulnerability scans for open ports. The vulnerability scan procedure is described in Conry-Murray (2001). How the three-step "handshake" to establish a TCP connection can be manipulated in intrusion attempts is described in Scambray, McClure and Kurtz (2001). A freeware port scanner, Nmap, can be downloaded from Insecure.Org (2002). Information on available commercial port scanners is available at Atomic Tangerine (2002).

Security Software Development

Antivirus protection programming skills require studies of self-modifying code programmed in assembler, in high level programming languages, and in scripting languages, as well as of virus sensitive vulnerabilities in common operating system environments.

Firewall software programming skills are based on knowledge of software implementations of the TCP/IP protocol stack. Programming exercises and projects to design software of the IP, TCP, UDP and application level protocols should therefore be included in advanced network security education.

For development of network applications with built-in application level security the open source toolkit OpenSSL is available (The OpenSSL Project, 2001). OpenSSL can be installed on UNIX, Windows, and Macintosh computers as a library of C functions available to a C compiler. Also, commercial development tools for SSL-protected network applications are available. RSA Security and Certicom offer software developer kits based on C and Java (see RSA BSAFE, 2001; Certicom, 2001).

There are a number of IPSec implementations and patches available for Linux, such as portable, open source, tunnel and reference implementation. (References can be found in R4knet, 2002; Ringström, 2002; Linux FreeS/WAN, 2002; and NIST/ ITL, 2002). The KAME project aims to provide free reference implementations of IPv6 and IPSec (see KAME Project, 2002).

There are also available commercial IPSec developer products such as SSH QuickSec™ Toolkit. This toolkit includes full IPSec based VPN functionality, an integrated stateful inspection firewall with support for multiple Application Level Gateways, dynamic addressing and configuration, and integration to existing infrastructures (authorization, authentication and accounting). It provides the industry's latest Internet standards, including IPv6, NAT Traversal, and robust PKI support (press release, 2002).

VPN software is implemented as add-on or integrated software controlled by operating systems of workstations, servers, and routers (F-Secure Security Solutions, 2002; Cisco Systems, 2002; Linux FreeS/WAN, 2002). Development skills for VPN software and other IPSec applications require a deep knowledge, especially in IKE - the encryption key management protocol in IPSec. Education of IPSec specialists should include installation, configuration, and test use of VPN software, as well as source code studies of VPN implementations combined with programming exercises in which new features and/or modifications are introduced into the examined VPN software.

There are a number of S/MIME toolkits and packages available from different commercial companies or non-commercial organizations. With these toolkits S/ MIME features can be implemented to existing software that do not support S/ MIME and to applications under development that need S/MIME support.

A freeware S/MIME v3 toolkit is available in the S/MIME Freeware Library (SFL). SFL works under the MS Windows NT/98/2000/XP, Linux and Solaris 2.8 operating systems (see Getronics, 2002).

There is an S/MIME Toolkit for cross-platform development of S/MIME applications available from The Mozilla Organisation. The Mozilla S/MIME Toolkit provides S/MIME functionality via an API that can be integrated with a variety of MIME parsers and generators (see Mozilla Organization, 2002).

Phaos S/MIME is a package in pure Java. With the Phaos S/MIME Toolkit secure S/MIME messaging applications and applets can quickly be built. The Phaos S/MIME Toolkit is platform-independent, and executes on newer versions of the Java platform. With the Phaos S/MIME Toolkit you can incorporate the S/MIME secure messaging protocol into Java applications (Phaos, 2000).

RSAEuro is an open source cryptographic toolkit providing various preprogrammed functions in C. RSAEuro can be downloaded; for example, from ftp.funet.fi (FUNET ftp server, 2001).

In smartcard application development usually some development kit for smartcard programming is used. Microsoft offers a Smart Card Toolkit based on the use of visual programming tools (Windows for Smart Cards Toolkit for Visual Basic 6.0, 2001).

Network Security Software Skill Levels

Every computer and computer network user needs skills:

• to understand the significance of antivirus protection and to perform virus scans with installed antivirus protection software;

• to understand the basic principles of firewalls; to install and use firewall software for protection of a workstation connected to a public TCP/IP network;

• to manage settings of network security software embedded for example in web browsers and remote access software like SSH; and

• to understand the basic principles of PKI and digital signatures.

This skill level could be called user level, including basic understanding of PKI and digital signatures. User level skill examples are management of security settings of a web browser and inspection of the signature of a signed email message .

User level skills in network security software should be acquired in all medium- and higher-level education

The next level of network security software skills is the network administrator level, which should include skills to install, configure and update network security software . Education of IT engineers and other IT professionals should provide network administrator skills in network security software.

The highest level of network security software skills is the software development level, in which a profound and detailed knowledge of:

• behavior of viruses and other malicious programs

• TCP/IP and other network protocols

• cryptographic algorithms, protocols and standards

is combined with advanced programming skills. Figures 12-14 illustrates the knowledge and skills needed for development of PKI client software based on the PKCS#11 standard. Education of software and programming professionals should provide software development skills in network security software.

An even higher skill level could be introduced, the network security scientist level, which covers knowledge and skills:

• to propose new protection methods against viruses and other malicious programs,

• to propose new firewall types and configurations,

• to further develop the mathematics of cryptography, and

• to propose new cryptographic algorithms, protocols and standards.

PKCS #11 V2.11: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD
11.1.7	More on relative priorities of Cryptoki errors	133
11.1.8	Error code "gotchas"	133
11.2	Conventions for functions returning output in a variable-length buffer	133
11.3	DISCLAIMER CONCERNING SAMPLE CODE	134
11.4	GENERAL-PURPOSE FUNCTIONS	135
?	C_Initializ	135
?	C_Finalize	136
?	C_GetInfo	137
?	C_GetFunctionList	138
11.5	SLOT AND TOKEN MANAGEMENT FUNCTIONS	139
?	C_GetSlotList	139
?	C_GetSlotInfo	141
?	C_GetTokenInfo	141
?	C_WaitForSlotEven	142
?	C_GetMechanismList	144
?	C_GetMechanismInfo	145
?	C_InitToken	146
?	C_InitPIN	147
?	C_SetPIN	149
11.6	SESSION MANAGEMENT FUNCTIONS	150
?	C_OpenSession	151
?	C_CloseSession	152

Figure 13: PKCS #11 function declarations published by RSA Laboratories

It should be possible to acquire this skill level in postgraduate IT education in universities.

Network Security Software Skills in Higher Education

Education of computer scientists and IT professionals in universities and polytechnics includes, as a rule, courses in computer and network security (Rubin, 2002). Several universities also offer MSc programs in information security (see Eastern Michigan University, 2002; James Madison University, 2002; Queensland University of Technology, 2002; University of Glamorgan, 2002; University of London, 2002; University of Westminster, 2002). Usually these courses and programs cover information security administration, antivirus protection, firewall techniques, intrusion prevention and detection, theory and applications of cryptography, and information security standards. Computer scientists and IT professionals educated by these courses and programs should have knowledge as well as skills about installation, configuration, use, and user support of present network security software. However, university and polytechnic level network security education seldom covers network security software development skills like programming TLS/ SSL applications, IPSec applications, SET applications, PKI applications, authentication solutions, applications with digital signatures, antivirus protection software, firewall software, and smartcard programming.

   /* pkcs11f.h include file for PKCS #11. 2001 June 25 */
  /* This function contains pretty much everything about all the */
  /* Cryptoki function prototypes. Because this information is */
  .............................
  /* Signing and MACing */

  /* C_SignInit initializes a signature (private key encryption)
  * operation, where the signature is (will be) an appendix to
  * the data, and plaintext cannot be recovered from the
  * signature. */
  CK_PKCS11_FUNCTION_INFO(C_SignInit)
  #ifdef CK_NEED_ARG_LIST
  (
  CK_SESSION_HANDLE hSession, /* the session's handle */
  CK_MECHANISM_PTR pMechanism,   /* the signature mechanism */
  CK_OBJECT_HANDLE hKey      /* handle of signature key */
  );

Conclusions

The rapidly spreading use of computers and computer networks and the many advantages of open global network interconnections also have created increasing needs of improved information security. Software solutions and tools are irreplaceable cornerstones in network security. As can be seen from this chapter, network security software is today a large and complex topic area in a rapidly expanding state. Network security software skills are a necessity, not only for IT and security specialists, but for every computer and computer network user. All this has profound implications on IT education, but also on all education in which use of computers and computer networks is inevitable.

The highest level of IT education, the university and polytechnic level, education for network security software skills should include:

• installation, configuration, and test use of all categories of available network security software solutions and products,

• source code inspection exercises of open source network security software solutions, and

• programming exercises and projects with TLS/SSL application development environments, cryptographic toolkits like RSAEuro, IPSec applications, SSH applications, PKI applications, and smartcard applications.

More emphasis should be put on network security software development skills in present upper level network security education, especially in postgraduate educational programs focusing on information security. Also, student participation in related research should be supported.

  #endif

Figure 14: PKCS #11 function declaration in include file pkcs11f.h published by RSA Laboratories

Education of IT professionals in Arcada Polytechnic includes an undergraduate course on Computer and Network Security and specialization courses on IPSec Applications and TLS/SSL Programming. Arcada Polytechnic has, in cooperation with the LM Ericsson IPSec Competence Center, implemented a multimedia IPSec tutorial, in which the characteristics of IPSec and especially IKE are illustrated with audio-supported text presentations, pictures and animations.

Cryptographic Software

Cryptographic Software

Classification

Cryptographic software for network security consists of secure network applications and implementations of

• secure network level data communication (IPSec) and

• secure transport level data communication (TLS/SSL).

TCP/IP network standards proposed by IETF are available for secure data communication on these two levels of the protocol stack, as well as for many secure network applications (Active IETF Working Groups, 2001). Many cryptographic software applications use standardized X.509 certificates of the Public Key Infrastructure (PKI) on the Internet (IETF Public-Key Infrastructure Working Group, 2002). PKI client software like ID2 Personal (2001) is a necessary component of such applications. Protection of sensitive cryptographic data and operations is usually implemented as smartcard applications (Rankl, 2000).

Software for Secure Network Level Data Communication

Most software implementations of secure network level data communication in TCP/IP networks are based on the Internet Protocol Security (IPSec) protocol suite developed by IETF IP Security Protocol Working Group (2002). A detailed tutorial on IPSec is found in Doraswamy and Harkin (1999).

The IPSec protocol suite adds security to TCP/IP communication by introducing a new layer in the TCP/IP protocol stack below the IP layer. IPSec adds authentication and optionally encryption to all transmitted data packets. Authentication ensures that packets are from the right sender and have not been altered. Encryption prevents unauthorized reading of packet contents. Two computers connected to the same TCP/IP network can implement end-to-end security through the network if IPSec software with encryption is installed and properly configured in both computers. When normal IP packets reach the IPSec node they are no longer routed through the network. They are instead used as optionally encrypted payloads of new IP packets (IPSec packets). The IPSec packets are then routed through the IP network, such as the Internet, until they reach an IPSec node, where the packet payloads are — for encrypted payloads first decrypted and then — unpacked to traditional IP packets.

Key management and security associations, the IPSec parameters between two IPSec nodes, are negotiated with the Internet Key Exchange (IKE). IKE is based on the Diffie-Hellman key exchange protocol. IKE creates an authenticated, secure tunnel between two IPSec nodes and then negotiates the security association for IPSec. This process requires that the two entities authenticate themselves to each other and establish shared keys.

IPSec defines a new set of headers to be added to usual IP packets in order to create IPSec packets. These new headers are placed after the IP header and before the Layer 4 protocol (typically Transmission Control Protocol [TCP] or User Datagram Protocol [UDP]) header. These new headers provide information for securing the payload of the IP packet as follows:

Authentication Header (AH)

This header, when added to an IP datagram, ensures the integrity and authenticity of the data, including the invariant fields in the outer IP header. It does not provide confidentiality protection. AH uses a keyed hash function rather than digital signatures, because digital signature technology is too slow and would greatly reduce network throughput.

Encapsulating Security Payload (ESP)

This header, when added to an IP packet, protects the confidentiality, integrity, and authenticity of the data. If ESP is used to validate data integrity, it does not include the invariant fields in the IP header.

IPSec provides two modes of operation — transport and tunnel modes. In transport mode original IP headers are used, but in tunnel mode new IP headers are created and used to represent the IP tunnel endpoint addresses. IPSec tunnel mode is thus an example of IP tunneling in TCP/IP networks.

The core elements of IPSec are shown in Figure 2. ISAKMP is the name of the standardized negotiation protocol used by Internet Key Exchange (IKE). Security Association Databases (SAD) and Security Policy Database (SPD) are databases needed by IPSec and IKE.

Figure 2: Elements of IPSec

IPSec is also integrated with Windows 2000 and Windows XP Professional to provide a platform for safeguarding TCP/IP data communication (see Microsoft TechNet, 2002).

The introduction of DNSSEC may however change the status of IPSec in the future.

A widely used IPSec application is Virtual Private Network (VPN) software for providing secure LAN functionality for geographically distributed LAN segments and computers interconnected by a public TCP/IP network, like Internet. VPN software thus implements IPSec tunnel mode. VPN software developers have founded an international trade consortium, VPNC. The primary purposes of VPNC are (VPN Consortium, 2002):

• Promote the products of its members to the press and to potential customers

• Increase interoperability between members by showing where the products interoperate

• Serve as a forum for the VPN manufacturers and service providers throughout the world

• Help the press and potential customers to understand VPN technologies and standards

• Provide publicity and support for interoperability testing events

The two fundamental VPN types are:

1. Access VPN: A secure connection to a LAN through a public TCP/IP Network

2. Connection VPN: A secure remote connection between two segments of the same logical LAN through a public TCP/IP network

An Access VPN example is a notebook PC with installed VPN Client software securely connected to a Home LAN over Internet (see Figure 3). The router connecting the Home LAN to Internet implements the transformation between incoming/outgoing IPSec packets on the Internet connection and traditional IP packets in the Home LAN with installed and properly configured VPN server software.

(NotebookPC|VPN Client)↔Internet↔(VPN Server|Router)↔HomeLAN

Figure 3: Access VPN example

A connection VPN is, for example, when two segments A and B of the same logical LAN are connected with routers to the Internet (see Figure 4). Both routers implement the transformation between incoming/outgoing IPSec packets on the Internet connection and traditional IP packets in the LAN segment with installed and properly configured VPN software.

Segment A↔(Router| VPN)↔Internet↔(VPN|Router)↔Segment B

Figure 4: Connection VPN example

There are some free VPN programs available (see Linux FreeS/WAN, 2002). VPNlabs is an open community for researching, reviewing, and discussing Virtual Private Networks (see VPNlabs, 2001). There are also many commercial VPN applications available. Information about commercial VPN solutions can be found on the web portal of VPNC (see VPN Consortium, 2002).

Software for Secure Transport Level Data Communication

Many applications in TCP/IP networks are based on the Transport Layer Security (TLS) standard proposed by (IETF Transport Layer Security [TLS] Working Group, 2002). TLS is based on version 3.0 of the Secure Socket Layer (SSL) protocol. Version 1.0 of SSL was introduced in 1994 by Netscape Communications for secure data communication based on the HTTP protocol.

The TLS/SSL protocol is based on an established client-server TCP connection between two communicating computers and uses the socket interface for data communication. After the establishment of a TCP connection both computers execute the SSL Handshake Protocol in order to agree on the cryptographic algorithms and keys to be used in the actual data communication (Stallings, 2000, p. 214). In this context, X.509 certificates may be used for server and/or client authentication. For the actual data communication the SSL Record Protocol is used. Sending side protocol steps are shown in Figure 5.

Figure 5: Sending side SSL record protocol steps

Application data is divided in data fragments, which are first optionally compressed. A message authentication code (MAC) is computed for each compressed data fragment. The compressed fragment | MAC-packet is encrypted and appended with a SSL record header. Finally the SSL record header and the encrypted packet are delivered to the socket interface of the established TCP connection. On the receiving side, SSL record headers are stripped of the data received from the socket interface. Received data packets are decrypted, the integrity of decrypted data is MAC-checked, checked data is decompressed if necessary, and finally data fragments are re-assembled to application data.

Secure TLS/SSL versions of HTTP and also of other application level TCP/IP protocols have been implemented and made available to the Internet community (see Table 2).

Table 2: Secure application level protocols running on the top of TLS/SSL (Oppiger, 2000, p. 135)

Secure protocol	Port	Description
HTTPS	443	TLS/SSL protected HTTP
POP3S	995	TLS/SSL protected POP3
IMAPS	993	TLS/SSL protected IMAP4
SMTPS	465	TLS/SSL protected SMTP
NNTPS	563	TLS/SSL protected NNTP
LDAPS	636	TLS/SSL protected LDAP

Reading mail from a remote mailbox using POP3S or IMAPS protects mailbox passwords and the contents of fetched email messages against attacks based on eavesdropping on network traffic.

Web Security

There are two basic web security services that need to be considered, access level security and transaction level security (Zouridaki, Abdullah, & Qureshi, 2000). Access security is provided with solutions using firewalls that guard the network against intrusion and unauthorized use. Transaction security requires protocols that secure sensitive, private information between a client and a server using a TCP/IP connection. To ensure that sensitive information is safe while passing between a Web browser and a Web server through an Internet link, there are three Internet protocols (Karve, 1997):

1. HTTPS, the SSL Secured HTTP Protocol

2. S-HTTP, Secure Hypertext Transfer Protocol

3. PCT, Private Communication Technology

S-HTTP is an extension to the HTTP protocol to support sending data securely over the World Wide Web. S-HTTP was developed in 1994 by Enterprise Integration Technologies as an implementation of the RSA encryption standard (see Webopedia, 2002). The protocol implements a flexible choice of key management mechanisms, security policies and cryptographic algorithms by supporting option negotiation between parties for each transaction (Graham, 1995). S-HTTP allows the client and server to negotiate the strength and type of cryptographic option, supports PKI, Kerberos and pre-arranged keys. S-HTTP does not require that the client possesses a public key certificate, which means that secure transactions can take place at any time without individuals needing to provide a key as in session encryption with SSL (Karve, 1997). S-HTTP supports secure end-to-end transactions by adding cryptography to messages at the application layer. S-HTTP is thus tied to the HTTP protocol. S-HTTP encrypts each message on an individual basis.

Microsoft introduced the Private Communication Technology (PCT) protocol in its first release of Internet Explorer in 1996.

HTTPS is a protocol using HTTP on top of SSL. Although HTTPS was originally introduced by Netscape for secure HTTP communication to and from the Netscape Navigator browser, it is now a globally accepted de-facto standard for secure Web communication and supported by practically all web browsers. The use of the protocols S-HTTP and PCT is today insignificant.

When using the Netscape Navigator browser, a user can tell that the session is encrypted by the key icon in the lower-left corner of the screen. When a session is encrypted, the key, which is usually broken, becomes whole, and the key's background becomes dark blue. In Internet Explorer there appears a lock in the lower-right corner of the screen signaling that the connection is encrypted. When browsing to a secure web page, the identities of the server and of the organization that issued the server certificate can be inspected:

• In Netscape Navigator, click once on the locked lock icon

• In Microsoft Internet Explorer, double-click on the locked lock icon

Then, by inspecting the shown certificate, the trustworthiness of the server can be determined. Browser information can be found in Netscape (2002), Microsoft (2002) and Opera (2002).

The URL in the browser also shows if a web page is secured. When a secure link has been opened, the first part of the URL at the top of the browser will change from http:// to https://.

HTTPS communication must, of course, be supported by the web server. HTTPS communication normally uses port 80, but HTTPS communication uses port number 443 by default. Server level support for SSL and HTTPS is included in most web servers (see Apache Software Foundation, 2002; Microsoft Internet Information Services, 2002).

Email Security

Email traffic to and from email servers can be secured by the SMTPS protocol, the SSL protected version of the SMTP protocol. Sessions with email client programs can be secured:

• by using the SSL protected versions POP3S and IMAPS of the email mailbox access protocols POP3 and IMAP4 or

• if the email client program uses a HTTPS web page as user interface.

However, full email security requires email client program extensions for signing and/or encrypting outgoing email messages as well as for decrypting and/or signature checking incoming email messages.

The most widely used email client program security extensions are Pretty Good Privacy (PGP) and Secure/Multipurpose Internet Mail Extension (S/MIME) (see Stallings, 2000, Chap. 5). Neither PGP nor S/MIME are based on the TLS/SSL protocol, but S/MIME uses - like TLS - X.509 certificates and the PKI on the Internet for authentication purposes.

Internet Mail Consortium (IMC) is an international organization focused on cooperatively managing and promoting the rapidly expanding world of electronic mail on the Internet. The goals of the IMC include greatly expanding the role of mail on the Internet into areas such as commerce and entertainment, advancing new Internet mail technologies, and making it easier for all Internet users, particularly novices, to get the most out of this growing communications medium (see Internet Mail Consortium, 2002).

PGP is a public key encryption program originally written by Phil Zimmermann in 1991. PGP is actually a hybrid cryptosystem, combining some of the best features of both conventional and public key cryptography. PGP uses compression of data, conventional encryption/decryption with temporary session key, public key encryption/decryption and digital signing. The combination of the two cryptographic methods combines the convenience of public key cryptography with the speed of conventional cryptography. The keys, measured in bits, in public cryptography are stored in encrypted form in two key ring files. The public keys (and PGP certificates) of your recipients are added to your public key ring and your own private keys are stored, encrypted using a pass phrase, on your private key ring.

Public key digital signatures enable checking of information authenticity and integrity. They also provide non-repudiation, proof of sender. These features are fundamental features in secure communication. To keep data volumes in reasonable size, i.e., keeping the system fast, PGP uses one-way hash functions in the creation of digital signatures. The hash function produces a fixed-length output and ensures that, if the information is changed in any way — even by just one bit — an entirely different output value is produced.

An important issue within public cryptographic systems is ensuring that the correct person's keys are used. It is possible to post a key with false name and user ID. It is important that the public key to which you are encrypting data is in fact the public key of the intended recipient and not a fake. In practice you can only trust those keys which physically have been handed to you. Digital PGP certificates are used to establish trust public keys. A digital PGP certificate consists of:

• a public key,

• information about the owner, such as name, user ID, and

• one or more digital signatures.

PGP Certificates are utilized when it's necessary to exchange public keys with someone else. For small groups of people who wish to communicate securely, it is easy to manually exchange diskettes or emails containing each owner's public key. This is manual public key distribution, and it is practical only to a certain point. Beyond that, it is necessary to put systems into place that can provide the necessary security, storage, and exchange mechanisms so coworkers, business partners, or strangers could communicate if needed. These can come in the form of storage-only repositories called Certificate Servers, or in more structured systems that provide additional key management features. These are called Public Key Infrastructures (PKIs) (see Network Associates, Inc., 1999).

The digital signatures on a PGP certificate are to state that the PGP certificate information has been attested to the authenticity of the certificate as a whole; it vouches only that the signed identity information is bound to the public key. The digital signature proves that the certificate information is valid. The public key of the sender is needed to check the signature.

Validity of a signature in a signed email can also be proved if sufficient trust can be derived from the signatures in the PGP certificate of the sender. There must be at least one completely trusted signature or at least two partly trusted signatures. Every PGP user collects PGP certificates in their own public key ring.

A PGP user can add own signature to any PGP certificate in own public key ring.

A PGP user can also attach a trust level to any PGP certificate in own public key ring:

• Unknown trust in the signature of the certificate owner,

• No trust in the signature of the certificate owner,

• Marginal trust in the signature of the certificate owner (partly trusted signature), and

• Complete trust in the signature of the certificate owner.

PGP stores the attached trust value in the signature made by the PGP user on the trusted PGP certificate. A PGP user always has complete trust in own signature.

Trust propagation means that a PGP user will accept the trust levels which by him/her completely trusted certificate owners attach to other PGP certificates.

The PGP trust network in the public key ring of every PGP user (Stallings, 2000, Figure 5.7, p. 134) remains updated only if:

• An updated PGP certificate (a new signature has been added or the trust level value in a signature has been changed) is always immediately sent to the certificate owner, who then also immediately updates own PGP certificate, not only in own public key ring, but also where it is published — on own web homepage, on key servers, etc.

• Own PGP certificate is attached by the sender to a signed email message or the email contains information about how to obtain the updated PGP certificate of the sender

A trust propagation example for PGP v6.5 in Linux is described. The following symbols are used in

Peik, Goran, Krister and Kaj are PGP users.

1. Peik sends a signed message with own PGP certificate peik.asc as a file attachment to Goran

2. Goran adds PGP certificate of Peik to own public key ring. → pgp -ka peik.asc

3. Goran checks signature of signed message from Peik: invalid signature from peik

4. Goran adds own signature to PGP certificate of Peik. → pgp -ks peik

5. Goran checks again signature of signed message from Peik: good signature from peik

6. Goran extracts PGP certificate of Peik to the file peik_updated.asc. → pgp -kxa peik peik_updated.asc

7. Goran emails the file peik_updated.asc to Peik

8. Peik updates own PGP certificate in own public key ring. → pgp -ka peik_updated.asc

9. Goran attaches complete trust in Peik as a signer. → pgp -ke peik

   "Would you trust 'Peik Åström' " to act as an introducer and certify other people's public keys to you?

   (1 = I don't know (default); 2 = No; 3 = Usually; 4 = Yes, always) ? 4

10. Kaj has earlier attached complete trust in Goran as a signer.

11. Peik signs the PGP certificate of Krister, sends it to Krister, who updates his own PGP certificate in his public key ring

12. Krister extracts his PGP certificate from his public key ring into the file krister.asc, and sends the file as an attachment to a signed message to Kaj

13. Kaj first updates his public key ring with the file krister.asc

14. Kaj checks how PGP certificate of Krister is signed. → pgp -kc krister

15. Kaj notices that the PGP certificate of Krister is signed by a, for him, unknown "number ID" user (= Peik)

16. Kaj asks Krister to send the PGP certificate of the "number ID" PGP user

17. Kaj gets the missing PGP certificate of Peik and updates his public key ring

18. Kaj checks the signature of the message from Krister: good signature from krister, because PGP certificate of Krister is signed by Peik, and PGP certificate of Peik is signed and completely trusted by Goran, who is completely trusted by Kaj

PGP has some legal issues that users should be aware of, but those have not stopped PGP from becoming a de-facto standard for secure email on the Internet. These problems have caused PGP to be divided into four distinct versions (see University of London, 2002):

• The original, monolithic work, not explicitly integrated into Internet mail (PGP 2)

• A standard, which integrates PGP Classic into Internet mail, using MIME (PGP/MIME)

• Versions using non-RSA algorithms (PGP 5.0/6.0/7.0)

• IETF standards for an open PGP specification, fully integrated with MIME (OpenPGP)

There is an active IETF OpenPGP Working Group (openpgp) that provides IETF algorithm standards and formats of PGP processed objects (see IETF OpenPGP Working Group, 2002). The current work on PGP/MIME is being done in the IMC (see Internet Mail Consortium, 2002).

PGP Freeware for non-commercial use is available for many different platforms, including Windows, UNIX, MS-DOS, OS/2, Macintosh, Amiga and Atari (see The International PGP Home Page, 2002). PGP for commercial use can be found at OpenPGP Alliance (2002).

PGP, version 7.0, works with a number of different email applications using specific email plug-ins. Plug-ins are available for a number of supported email applications in Windows:

• Qualcomm Eudora

• Microsoft Exchange

• Microsoft Outlook

• Microsoft Outlook Express

• Lotus Notes

S/MIME is a secure email standard based on the unsecured email standard MIME, which is based on technology from RSA Data Security (RSA Security Inc.). S/MIME accomplishes privacy and authentication by using encryption and digital signatures. S/MIME combines traditional symmetric ciphers, public key cryptography, hashing, and public key certificates. The reason why these various methods are combined within S/MIME is efficiency. By using the strength of each method in the appropriate place, the result is a reasonably secure scheme that still runs quickly in practical use (Connell, 2001).

S/MIME is designed to work within a Public Key Infrastructure (PKI), which secures communication between two or more parties. The S/MIME standard has been developed by the Internet Engineering Task Force (IETF) and is based on the PKCS #7 (Public Key Cryptography System #7) standard for messages, and the X.509v3 standard for certificates (see Secure Solution Experts, 2002). Corresponding work is done in IETF S/MIME Working Group (2002).

S/MIME provides the following functions, described in Stalling (1998, Chap. 5):

Enveloped Data

Such data consists of encrypted content of any type and encrypted content encryption keys for one or more recipients.

Signed Data

A digital signature is formed by taking the message digest (hash) of the content to be signed and then encrypting that with the private key of the signer. The content plus signature are then encoded using base64 encoding. A signed data message can only be viewed by a recipient with S/MIME capability.

Clear-Signed Data

As with signed data, a digital signature of the content is formed. However, in this case, only the digital signature is encoded using base64. As a result, recipients without S/MIME capability can view the message content, although they cannot verify the signature.

Signed and Enveloped Data

Signed-only and encrypted-only entities may be nested. Encrypted data may be signed, and signed data or clear-signed data may be encrypted.

In S/MIME v3 — presently the latest version of S/MIME — it is still a recommendation, but no longer a precondition, for an email user to own a X.509 security certificate, in which his/her email address is included, in order to obtain all security services from a S/MIME email client extension (IETF S/MIME Working Group, 2002).

Many of the latest commercial email programs have built in S/MIME support that allows users to use the security features of S/MIME (IETF S/MIME Working Group, 2002). Microsoft Outlook and Netscape Messenger are examples of email client programs with S/MIME support. To add S/MIME support to early versions of these email client programs third-party utilities are used (see Slipstick Systems, 2002).

Microsoft Outlook 2000 Service Release 1 (SR-1) and Outlook 2002 support S/ MIME v3. TrustedMIME is an email client program plug-in with S/MIME v3 support. TrustedMIME provides support for both Microsoft (Outlook, Exchange, and Messaging) and Lotus Notes platforms. TrustedMIME is compatible with smartcards and tokens from Setec, Rainbow, Aladdin, Gemplus, Siemens, De La Rue, Oberthur, Schlumberger, and Bull, and it has support for PKCS #15, the Swedish SEIS standard, and FINEID smartcard profiles. For further information, see Secure Solutions Experts (2002).

Although PGP and S/MIME offer similar services to users, the two secure email client program extensions have very different certificate formats and can therefore not interoperate. There are many differences between X.509 certificates in S/MIME and PGP certificates. Users can create own PGP certificates, but in S/MIME users must request and be issued X.509 certificates from a Certification Authority. X.509 certificates natively support only a single name for the key's owner, PGP certificates supports multiple names. X.509 certificates support only a single digital signature for creating trust in a public key. PGP supports multiple signature validation (see Network Associates, 1999).

Secure E-commerce (SET, SEMPER, etc.)

Secure Electronic Transaction (SET), originally introduced by MasterCard and Visa, is an open encryption and security specification designed to protect credit card transactions on the Internet (Nachenberg, 1997). SET provides three services:

1. a secure communication channel among all parties involved in a transaction,

2. trust by the use of X.509v3 digital certificates, and

3. ensures privacy because the information is only available to parties in a transaction when and where necessary.

A core transaction in SET is a purchase transaction, which consists of order information (OI) encrypted by the public key of the merchant (KPubM), and payment information (PI) encrypted by the public key of the credit card issuer (KPubB). A credit card issuer will shortly be called a bank. All encrypted information is signed (a dual signature) with the private key of the cardholder (KPrivC). The purpose of the dual signature is to create a unique, unambiguous, and irreproducible association between specific order information and specific payment information. All encrypted information with the dual signature and a certificate for the public key of the cardholder (X.509_C) is sent to the merchant, who can verify the dual signature, check the cardholder certificate, and decrypt the order information. The merchant, who can't decrypt the payment information, passes the encrypted PI, a hash of OI, the dual signature, and the cardholder certificate to the bank through a payment gateway. Also, the bank can verify the dual signature, check the cardholder certificate and further decrypt the payment information. However, the bank can't find out OI from the received hash, which is needed for verifying the dual signature. After verification of the payment information the bank informs the merchant about the payment authorization.

Some transaction details have been streamlined on purpose in order to show more clearly how security and privacy are ensured in one and the same transaction. An exact but still compact description of SET is found in Stallings (2000, Chap. 7.3). A detailed description is found in Macgreogor, Ezwan, Ligouri, and Han (1997). The official web site of SET is http://www.setco.org (2001).

cardholder -----> Sig_KPrivC(E_KPubM(OI) | E_KPubB(PI) | X.509_C -----> merchant

gw(bank) <------ Sig_KPrivC(E_KPubM(OI) | E_KPubB(PI) | X.509_C<------- merchant

gw(bank) -----------> info about payment authorization -----------> merchant

Figure 7: "Cryptographic logic" of a purchase transaction in SET

The SET protocol can only be used to secure payment transactions with credit cards in TCP/IP networks. Other steps in electronic commerce (orders, confirmations, deliveries, etc.) are not supported. A project for standardization of the security architecture of value chains in electronic commerce is the SEMPER (Secure Electronic Marketplace for Europe) project of the European Union (Lacoste, Pfitzmann, Steiner, & Waidner, 1999; SEMPER Secure Electronic Marketplace for Europe, 2001). An overview of electronic payment systems is published in Oppliger (2001).

Secure Shell (SSH)

The Secure Shell (SSH) protocol is an application level protocol introduced for secure remote login in TCP/IP networks (Ylönen, 1996). Presently SSH is an established de-facto Internet security standard, which is being further developed by a dedicated Internet Engineering Task Force Security Area Working Group (IETF Secure Shell Working Group, 2002). The Working Group attempts to assure that the SSH protocol:

• provides strong security against cryptanalysis and protocol attacks

• can work reasonably well without a global key management or certificate infrastructure

• can utilize existing certificate infrastructures (e.g., DNSSEC, X.509) when available

• can be easy to deploy and take into use

• requires minimum or no manual interaction from users

• is reasonably clean and simple to implement

• will operate over TCP/IP or other reliable but insecure transport

Features of SSH include (SSH Communications Security, 2002):

• protects all passwords and data

• full replacement for TELNET, RLOGIN, RSH, RCP, and FTP

• fully integrated secure file transfer and file copying

• graphical user interface on Windows

• automatic authentication of users

• multiple strong authentication methods to prevent spoofing of user identity

• authentication of both ends of a connection

• agents enabling strong authentication to multiple systems with single sign-on

• transparent and automatic secure tunneling of X11 sessions

• secure tunneling of arbitrary TCP/IP-based applications

• encryption and compression of data for security and speed

• multiple built-in methods for password, public key, and host-based authentication

• multiple ciphers for encryption, 3DES, Blowfish, and the AES candidate TWOFISH

The SSH protocol is available in two incompatible varieties: SSH1 and SSH2 (OpenSSH, 2002). The new SSH2 protocol provides several improvements over SSH1 (Ylönen, 1996):

• much better understood and more secure protocol

• new design, which requires much less code to be run with root privileges

• totally rewritten code that improves security

• new routines for cryptography and mathematics, resulting in considerable improvements in speed

• easy to use file transfers using the integrated file transfer agent in SSH for Windows, and the SCP (Secure file copy) and SFTP (Secure File Transfer Protocol) applications on UNIX

• support for multiple public key algorithms, including DSA and Diffie-Hellman key exchange

A free version of the SSH protocol suite of network connectivity tools called OpenSSH can be found in OpenSSH (2002). OpenSSH has been primarily developed by the OpenBSD Project (see OpenBSD, 2002). The goal for the OpenSSH project is simple: all operating systems should ship with support for the SSH protocol included. The current OpenSSH release is OpenSSH 3.4, released in June 2002. It contains support for both SSH1 and SSH2 protocols. The Linux clients in the newest releases of OpenSSH support smartcard login.

The current commercial release from SSH Communications Security of SSH is release 3.2. It is based on the SSH2 protocol with enhanced performance and smartcard support, as well as with major new server features. It includes a Windows client that supports smartcard login (SSH Communications Security, 2002).

Secure Network Management

Network management and monitoring software for TCP/IP networks is usually based on the Simple Network Management Protocol (SNMP), an application level protocol. The first versions of SNMP have practically no security features. SNMP managers could neither securely authenticate themselves to managed SNMP agents nor protect the message transfer between themselves and the managed SNMP agents. The access control of managed SNMP agents was also insecure. In Version 3, secure authentication and encryption features were incorporated in the specifications for SNMP managers and secure access control features were incorporated in the specifications for SNMP agents (see IETF SNMP Version 3 Working Group, 1998). A detailed description of the security features in SNMPv3 is published in Stallings (2000, Chap. 8)

Secure DNS (DNSSEC)

The Domain Name System (DNS) is vital to the Internet, providing a distributed mechanism for resolving host names into Internet Protocol (IP) addresses and IP addresses back into host names. The DNS also supports other Internet directory-like lookup capabilities to retrieve information belonging to DNS Name Servers. Unfortunately there are many security problems surrounding IP and the protocols carried by it. The DNS is not immune to these security problems.

The accuracy of the information contained within the DNS is vital in many aspects of IP-based communications. DNS is missing services that provide data integrity and authentication for data within the DNS. This also causes security threats to other protocols that rely on DNS data for access control.

DNS Name Servers are subjected to many types of attacks (Liu, 1998):

• Denial of service

• Buffer overruns

• Discovered attacks are patched

Name servers are relatively easily spoofed. Security measures, like access lists, and mechanisms, like credibility, can make spoofing more difficult, but not impossible.

A better, more secure version of the DNS protocol is therefore needed. To address this problem IETF formed DNSSEC Working Group to develop the DNSSEC standard. The development work has been overtaken by IETF DNS Extensions Working Group, which addresses these security issues in cooperation with IETF DNS Operations Working Group, (see IETF Working Group DNS Extensions (dnsext), 2002; IETF DNS Operations Working Group (dnsop), 2002). The objective is a standard for secure DNS that provides both authentication and integrity to the information contained within the DNS. DNS SEC can accomplish both of these goals through cryptography. DNSSEC primarily relies on public key technology to create cryptographic digital signatures on information contained within the DNS ( Davidowicz & Vixie, 2000).

As defined in Davidowicz (1999), the security extensions to the DNS can be summarized into three services:

Key Distribution

Allows for the retrieval of the public key of a DNS name, to verify the authenticity of the DNS zone data, and provides a mechanism through which any key associated with a DNS name can be used for purposes other than DNS.

Data Origin Authentication

Relieves such threats as cache poisoning and zone data compromise on a DNS server.

DNS Transaction and Request Authentication

Provides the ability to authenticate DNS requests and DNS message headers, guaranteeing that the answer is in response to the original query and that the response came from the server for which the query was intended.

To support the new security capabilities of DNSSEC several new types of DNS Resource Records (RRs) were created. These records allow mapping of uniquely identified host names into IP addresses, i.e., identify an IP address for a given DNS name (a record).

The most important new types of RRs are (Davidowicz, 1999):

1. KEY RR: Used for verification of a DNS RRSet's signature.

2. SIG RR: Used for storing the RRSet.

3. NXT RR: Used to cryptographically assert the nonexistence of an RRSet.

4. CERT RR: Used to provide public key certificate within the DNS to other applications outside the DNS.

DNSSEC is still a work in progress. However, any organization that relies on the Internet should consider DNSSEC a critical component of its security infrastructure because the DNS protocol is still vulnerable to malicious misuse. Only DNSSEC, through its strong cryptographic techniques, will provide authentication and integrity to all aspects of DNS in one package (Davidowicz & Vixie, 2000).

BIND (Berkeley Internet Name Domain) was originally written at University of California at Berkeley as a graduate student project. BIND is an implementation of the Domain Name System (DNS) protocols and provides an openly redistributable reference implementation of the major components of the Domain Name System (Internet Software Consortium, 2002). The BIND DNS Server is used on most name serving machines on the Internet. Cryptographic authentication of DNS information is possible through the DNS Security (DNSSEC) extensions, defined in RFC 2535 (Nominum, 2001). (For more information concerning BIND compatibility with DNSSEC, see Internet Software Consortium (2002).

The tool package Net::DNS::SEC has DNSSEC functionality (see RIPE NCC, 2001). The DNSSEC functionality is written in PEARL and it works as an extension to the Net::DNS package (Fuhr, 2002).

Smartcard Applications

The computationally secure randomness applied to key creation in public key cryptography may cause security problems, if encryption and decryption operations use the main memory of network-connected computers. Intruders may identify keys as random areas in the main memory, since code and data are usually structured. An identified area of 1024 bits may be a private RSA key being used in an encryption or decryption operation. This is a possible security problem. That is why a private key should be stored on a smartcard together with the code of the cryptographic operations using it. Then all cryptographic operations using the key can be executed on board the smartcard and the key, after installation, will never leave the smartcard. Once installed, a private key should never leave a smartcard. The use of keys on a smartcard is protected by pin codes or biometrically by digital fingerprint comparison and/or by digital voice recognition. A numerical keypad dedicated to the smartcard is necessary for pin code security.

The characteristics of present smartcards are defined by several ISO 7816 standards (see Portal of International Organization for Standardization ISO, 2002). Smartcards exchange byte sequences — called APDU's in ISO 7816 — with smartcard readers. The file structure of many current smartcard operating systems is based on the pkcs#15 standard (RSA Security, 2002).

Smartcard applications call functions of some Application Programming Interface, when information and operations coded on smartcards are needed. Examples of such API's are implementations of the pkcs#11 standard (RSA Security, 2002) and Microsoft CryptoAPI (MSDN, 2002). Moreover, API's for smartcard applications need interface software to smartcard reader drivers. Usually such interface software is an implementation of the PC/SC Specifications, see (PC/SC Workgroup, 2002).

An example of a smartcard-based digital personal identity is the Finnish Electronic Identity Card (FINEID card) introduced in December 1999 and managed by the Finnish Population Register Centre. The implementation details of FINEID are published in Finnish Population register Centre (2002).