Crptograpy

Analysis and Assessment of Secure Mechanisms for the Building of a Secure Server Network
{ Cryptographic Systems and Applications, in particular Virtual Private Networks {
This Report has been submitted for assessment towards a Bachelor of Engineering degree in the School of Electrical, Electronic and Information Engineering, South Bank University. This report is written in the author's own words and all sources have been properly cited. Author's signature:
Name: Christine Reckziegel Course: BEng (Hons) Telecommunication and Computer Network Engineering Submission Date: 31/05/1999
Diplomarbeit
Analysis and Assessment of Secure Mechanisms for the Building of a Secure Server Network
{ Cryptographic Systems and Applications, in particular Virtual Private Networks {
Name: Christine Reckziegel Course: European Electrotechnical Studies Semester: I8ESx Supervisor: Prof. Dr. J. Lubcke Submission Date: 31.05.1999
Erklarung
Hiermit erklare ich, da ich die vorliegende Diplomarbeit in meinen eigenen Worten und nur unter Benutzung der angegebenen Quellen und Hilfsmittel angefertigt habe.
Christine Reckziegel
ii
Acknowledgements
I would like to thank Kai-Oliver Detken who initiated this nal project and supervised us. I learned a lot from him during the projet. His enthusiasm was always an incentive to equal him. In the same way, I would like to acknowledge Professor Lubcke at the Hochschule Bremen for the comments on our work and the time he spend to discuss and clarify important points. Special thanks to Dr Pervez at South Bank University who was always in contact with us via e-mail. He cared for us fantastically, especially during our year in London and I am very happy that I have meet him. Thanks as well to Dr Peng for his untiring e orts to explain Internetworking. It has been very helpful for this project. I gratefully acknowledge the help of Ariane Steglich who reviewed this report. Her grammar, spelling, and style is much better than mine. Many thanks to Thomas Krebs who had always a solution for my problems with TEXand put my pictures in their true light. I would like to thank the Team at OptiNet for o ering me the opportunity to realise this nal project. Many people from OptiNet GmbH helped to produce this nal report. Martin Reincke and Jorn Seemann helped us with the right questions. Thomas Renken had a lot of good hints and sources about Internet security. Many thanks to Christa for the tea and everything else. We are still a good team! Last, but not least, I would like to thank my whole family who gave me the chance to do my studies and especially my parents who always encouraged me.
iii
iv
Abstract
Todays information is digitally stored, electronically processed and transfered through private and public networks, such as the Internet. This means universal electronic connectivity but also hackers, viruses and electronic eavesdropping. It is therefore time that security does matter. It is time for security concepts, for rewall and Virtual Private Networks to built a Secure Server Network to protect the Intranet against the threats from the Internet and the communication via the Internet. Encryption systems are necessary for virtually private connections. These have been evaluated related to security, performance and their applications. So that the reader is able to decide which encryption systems should be used and which aspects are important to look at. Especially criteria for the selection of VPN solutions are given. But the security concept contains more then these technical aspect. Organisational and structural measures are included. Also recommendations related to security awareness like training of employees are mentioned. An overall security concept has been developed in co-operation with the client who has ordered it. Recommendations for security measures have been evaluated in relation to the special situation of the client.
vi
Contents
1 2 3 4 Introduction Aims and Objectives Deliverables Technical Background and Context 1 3 5 7
4.1 4.2 4.3 4.4 4.5
4.6
4.7 4.8
Safety and Security . . . . . . . . . . . . . . . . . . . . . . . Security Concept . . . . . . . . . . . . . . . . . . . . . . . . Evaluation of a Security Concept . . . . . . . . . . . . . . . Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Basics . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 The most important methods for secret key systems . 4.4.3 The most important methods for public key systems Encryption in di erent Layers . . . . . . . . . . . . . . . . . 4.5.1 Encryption in Layer 7 (Application Layer) . . . . . . 4.5.2 Encryption in Layer 4 (Transport Layer) . . . . . . . 4.5.3 Encryption in Layer 3 (Network Layer) . . . . . . . . 4.5.4 Encryption in Layer 2 (Link Layer) . . . . . . . . . . 4.5.5 Encryption in Layer 1 (Physical Layer) . . . . . . . . E-Mail Security . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1 Security Problems in connection with e-mail . . . . . 4.6.2 Privacy Enhanced Mail . . . . . . . . . . . . . . . . . 4.6.3 Pretty Good Privacy . . . . . . . . . . . . . . . . . . 4.6.4 S/Mime . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.5 Mailtrust . . . . . . . . . . . . . . . . . . . . . . . . Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.1 Digital Signature . . . . . . . . . . . . . . . . . . . . Key Management . . . . . . . . . . . . . . . . . . . . . . . . 4.8.1 Web of Trust . . . . . . . . . . . . . . . . . . . . . . 4.8.2 Trust Centre or Certi cation Authority . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
7 9 11 13 14 21 25 28 28 29 29 30 30 31 31 32 32 33 34 34 35 35 36 36
vii
CONTENTS
4.9 Virtual Private Networks . . . . . . . . . . 4.9.1 Why do organisations need VPNs? 4.9.2 Advantages of VPNs . . . . . . . . 4.9.3 Typical VPN Implementations . . . 4.9.4 Tunneling . . . . . . . . . . . . . . 4.9.5 IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 38 38 39 42 47
5 Technical Approach
5.1 Security Concept . . . . . . . . . . 5.1.1 Risk Analysis . . . . . . . . 5.1.2 Security plan . . . . . . . . 5.1.3 Disaster Plan . . . . . . . . 5.2 Introduction of a Security Concept 5.3 Criteria for VPN solutions . . . . . 5.4 VPN Products . . . . . . . . . . . . 5.4.1 NCP . . . . . . . . . . . . . 5.4.2 3Com . . . . . . . . . . . . 5.4.3 CheckPoint . . . . . . . . . 5.5 Evaluation of a VPN solution . . . 6.1 Risk Analysis . . . . . . . . . . 6.1.1 Identifying Assets . . . . 6.1.2 Identifying Threats . . . 6.2 Security Plan . . . . . . . . . . 6.2.1 Technical Measures . . . 6.2.2 Organisational Measures 6.2.3 Structural Measures . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
53
53 53 54 54 55 56 58 58 59 60 61 63 64 64 65 65 70 82
6 Results
63
7 Discussion 8 Conclusion and Recommendations for Further Work A Secure Remote Access B Internet Threats
A.1 RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 A.2 TACACS+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 B.1 Protocol depending Security Risks . B.1.1 Password sni ng . . . . . . B.1.2 Packet manipulation . . . . B.1.3 Re-routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83 85 91 93
93 93 93 93
viii
Final Report
B.1.4 Replay-Attack . . . . . . . . . B.1.5 IP-Spoo ng . . . . . . . . . . B.1.6 ARP and ICMP Attacks . . . B.2 Service speci c Security Risks . . . . B.2.1 E-mail and Usenet-News . . . B.2.2 Telnet . . . . . . . . . . . . . B.2.3 FTP . . . . . . . . . . . . . . B.2.4 WWW . . . . . . . . . . . . . B.2.5 DNS . . . . . . . . . . . . . . B.2.6 Finger . . . . . . . . . . . . . B.2.7 SNMP . . . . . . . . . . . . . B.3 Security Risks from Active Elements B.3.1 ActiveX . . . . . . . . . . . . B.3.2 Java . . . . . . . . . . . . . . B.3.3 Plug Ins . . . . . . . . . . . . B.3.4 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CONTENTS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 94 94 94 94 95 95 95 96 96 96 96 96 97 97 97
C D E F G
VPN Products Project Planning Questionnaire Abbreviations Glossary
98 101 105 109 113
ix
CONTENTS
List of Figures
4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 6.1 6.2 D.1 D.2 Security Concept . . . . . . . . . . Vernam cipher or one-time-pad . . Transposition cipher . . . . . . . . Di e-Hellman key exchange . . . . Intranet VPN . . . . . . . . . . . . Remote Access VPN . . . . . . . . Extranet VPN . . . . . . . . . . . . Tunneling of ISPs . . . . . . . . . . Tunneling over several ISPs . . . . End-to-End Tunnel . . . . . . . . . Router-to-Router Tunnel . . . . . . Tunnel to remote VPN LAN clients IPSec Packet Structure . . . . . . . Encryption Transmission Modes . . Firewall Concept . . . . . . . . . . IT Security Management . . . . . . Initial Plan . . . . . . . . . . . . . Modi ed Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 16 17 26 40 41 41 43 44 45 46 47 48 49 66 71 103 104
xi
LIST OF FIGURES
The modern world of information and communication needs more and more the help of information technology (IT) to manage the growing amount of electronic data. Numerous work processes, both in public and in industry, are electronically controlled. As a result, many organisations depend on perfectly operating IT and communication systems. Information is digitally stored, electronically processed and transfered through private and public networks, such as the Internet. The Internet is a low-price possibility to connect mobile workers, business partners, suppliers and customers worldwide. However, the need for security of this sector of communication is closely related with the oppertunity to get developed. Availability is not enough, the user needs the certainty that his data transmission is secure. Especially for pecuniary transactions which will take place more and more often via the Internet, IT security must become an integral part and develop from security systems to secure systems. Therefore the awareness for security must grow. (Bundesministerium fur Sicherheit in der Informationstechnik, 1998) IT systems have changed since the time when they were mainframes in security rooms with access control, strict rules, and regulated course of events. Modern IT systems realise new concepts such as client-server architecture, decentralisation etc. whereas security often only gets low priority. A new security policy is necessary: data has to be considered to be economic good. (Pohlmann, 1998) The Internet has obtained a high complexity but in its development security has been neglected. As a result of globalisation and teleworking, organisations actually need the Internet but they also need to protect their communication via the Internet and most of all they have to protect their Intranet. The former can be realised with cryptographic methods, the latter with rewalls. Cryptographic methods are mathematical transformations which make it impossible to reconstruct the original plain text from the cipher text without knowing the key. Virtual Private Networks (VPNs) are one of the possible applications which use cryptographic methods. Another example is digital signature which is a method for authentication. (Schmidt, 1998) A lot of companies are connected to the Internet without the knowledge of how to secure their local network and how to use the Internet as a cost-e ective transmission medium with the required security level. Therefore a security concept should be developed for a company which plans to use the Internet. This company will appear as \the organisation" in the text because of the con dential data which this report may contain.
Chapter 1 Introduction
CHAPTER 1. INTRODUCTION
The security concept is written as a group work with Christa Eekho . The following sections are done in co-operation with her: 4.1 Safety and Security 4.2 Security Concept 4.3 Evaluation of a Security Concept 5.1 Security Concept 6 Results 7 Discussion 8 Conclusion and Recommendations for further work (partly together)
Chapter 2 Aims and Objectives

The main aim of this group work is to develop a security concept for an organisation. A security concept in general has to consider a lot of di erent aspects from access control over secure data transmission and rewall concepts, structural measures such as security rooms up to organisational security tasks such as dealing with regulations for user access. Safety precautions preventing from mechanical destruction like re etc. are also part of an overall security concept. However, our security concept only takes some of these aspects into account, for example a rewall-concept, secure remote access, secure data transmission or a reliable network. The latter includes some other aspects such as dealing with viruses and emergency plans. Within the organisational measures, the emphasise lies on the consruction of a structure with security o cer and security team etc. The structural measure against mechanical destruction has been left out in this work, because the security concept mainly deals with computer security and the regulations for this sector. In my Final Year Project I concentrate on all aspects of secure data transmission dealing with encryption. This also includes authentication for data transmission or e-mail. Therefore cryptographic systems for secure transmission via public networks should be analysed with regard to correct ful lment of the demand for security and performance. Cryptographic systems are used in many applications. One of them is the already mentioned Virtual Private Network (VPN). In this nal year project, products which are available on the market shall be compared. Criteria for analysing methods and products should be found out. The outcome of this analysis should be some general recommendations, but the emphasis will be on the recommendation related to the furnished facts and demands of one special organisation. Therefore the analysis should be able to provide assistance in deciding which product may be a perfect t. In order to achieve this goal in a satisfying way, it is necessary to get the right information
CHAPTER 2. AIMS AND OBJECTIVES

about the organisation. It is therefore very helpful to use a questionnaire which will be lled out by the person responsible for the project within the organisation. This questionnaire for a security concept has also to be developed in this project. The security concept shall contain the actual state of security risks and existing leaks and give some recommendations on the basis of the given facts. This will be demonstrated exemplarily for one special organisation. After elaborating the concept, the recommendations shall be realised as agreed with the client. The realisation also includes the testing of the single components and of the whole system in order to guarantee its security. The testing will be done with adequate tools.
Chapter 3 Deliverables
The deliverables for this nal year projet will be the nal report, a questionnaire and the security concept for the German customer. The latter will only be handed in for examination and discussion but will not be published because of the con dentially information that it contains. The most important aspects will appear in the results. The facts will be a little bit distorted for security reasons but are comparable to the original data. The questionnaire is given in Appendix E. Final Report Questionnaire Security Concept
CHAPTER 3. DELIVERABLES
Chapter 4 Technical Background and Context

This chapter should give background information to security aspects. First there is a short description what security and a security concept is. Then measures for protection of communication with encryption are described. The intension is that the reader gets an idea of the di erent concepts for encryptions like secret and public key encryption systems and that he can decide which algorithm is secure enough for his special purpose. The most important point is the key length which may be variable in some applications. The reader should be able to estimate which key length for which algorithm is secure. The algorithms are the basis for the next sections about applications of encryption. The main subject here is the section about Virtual Private Networks (VPNs). The concept of VPNs is described generally and gives criteria to chose the right VPN solution for a special con guration. Some products are described in more detail but they only give an idea what di erent concepts are realisable with VPNs.
4.1 Safety and Security

For developing a security concept the rst question is: What is Security? An easy question, everyone will nd an answer to it. But all the answers to this question will be very di erent, because everyone understands something di erent by security. In ADP terms this includes con dentiality, access control etc. as well as natural disasters or terrorist attacks. The German expression \Sicherheit" contains both security and safety. The di erence between security and safety is the intention behind it. Security measures are countermeasures against intentional
CHAPTER 4. TECHNICAL BACKGROUND AND CONTEXT

attacks for example monitoring, manipulating and destruction of information. Safety precautions are measures against unintentional incidents for example destruction due to forces of nature or technical failures. In the following text we uses security for both expressions. Security is a very subjective thing. Some people for example are only feeling secure if the door is locked with half a dozen locks and others do not bother about locking the door at all. It is the same with companies and their \feeling" about security. Some companies trust their employees. They do not control them and trust in their sense of doing the right thing to protect the valuable information of the company. Others do not trust their employees at all. They install cameras to control them, setting up strict rules and regulations to ensure that valuable information is protected. Security is very individual and thus each company will need an individual security concept. The rst time when companies think about security is often when they get a connection to the Internet. They hear a lot about all the hackers and think they have to protect themselves. Often it is forgotten that the connection to the Internet o ers not the only ability to theft information and resources. It is no good if there is a rewall to protect the internal network but just anybody can walk into the o ce, into the computer centre and take away a server. There is a need for an overall security concept which does not only take into account the digital stored information but also all the information on paperwork, facsimile and phone. All information has to be protected against loss, damage etc. To compile a security concept it has to be known in which danger the information is and how likely it is that an incident occurs. The following list of security aspects of information can help to identify threats and to decide which kind of dangers have to be paid special attention to and which can be neglected. (Gar nkel and Spa ord, 1996, p.24 ) Con dentiality Protecting information from being read or copied by anyone who has not been explicitly authorised by the owner of that information. This type of security includes not only the information in toto, but also the protection of individual pieces of information that may seem harmless by themselves but that can be used to infer other con dential information. Data Integrity Protecting information (including programs) from being deleted or altered in any way without the permission of the owner of that information. Information to be protected also includes items such as accounting records, backup tapes, le creation times, and documentation.
Final Report
Availability
4.2. SECURITY CONCEPT
Protecting services so they are not degraded or made unavailable (crashed) without authorisation. If the system is unavailable when an authorised user needs it, the result can be as bad as having the information that resides on the system deleted. Authentication Authentication is a very important point to realise authorisation. Authentication is the process of proving that a subject (e.g. a user or a system) is what the subject claims to be. Access Control Restrictions on the ability of a user to use a system or an object (e.g. a le) in that system. Such control limits access to authorised users only. Non Reputation Non reputation prevents either sender or receiver from denying a transmitted message. Thus, when a message is sent, the receiver can prove that the message was in fact sent by the alleged sender. Similarly, when a message is received the sender can prove that the message was in fact received by the alleged receiver. Auditing Auditing is used to monitor actions of unauthorised users and authorised users who sometimes make mistakes, or even commit malicious acts. In such cases, you need to know what was done, by whom, and what was a ected. Consistency Making sure that the system behaves as expected by the authorised users. If software or hardware suddenly starts behaving radically di erently from the way it used to behave, especially after an upgrade or a bug x, a disaster could occur.
4.2 Security Concept

To develop an individual security concept it has to be clear how important the di erent security aspects are. To see how much security is needed, rst there has to be a risk analysis. This will give the total risk which can be minimised by certain actions which are shown in Figure 4.1 on page 10.

Total Risk
Remaining Risk
Limiting of Damage
DISASTER PLAN SECURITY PLAN
SECURITY POLICY SECURITY CONCEPT
Figure 4.1: Security Concept Risk avoidance With risk avoidance a lot of damage can be prevented. For example all services (especially Internet services) that are not needed should not be o ered. Which risks can be avoided is written down in the security plan. Security measures If dangerous things or services are needed they can be made more secure with security measures. Which security measures has to be implemented is written down in the security plan. Limiting of damage Damage can often be limited if everybody knows, what to do and which steps to take if an incident occurs. This is written down in disaster plans.
Security Measures
10
Risk Avoidance
Final Report
Remaining risk
4.3. EVALUATION OF A SECURITY CONCEPT
The remaining risks are the risk the company has to face after reducing the total risk with risk avoidance, security measures and limiting of damage. Sometimes the risk which remains after taking the above steps can be further reduced with insurance. The security concept contains the risk analysis and all measures to minimise the risk. Sometime it can even be necessary to develop a more common security policy which then can be distributed to co-operated companies. The detailed security concept contains two parts: The risk analysis and the security policy. The security policy document contains the security plan and the disaster plan. In the security plan it is written down, which measures should be taken to avoid and to minimise the risk. The disaster plan contains the backup plan, the recovery concept, the restart plan. So it contains everything that is needed to recover from an incident with as less damage as possible. While writing the security concept one has to be aware of certain things. There are certain parts of the security concept which will be a guideline for the employees. So it should be written positive and don't treat them as criminals. If the company could trust their employees before the company got connected to the Internet there is no reason to change this thrust in the employees, when connected to the Internet. The employees should be involved into the security concept as much as possible. They have to understand that security is everybody's matter. If the employees do not understand the necessity of the security measures they will boycott them consciously or unconsciously. It is the best to inform the employees instead of keeping everything a secret. Security through obscurity is normally no good idea. Someone will try to nd out sooner or later. While developing the security concept common sense has to be used. Not everything can be made secure. The task is to minimise the risk and not to let it vanish which is not possible. There is nothing like a 100% security. There are risks one has to live with. So the e ort to develop the security concept and to realise it should be reasonable.
4.3 Evaluation of a Security Concept

For the client who orders a security concept it is nearly impossible to say whether the concept is good or not. The problem arises before a client who needs a security concept does not know which company should be put in charge of it, because he does not know what criteria a company must ful l to be able to produce a good security concept. The evaluation of organisational measures is nearly impossible. They can be only proofed against logical mistakes or recommendations which can not be realised in the client's company because of their preconditions. But the technical measure
11

for the IT system can be evaluated but it is di cult. The raising number of security systems which are available on the market shows that there is a huge number if possible solutions. But users and persons running a system are rattled about the quality of these measures. Trust is an important precondition for the successful operation of security measures in practice. If there is no trust, existing mechanisms will not be employed, because of the conviction that they are useless. It is important that the user has trust in the quality of the security measures but how can this be done? If the user does not want to trust in the declaration of the manufacturer he has to inspect the security measures himself or he needs a neutral, trustful authority { this is comparable to the German \TUV" for cars { to evaluate objectively the quality of security mechanisms. This kind of evaluation is known in the military sector of the USA as the \Orange Book". In the Orange Book di erent level of security and di erent classes are de ned. These classes are:
D | Minimal Protection C | Discretionary Protection B | Mandatory Protection A | Veri ed Design

The Orange Book describes all demands for military systems, therefore its criteria are not accepted in the civil sector. Especially in the civil sector certi cates from neutral authorities can make a contribution for the application of security measures. Normally the user can not evaluate the IT system himself, because the costs for evaluation are in no justi able relation to the costs for the whole IT system. Besides this the criteria in the commercial sector are less strong than in the military sector. New evaluation criteria for the commercial sector are developed in Europe. The most important activities are the \Grune Buch" (Green Bock) of the Bundesministerium fur Sicherheit in der Informationstechnologie (BSI) and the EG-ITSEC. The Green Bock is based on the Orange Book and supplements the following aspects: The orientation is more to the private and commercial market. The Green Bock is for civil users in industry. An extension of the security idea: criteria for aspects of con dentiality, integrity, and availability of IT systems are of equal importance.
12
Final Report
4.4. CRYPTOGRAPHY
But these last three aspects are not enough to meet the whole spectrum of security demands which are necessary for modern information communication systems. In 1990 the ITSEC published the Information Security Evaluation Criteria which is based on works from France, Germany, Netherlands, and Great Britain. ITSEC is in uenced by the Green Bock but emphasises the questions of quality. It di ers between IT products and IT systems but some points are still missing: aspects of data protection like unobservability and pseudonymity anonymity and originality concepts for combination and integration of certi cated systems concepts for accreditation of certi cated systems in a concrete environment and for repeated controlling of the orderly system employment. criteria for the evaluation of hardware The trend of security systems goes towards reliable information systems. This means that the development is away from security systems towards secure systems which will be realised by the integration of security functions into hardware, operating systems, and applications. The most important e ect of these criteria is that standardised guidelines for the building of secure systems are valid all over Europe. Manufactures will o er products with security functions which are based on standards certi cated from a neutral authority. Standard are a basis on which user and manufacturer can rely, but it is no universal remedy for all open questions. There is still the problem of accreditation of certi cated systems in a concrete environment and the evaluation of combinations of di erent certi cated systems. In future, as well, users will need systems which are specially tailored for their security requirements and o er individual solutions.
4.4 Cryptography
When talking about cryptography it turns out that it has a lot of di erent meanings for the people. Children for example play with toy ciphers and secret languages. However, these have nothing to do with real security and strong encryption. Strong encryption is the kind of encryption that can be used to protect information of real value against criminality, multinational corporations, and major governments. Strong encryption used to be only military business however, in the information society of today it has become one of the central tools for maintaining privacy, trust, access control, electronic payments, corporate security, and countless other elds. Cryptography is no longer a military concern that can be
13

ignored. It is time to demystify cryptography and make full use of the advantages it can provide for the modern society. In the following, basic terminology and the main methods of cryptography will be presented. Afterwards the most common methods in the Internet will be shortly described especially in relation to their use in di erent applications. One of these applications is Virtual Private Networks (VPNs) which will be described in more details. How cryptographic systems are used for digital signature will be shown and the problem of secure key management will be explained.
4.4.1 Basics
Cryptography1 is the art of the science of encryption and decryption. Encryption transforms original information, called plaintext, into unintelligible information, called cipher or ciphertext. Decryption is the reverse process which transforms the ciphertext back into the original plaintext. Encryption and decryption methods are mathematic transformations which are called cryptographic or encryption algorithms. Sometimes cipher is also used for names of encryption algorithms. (Russell and Gangemi Sr., 1991, p.169 ) Cryptography is also the art of the science of designing encryption algorithms, whereas cryptoanalysis is the art of reading the ciphertext without knowing the encryption key. The proceeding is known as codebreaking or compromising. The aim for every cryptographer is to develop an algorithm for which the cryptoanalysis gives an outcome of no practical use. This doesn't mean that cryptoanalysis is impossible but that it would take too long (in the meantime the information would have become worthless) or that it would be much more expensive then the original value of the information. Each new algorithm must be tested against all known methods of cryptoanalysis. A special emphasis is always given to the security of an algorithm. Only then other criteria such as fastness for encryption and decryption and ease of implementation in hardware will be considered. The aim is to make the algorithm so secure that only a brute-force attack (see Section 4.4.1.1) is possible. Therefore it is important to know something about cryptoanalysis and possible attacks. (Wobst, 1997, p.52) \Before computers cryptography consisted of character-based algorithm. The primary change is that algorithms work on bits instead of characters. Things are more complex these days, but the philosophy remains the same" (Schneier, 1996). Di erent algorithms still substitutes bits by other ones or transposes them. Most successful algorithms combine elements of substitution and transposition. These basic principles will be explained in Section 4.4.1.2.
1
from the Greek kryptos meaning \hidden," and graphia, meaning \writing"
14
Final Report
4.4. CRYPTOGRAPHY
4.4.1.1 Cryptanalysis and Attacks on Cryptosystems

Cryptanalysis is the art of deciphering encrypted communications without knowing the proper keys. There are many cryptoanalytical techniques. Some of the more important ones for a system implementor are described below. anything about the contents of the message, and therefore has to work from ciphertext only. In practice, it is quite often possible to make guesses about the plaintext, as many types of messages have xed format headers. Even ordinary letters and documents begin in a very predictable way. It may also be possible to guess that some ciphertext block contains common words.
Ciphertext-only attack: This is the situation when the attacker does not know
Known-plaintext attack: The attacker knows or can guess some parts of the plaintext from the ciphertext. The task is to decrypt the rest of the ciphertext blocks using this information. This may be done by determining the key used to encrypt the data, or via some shortcuts.
crypted with the unknown key. The task is to determine the key used for encryption. Some encryption methods are extremely vulnerable to chosen-plaintext attacks. When such algorithms are used, extreme care has to be taken to design the entire system so that an attacker can never have chosen plaintext encrypted. protocols (see Section 4.4.1.4. The idea is that when two parties are exchanging keys for secure communications, an adversary puts himself between the parties on the communication line. The adversary then performs a separate key exchange with each party. The parties will end up using a di erent key, each of which is known to the adversary. The adversary will then decrypt any communications with the proper key, and encrypt them with the other key for sending to the other party. The parties will think that they are communicating securely, but in fact the adversary eavesdrops everything.
Chosen-plaintext attack: The attacker is able to have any text he likes en-
Man-in-the-middle attack: This attack often occurs when using key exchange
Timing Attack: This very recently developed attack is based on repeated measurement of the exact execution times of modular exponentiation operations. It is relevant to at least some cryptographic algorithms for example RSA (see Section 4.4.3.2), Di e-Hellman (see Section 4.4.3.1), and Elliptic Curve methods. More information is available in (Schmeh, 1998, p.95). There are many other cryptographic attacks and cryptanalysis techniques. However, these are probably the most important ones.
15
4.4.1.2 Substitution and Transposition

In the encryption methods which uses substitution, every character of the plaintext is replaced by another character in the ciphertext. For the decryption, the reverse substitution has to be performed. The easiest substitution is given when each character is replaced by exactly one other character. This encryption can be broken with statistical methods because in every language characters appear with a particular probability. The homophone substitution is an improvement in which each character can be replaced by di erent characters. This is meant to compensate the statistical distribution. But there are still some regularities and substitution has no chance against known-plaintext attacks (where parts of the plaintext are known in addition to the ciphertext). The reason for this is because there are certain words that are expected in the text. Poly alphabetical cipher systems use a key which can be as in the case of Vignere cipher a word. The original text and the key-word are added character by character. If the key-word is shorter than the original text then it will be repeated. This method can also be easily broken because of the normally short key length. If the key is as long as the plaintext then this is called Vernam cipher and if the the key is a random sequence it is called one-time-pad.
ALONGANDRANDOMKEY SHORTERPLAINTEXT ================ SSDFZEFSDAVQIQIX
Figure 4.2: The characters of the key and the plaintext are added: A+S=S, 0+19=19 It can be proved that a truly random key provides an absolutely secure method. As this is an easy and secure system, why should we look for other ones? Because there are also some disadvantages: The key is as long as the message, this doubles the amount of data. The key must be known by sender and receiver the key must be transmitted somehow to the receiver and then we have the same problem, because it makes no di erence whether to send the message or the key. (More about changing keys in Section 4.4.1.4.) It is very di cult to produce big amounts of truly random keys. (A section about the problems of random number generators can be found in (Schmeh, 1998).) Because of this disadvantages one-time-pads have no practical use for transfering messages.
16
Final Report
4.4. CRYPTOGRAPHY
Transposition is another type of cipher where the order of the characters is rearranged but does not change the actual characters. An example is simple columnar transposition cipher where the plaintext is written horizontally with a certain width. The ciphertext can be read vertically as shown in Figure 4.3 on page 17. Plaintext: YOU CAN FIND THE GOLD IN THE HOLE
YOUCANFI NDTHEGOL DINTHEHO LE
Ciphertext: YNDLODIEUTNCHTAEHANGEFOHILO Figure 4.3: The plaintext is written horizontally and the ciphertext can be read vertically Transposition can be broken by statistical methods because the pairs of successive characters in a normal language have typical likelihood. Other pairs do occur much less often. If the messages is short, some characters may not appear thus it is possible to say which words do not exist in the text. An improvement on this cryptographical method is to put the ciphertext through a second transposition cipher. There are a lot of even more complicated transposition ciphers, but computers can break almost all of them. A disadvantage of transposition is the high demand for memory, therefore substitution is far more common.
4.4.1.3 Di usion and Confusion

Di usion is the spreading of information belonging to the plaintext over the ciphertext. The easiest method for di usion is transposition. Confusion is the camou age of the connection between plaintext-characters and ciphertext-characters. The easiest method for confusion is substitution. Di usion without confusion is very easy to break. A very e ective version of di usion is the avalanche-e ect for block cipher (see Section 4.4.1.5): Each bit of the ciphertext should depend on each bit of the plaintext and of the key. In a good algorithm, the changing of a bit happens with a probability of 50%, all deviations from this run the risk to be deciphered by di erential cryptoanalysis. This and other methods of cryptoanalysis are explained in (Schneier, 1996).
4.4.1.4 Secret or Public key

Elements of cryptographic systems are the algorithm and the key. If there is no key the algorithm has to be the secret. When this is the case everyone who wants
17

to interchange messages with more than one other person needs di erent algorithms, one for each partner. Everyone then will have to write his own algorithm. Using o -the-shelf hardware or software would mean that everyone can buy it and eavesdrop the encrypted messages. In modern cryptography therefore keys are used. The range of possible keys is called the keyspace. The whole secret lies in the key. Usually good algorithms are published, analysed, and tested by everyone who thinks he is a crypto analyst. There are two general types of key-based algorithms: secret key and public key systems. Algorithms which use a secret key are called symmetric because they use the same key for encryption and decryption or a decryption key which can be calculated from the encryption key, respectively. Secret key systems normally use di erent algorithms for encryption and decryption. Sender and receiver agree on one key and all messages then can be encrypted and decrypted with this key. So this key must be absolutely secret and only be known by the sender and the receiver. It is important to periodically replace the keys. In practice the term is known as \perfect forwarding secrecy," means that the keys are refreshed on a very frequent basis. If { for what reason ever { anyone gets a key, he will only have a very small window of access which ensures a greater level of privacy. Key replacement is also done for another reason: the more keys are used to encrypt bulk data, the greater the chance to utilise non-brut-force attacks which are more e ective than brute-force attacks. For a small number of keys this method of agreeing and refreshing keys may be acceptable, but when the number of keys increase it quickly becomes very di cult to manage. The problem is that you need one key for each communication and if there is a group of 100 users who wish to exchange encrypted messages amongst themselves there would be 4950 keys to manage. Public key algorithms instead use two di erent keys: one for encryption, often called public key, and one for decryption, often called private key. When it comes to digital signatures (see Section 4.7.1), it works the other way round: a message is encrypted with the private key and decrypted with the public key. Very important for public key systems is the point that the private key is truly secret and can not be calculated from the public key. Because of the reason that there are two di erent but mathematically related keys public key systems often use the same algorithm for encryption and decryption. The public key system works as follows: a private key and a related public key are generated, then the public key is sent to the person who wants to send a message. This person then encrypts the message with the public key. Only the person with the private key can decrypt the message. This system works for receiving messages, but not for sending messages. However, the advantage is clear: no secret key has to be sent to the receiver { it can remain all the time on the own \secure" computer { and the public key can not be compromised because it is already known. The only problem which remains is that there are only a
18
Final Report
4.4. CRYPTOGRAPHY
few principles known that o er secure and practical algorithms. The algorithm has to show some characteristics: it needs an easy function for encryption with a very complex revers function for decryption. Furthermore this complex revers function must have a \hidden short cut" which can be used as a key. Another demand is that the private key can not be calculated from the public key. Functions which are relatively easy to compute but which shows a complex revers function are called one-way functions, and if there is a hidden short cut they are called trapdoor one-way functions. The following di erences between public key and private key systems and some more points can be found in (Schmeh, 1998, p.99). All known secret key algorithms use simple mathematical functions. However, public key algorithms can only be realised with complex mathematical functions. It is hard to nd new public key algorithms, whereas secret key algorithms can be developed in any number. In practical use the most important fact depends on the rst point: public key algorithms require more computer performance than secret key algorithms. This can be seen by the comparison of RSA (see Section 4.4.3.2) and DES (see Section 4.4.2.1), RSA is 1000 times slower than DES. Public key algorithms are more susceptible to faulty implementation then secret key algorithms because of their complexity. In secret key algorithms the key can be represented as a sequence of bits. In public key algorithms the key can be represented as a big number. This leads to xed key length in most of the secret key algorithms (e.g. 64 Bit with DES, 128 with IDEA) and variable key length in public key algorithms (this means that the used number has no xed quantity). Modern cryptographic algorithms cannot be executed by humans. Strong cryptographic algorithms are designed to be executed by computers or hardware devices. In most applications, cryptography is done by computer software. Generally, symmetric algorithms are much faster in operation on a computer than asymmetric ones. In practice both are often together in use, so that a publickey algorithm is used to encrypt a randomly generated encryption key, and the random key is used to encrypt the actual message using a symmetric algorithm. This method is called hybrid encryption.
19
4.4.1.5 Stream cipher and block cipher

Symmetric algorithms can be divided into stream ciphers and block ciphers. Stream ciphers encrypt a stream of plaintext with a cipher key that encrypts one single bit after one single bit to produce a ciphertext. These ciphers can only use confusion even though some feedback methods also uses di usion. Block ciphers take a number of bits (typically 64 bits in modern ciphers), and encrypt them as a single unit. Block ciphers use confusion and di usion.
4.4.1.6 Strength of Cryptographic Algorithms

In theory, any cryptographic method with a key can be broken by trying all possible keys in sequence. If using brute force and trying all keys is the only option, the required computing power increases exponentially with the length of the key. A 32 bit key takes 232 (about 109) steps. This is something any amateur can do on his home computer. A system with 40 bit keys (e.g. US-exportable versions) takes 240 steps { this kind of computing power is available in most universities and even smaller companies. A system with 56 bit keys (such as DES which is described in Section 4.4.2.1) demands a substantial e ort, but is still quite easily breakable with special hardware. The cost of the special hardware is substantial but easily within reach of organised criminals, major companies and governments. Keys with 64 bits are probably breakable now by major governments, and will be within reach of organised criminals, major companies, and lesser governments in a few years. Keys with 80 bits may become breakable in future. Keys with 128 bits will probably remain unbreakable by brute force for the foreseeable future. Even larger keys are of course possible. However, key length is not the only relevant issue. Many ciphers can be broken without trying all possible keys. In general, it is very di cult to design ciphers that could not be broken with less e ort by using other methods. One should generally be very wary of unpublished or secret algorithms. Quite often the designer then is not sure of the security of his algorithm, or its security depends on the secrecy of the algorithm. Generally, no algorithm that depends on the secrecy of the algorithm is secure. Particularly in software, it is easy to disassemble and reverse-engineer the algorithm. Experience has shown that a vast majority of secret algorithms that have become public revealed to be pitifully weak in reality. The key lengths used in public key cryptography are usually much longer than those used in symmetric ciphers. The problem of public key systems is not that of guessing the right key, but deriving the matching secret key from the public key. Here are some examples to give some idea of the complexity: in the RSA cryptosystem (see Section 4.4.3.2), a 256 bit modulus is easily factored by ordinary
20
Final Report
4.4. CRYPTOGRAPHY
people. 384 bit keys can be broken by university research groups or companies. 512 bits is within reach of major governments. Keys with 768 bits are probably not secure in the long term. Keys with 1024 bits and more should be safe for now unless major algorithmic advances are made in factoring keys of 2048 bits are considered by many to be secure for the next decades. It should be emphasised that the strength of a cryptographic system is usually equal to its weakest point. No aspect of the system design should be overlooked, from the algorithm choice to the key distribution and usage policies. The next two sections list commonly used cryptographic algorithms and methods, and give references to implementations and textbooks.
4.4.2 The most important methods for secret key systems

Secret key algorithms use for both encryption and decryption the same key (or two that are easily derivable from each other).
4.4.2.1 Data Encryption Standard (DES and Triple DES)

The Data Encryption Standard (DES), known as the Data Encryption Algorithm (DEA) by ANSI and the DEA-1 by the ISO, has been a worldwide standard for over 20 years. It has been developed in the early 1970s by IBM (USA) and it was the rst modern secret key algorithms that was secure, known in all details and royalty-free. In 1976 the National Bureau of Standard (NBS), now the National Institute of Standards and Technology (NIST), adopted DES as a federal standard after consulting the National Security Agency (NSA). The NSA reduced the key length from originally 128-bits to 56-bits and was also suspected of having modi ed the algorithm in order to install a trapdoor. It was the rst NSA-evaluated cryptographic algorithm which has been made public and today there are still some design criteria for the internal structure, the so called S-boxes (the S-boxes realises substitution), which are classi ed. The circumstances of developing the DES were very strange. Over the years it became clear that the developers of the DES did a very good job. The recent work in cryptoanalysis shows that the DES is also protected against di erential cryptoanalysis which is guaranteed by the substitutions in the S-Boxes. And exactly the numbers of the S-boxes which de ne the rules for the substitution were changed by the NSA to improve the protection against di erential cryptoanalysis. This means that the NSA knew about di erential analysis 20 years earlier than the public research. They did not want to publish the design criteria because in that case di erential cryptoanalysis would have been known to the rest of the world and their competitive advantage would have been weakened. See (Schneier, 1996) for details about the story and the algorithm.
21

Some important points about DES: The key length is 56 bits (plus eight bits used for parity check only). The algorithm is a block cipher which transforms 64-bit blocks of plaintext in 64-bit blocks of ciphertext. DES is a symmetric cipher. The algorithm and the key for encryption and decryption is the same, except some minor di erences in the key schedule. The fundamental construction block is a substitution followed by a permutation. This is known as a round. DES has sixteen rounds. The algorithm is optimised for hardware implementation and there especially for the hardware from the 1970s. All operations are reduced to bitwise shifting, xed permutations and XOR (exclusive or) operations. The security aspects of DES: An expansion permutation allows one bit to a ect two following substitutions. The dependency of the output bits from the input bits spreads very fast. This is called avalanche e ect (see Section 4.4.1.3). The permutation box (P-box) ensure that each bit of plaintext goes through another substitution box (S-box) in each of the sixteen rounds. The S-boxes add non-linearity and protection against di erential analysis to the algorithm. Each round uses a 48-bit subkey made out of the 56-bit key. After shifting the two 28-bit halves of the key, 48 bits are selected with a compression permutation. Because of this shifting each changing of a key-bit in uences all bits of the ciphertext after a few rounds. Breaking the DES can be done with di erent methods such as di erential or linear cryptoanalysis. However di erential analysis is only with a chosen-plaintext attack more e cient than a brut-force attack (see Section 4.4.1.1). This is due to the number of rounds:"DES with any number of rounds fewer than sixteen could be broken with known-plaintext more e ciently than by a brut-force attack. Certainly brut-force is much more likely attack, but it is interesting that the algorithm has exactly sixteen rounds." (Schneier, 1996, p.284). Linear cryptoanalysis requires less known-text than di erential cryptoanalysis requires chosen-text to be more e cient than brut-force. But still the amount of data is to big for practical usage, because no one would encrypt so much data with the same key. The short key is the weak point of DES. This makes it fairly easy to break with
22
Final Report
4.4. CRYPTOGRAPHY
modern computers or special-purpose hardware. DES is still strong enough to keep most random hackers and individuals out, but it is easily breakable with special hardware (DES-Crack-Machines) by government, criminal organisations, or major corporations. DES, like it is now, is getting too weak. If it has a 64-bit key there would be no chance to break it at the moment. A variant of DES, Triple-DES or 3DES is based on using DES three times. Usually, there will be an encrypt-decrypt-encrypt sequence with three di erent, unrelated keys. The reason for the decryption in the middle is that only two keys are necessary, one for the two encryptions and another for the decryption. The algorithm can be reduced to simple DES by using the same key so that the rst two steps: encryption-decryption produce the original plaintext. Many people consider Triple-DES to be much safer than plain DES. An improvement is the use of DES with key dependent S-boxes, because linear and di erential cryptoanalysis are only possible if the composition of the S-boxes is known. The only condition for the realisation of this algorithm is a hardware which is designed with loadable S-boxes. In this case there are no speed penalties. Blow sh is an algorithm developed by Bruce Schneier and published in 1994 (Schneier, 1996, p.336). It is a block cipher with 64-bit block size and variable length keys (up to 448 bits). There are some similarities to DES in the design: Blow sh uses S-boxes which are already key dependent and also P-boxes. The number of rounds is the same which is very important because this is relevant for the security of the system. The function of each round is much more complex than in DES and therefore Blow sh is more non-linear. It is very compact and can run in less than 5 kbyte of memory. It uses simple operation and it is easy to implement (source code is free and given in (Schneier, 1996)). It has gained a fair amount of acceptance in a number of applications. No attacks are known against it. Blow sh is used in a number of popular software packages, including Nautilus, PGPfone and FolderBolt for MS Windows and Macintosh.
4.4.2.2 Blow sh
4.4.2.3 IDEA
IDEA (International Data Encryption Algorithm) is an algorithm developed at ETH Zurich in Switzerland. It is the successor of the Proposed Encryption Standard (PES) which has been developed in 1990. After strengthening the algorithm against di erential analysis ETH changed its name into IDEA in 1992. It is a block cipher operating on 64-bit plaintext blocks and using a 128 bit key. IDEA is based on a mixture of operations belonging to three di erent algebraic groups which can all be easily implemented in both hardware and software. Each of the eight rounds of IDEA is a very complex sequence of these operations. The small
23

number of rounds is surprising but although cryptoanalysis is always an improving the algorithm still seems strong. It is based on a special multiplication-addition transformation which produces di usion. In fact each bit of the output depends on each bit of the input and of the key, and this after only one round. So IDEA is generally considered to be very secure and is currently one of the best public known algorithms. It is a fairly new algorithm, but it has already been around for several years, and no practical attacks on it have been published despite of numerous attempts to analyse it. IDEA is well-known for its use in PGP (see Section 4.6.3). It is patented in the United States and in most of the European countries. The patent is held by Ascom-Tech. Non-commercial use of IDEA is free. Commercial licenses can be obtained by contacting idea@ascom.ch. Software implementations of IDEA are about twice as fast as DES. They can be much faster if only four rounds are implemented. In this case they still seems to be secure enough because the best attack against IDEA faster than brut-force attacks is only for three rounds or less. The hardware implementation is quite complecate because of the multiplications. ETH Zurich developed a chip for IDEA but it is not series-produced. The reason for that, seems to be that the industry has reservations because of the licence fee for the algorithm.
4.4.2.4 Block cipher modes

Many commonly used ciphers (e.g., IDEA, DES, BLOWFISH) are block ciphers. This means that they take a xed-size block of data (usually 64 bits), and transform it to another block of the same size using a key selected function. The cipher basically de nes a one-to-one mapping from 64-bit integers to another permutation of 64-bit integers. If the same block is encrypted twice with the same key, the resulting ciphertext blocks are the same (this method of encryption is called Electronic Code Book mode, or ECB). This information could be useful for an attacker. In practical applications, it is desirable to have identical plaintext blocks encrypted into di erent ciphertext blocks. There are two methods commonly used for this: Cipher Block Chaining (CBC) mode: a ciphertext block is obtained by rst xoring2 the plaintext block with the previous ciphertext block, and encrypting the resulting value. Cipher Feedback (CFB) mode: a ciphertext block is obtained by encrypting the previous ciphertext block, and xoring the resulting value with the plaintext. There is no previous ciphertext block for the rst block, therefore an initialisation vector which can be chosen randomly is used.
2
using the operation XOR - exclusive OR
24
Final Report
4.4. CRYPTOGRAPHY
4.4.2.5 RC4
Rivest Code 4 (RC4) is a stream cipher designed in 1987 by Ron Rivest for RSA Data Security, Inc. It used to be a trade secret, until someone posted source code for an algorithm in Usenet News, claiming it to be equivalent to RC4. There is very strong evidence that the posted algorithm is indeed equivalent to RC4. The algorithm is very fast. Its security is unknown, but breaking it does not seem trivial either. Because of its speed { about 10 times faster than DES { it may nd usage in certain applications, including Lotus Notes. It can also accept keys of arbitrary length, but in most cases a 128 bit key is used. RC4 is essentially a pseudo random number generator, and the output of the generator is xored with the data stream. For this reason, it is very important that the same RC4 key is never used to encrypt two di erent data streams. The United States government routinely approves RC4 with 40 bit keys for export. Keys that are this small can be easily broken by governments, criminals and amateurs. More stream ciphers such as SEAL or WAKE which are described in (Schneier, 1996). Public key algorithms use two di erent keys: one public key for encryption and one private key for decryption. They can only be realised with complex mathematical functions. The mathematical description of all algorithms which are mentioned in the following section and of a lot more can be found in (Schneier, 1996).
4.4.3 The most important methods for public key systems
4.4.3.1 Di e-Hellman
Di e-Hellman { published by Whit eld Di e and Martin Hellman in 1976 { was the rst public-key algorithm ever invented and is now commonly used for key exchange. The purpose of the algorithm is to enable two user to securely exchange a key that can then be used for subsequent symmetric encryption of messages. In a Di e-Hellman cryptosystem the combination of private key A and public key B generates the same result as the combination of private key B and public key A (see Figure 4.4). Di e-Hellman can be used for key distribution, but it cannot be used to encrypt and decrypt messages. The security of Di e-Hellman relies on the di culty of the discrete logarithm problem (which is believed to be computationally equivalent to factoring large integers). The security of Di eHellman depends on the right choice of some numbers, especially a strong prime and a generator which has to be of a certain volume and su cient long keys. A conservative advice is to make the key for Di e-Hellman twice as long as the intended session key. The keys are much longer than for symmetric algorithm
25
Figure 4.4: Di e-Hellman public key distribution system because brut-force is not the most e cient attack. There are methods for calculating the discrete logarithm which require less expenditure than brut-force, but which are still quite expensive. The generator and the key length should be at least 768 bit (see (Schmeh, 1998, p.92)). Generally Di e-Hellman is considered to be secure. Di e-Hellman also works in communicative rings or multicast groups which means that tree or more people can generate the same session key and communicate with one another. The patent for the algorithm has expired on April 29, 1997. Timing attacks can be used to break many implementations of Di e-Hellman (see Section 4.4.1.1).
4.4.3.2 RSA
Di e and Hellman introduced a new approach to cryptography. One of the rst responses to them has been developed by Ron Rivest, Adi Shamir, and Len
26
Final Report
4.4. CRYPTOGRAPHY
Adleman in 1977 and published in 1978. The Rivest-Shamir-Adleman (RSA) algorithm is the most commonly used public key algorithm which can be used not only for key exchange but also for encryption and decryption of messages as well as for signing (see Section 4.7.1). RSA is a block cipher in which the plaintext and ciphertext are integers and there the function is a trapdoor oneway function (see Section 4.4.1.4). The security of RSA relies on the di culty of factoring large integers. Therefore the characters of a message are described by numbers, e.g. A=00, B=01, C=02 etc. All these numbers are put together and taken as one integer. This reveals to be a very large integer which is very advantageous because it is really di cult to calculate the revers function for their exponents. Recovering the plaintext from the public key and the ciphertext is equivalent to factorising the product of two primes. In general, this kind of algorithm is considered to be secure when su ciently long keys are used (512 bit is insecure, 768 bit is moderately secure, and 1024 bit is good). Dramatic advances in factoring large integers would make RSA vulnerable. RSA is currently the most important public key algorithm. It is patented in the United States (expires year 2000), and available for free outside the USA. One should know that RSA is very vulnerable to chosen plaintext attacks. Timing attacks can be used to break many implementations of RSA (see Section 4.4.1.1). There is also a low-exponent attack: the exponent is one part of the public key which is normally 3, 17, or 65537. These are primes with few 1's when they are written as binary numbers this allows a fast calculation of the exponential function. Newer implementations use larger numbers than 65537 but they are still xed. The RSA algorithm is believed to be safe when used properly, but one must be very careful when using it to avoid these kind of attacks.
4.4.3.3 Digital Signature Algorithm

Concerning digital signatures, there are much more algorithms. Some of these are based on discrete logarithm which are called Discrete Logarithm Signature Systems (DLSS). ElGamal public key cryptosystem is an improvement of Di eHellman and also a DLSS. The Digital Signature Algorithm (DSA) is a variant of ElGamal. It makes use of a random number and the one-way hash function Secure Hash Algorithm (SHA). DSA and SHA has been developed by the NSA. The NIST later on proposed to use these algorithms as a Federal Information Processing Standard (FIPS) for Digital Signature Standard (DSS). It would have been a signature-only mechanism endorsed by the United States Government, but its design has not been made public. Instead of using the common RSA algorithm the Government decided to use DSA. This created a lot of criticism and discussions, because it cannot be used for encryption or key distribution. National departments which are interested in regulating cryptographic systems
27

require these characteristics because they need digital signatures but do not want people to encrypt their communications. Therefore DSS is worldwide available on royalty-free basis and without any export regulations. DSA should by used with a 1024 bit key, implementations should sort out weak keys, and the random number generator has to be very good.
4.5 Encryption in di erent Layers

After the overview of di erent methods of encryption, there is the question of how they are used in practice. Each time when computer communication via network is discussed, the OSI reference model is used to categorise di erent approaches. The OSI reference model and the TCP/IP model is explained in many textbooks, e.g. (Schmeh, 1998). Encryption can be executed in di erent layers. It is always wise to leave the layer paradigm untouched which means that the interfaces between two layers remain the same. Changes will only happen in a single layer and without any changes for the other ones. The advantages and disadvantages for encryption on the di erent layers will be shown in the next sections. Layer 5 and 6 are not mentioned, because the TCP/IP model is realised in the Internet.
4.5.1 Encryption in Layer 7 (Application Layer)
This means that the application such as an e-mail program or a web browser itself is responsible for encrypting, decrypting, and signing the message as well as for authentication. Advantages Encryption from the application of the sender to the application of the receiver. Every message can be individually encrypted. Received messages can be decrypted directly or stored rst. Non reputation can be proofed. Authentication t best into this layer because lower layers cannot ask for a password or a chip card without the help of the application layer. This would violate the interface paradigm. Disadvantages The program must support encryption or the use of plug-ins ! all applications have to be changed.
28
Final Report
4.5. ENCRYPTION IN DIFFERENT LAYERS

!
Sender address and receiver address can not be encrypted tra c can be analysed and used for attacks.
the ow of
The transport layer includes in the Internet TCP and UDP. Each application uses a port number thus encryption on the transport layer means to establish a secure tunnel between two applications. Advantages Instead of changing all applications only the protocol must be changed. Using the port number, the coice of the message to be encrypted can be made dependent of the application. The port number can be encrypted thus an attacker does not know which one of the applications is sending the message. Disadvantages Encryption depends on the application. Messages can not be encrypted individually. The message is already decrypted arriving at the receiver's application. Digital signature is for the same reason not possible. Security ends outside the application this is a critical point especially for e-mails. Therefore e-mails has to be encrypted on the application layer. Two protocols, TCP and UDP, has to be changed, but the IP address is still readable. Encryption on layer 3 establishes a secure tunnel in the same way as on layer 4. The advantages and disadvantages are nearly the same as on layer 4. Advantages Only on protocol, the IP, has to be changed. Authentication and integrity check of IP-packets protects the network against some attack such as IP spoo ng, denial-of-service attack etc.
4.5.2 Encryption in Layer 4 (Transport Layer)
4.5.3 Encryption in Layer 3 (Network Layer)
29

Parts of the network between two routers can be protected. This is used for virtual private networks (see Section 4.9). Disadvantages IP addresses still can not be encrypted because they are needed for routing.
4.5.4 Encryption in Layer 2 (Link Layer)

No secure tunnel can be established. Only secure sections can be realised. Advantages IP addresses are encrypted. Sections of the network belonging to di erent providers can be protected individually. Disadvantages No secure tunnel from user to user is possible. If an attacker can conquer a router he gets the messages in plaintext.
4.5.5 Encryption in Layer 1 (Physical Layer)

It is of no real advantage compared to layer 2 encryption. Therefore it is only used for special cases such as ISDN. Usually mechanical protection is used to secure cables.
Conclusion
The advantages and disadvantages show that one optimum solution do not exist. It depends on every isolated case and often a combination will o er the optimum level of security. The principle is the same as for good rewalls having lter functions on di erent layers. But some points should be emphasised: The deeper the layer in which encryption takes part, the more will be encrypted. Addresses and routing information are always encrypted. The higher the layer in which encryption takes part, the more the user has got in uence on what will be encrypted and in which way.
30
Final Report
4.6 E-Mail Security
4.6. E-MAIL SECURITY
With e-mail messages can be sent over the Internet. Messages have to be protected in the same way as all other communication. Therefore con dentiality, authentication, integrity, and non reputation must be guaranteed. Speci c aims for secure e-mail are as follows: Cryptography should only be used when necessary thus the user has to be able to decide whether he wants to use encryption or not. Mail clients should be able to read encrypted as well as non encrypted mail. Mail server and mail clients have to be protected against attacks. Mail servers are highly in danger because they are on a xed location in the network and they work with complex software. Mail clients are more or less immune against attacks as long as only text mail is processed. Mail clients which also accept executable programs can get problems with viruses. Some general aspects on e-mail security As we have seen in section 4.5, e-mail has to be encrypted in the application layer. This means that information about addresses etc. remain unprotected. Non reputation is beside authenticity an important point if e-mail is used for nancial transactions. Digital signatures (see Section 4.7.1) can help in these cases. the reliable distribution of public keys are connected with the digital signatures. This point will be discussed in more detail in section 4.8. Ordinary e-mail can be easily sent to a lot of persons with the help of mailing lists. This becomes more complex for encrypted mail because each receiver has got a di erent public key. E-mail encryption must be possible even if the receiver is o ine. Attacks on e-mail are so easy because e-mail uses the Simple Mail Transfer Protocol (SMTP). Contents and author can be replaced easily and it is also easy to fake that an e-mail comes from president@whitehouse.com or someone else. SMTP commands can be directly used with a telnet connection. Like on all other means of communication via the Internet, everybody can eavesdrop on e-mail. E-mail is less secure than a postcard, because a postcard can only be read by a certain number of postmen but e-mail can be read by many people in the Internet.
4.6.1 Security Problems in connection with e-mail
31
4.6.1.1 Attacks on Servers

There are a lot of security problems concerning e-mail programs such as sendmail for UNIX. Normal rewalls with proxies are not secure enough special lter for e-mail has to be used.
4.6.1.2 Attacks on Clients

There are no risks if only text mails are processed. Warnings about dangerous e-mail are scare-monger. These warnings are the virus itself. Possible attacks come from macro programs which are used in word processing programs and other executable programs such as Java scripts or ActiveX programs. Usually these programs can be forbidden by the mail client.
4.6.2 Privacy Enhanced Mail
Privacy Enhanced Mail (PEM) is an US American standard which has been developed in the mid 80s. It uses MD5 for digital signature, RSA and DES for hybrid encryption. PEM only encrypts the body of the message, the header remains unchanged thus it can be used on di erent mail clients. Each message is signed but not necessarily encrypted. It uses a hierarchical structure for certi cates with a trust centre (see Section 4.8). Unfortunately PEM shows some disadvantages: PEM is outdated. It does not support Multipurpose Internet Mail Extension (MIME), because it has been developed earlier. (MIME enables to sent several parts with di erent formats in one e-mail.) It uses 7-Bit characters which is only adequate for English ASCII-text. The supported cryptographic algorithms are too weak, like DES, and it uses too short keys.
4.6.3 Pretty Good Privacy
Pretty Good Privacy (PGP) has been developed by Phil Zimmermann. It is not an e-mail encryption program but a le encryption program which has been developed for e-mails and it is the most often used program for e-mail encryption. The key exchange is done with RSA or Di e-Hellman, DSS respectively. Encryption is doneby IDEA, Triple DES or another algorithm called CAST are implemented. PGP supports the hash functions MD5 and SHA. The main di erence to PEM is the key management. PEM uses trust centre and PGP the web of trust (see
32
Final Report
4.6. E-MAIL SECURITY
Section 4.8). Although PGP does not forbid the utilisation of trust centres. Advantages of PGP: The quality is better than that of PEM, because PGP supports IDEA and Triple DES. All Information which are not necessary for transfering the message are encrypted. PEM leaves digital signature after encryption visible. No trust centres are necessary. Whereas PEM needs trust centre which were not avaliable some years ago. PGP source code is published and analysed. PGP is spread over the whole Internet, whereas PEM has problems with the export regulations of the USA. Disadvantages: PGP is not a standard. It is only for free for non-commercial use It is not compatible with other systems The web of trust does not work very well and it has no approved certi cate which can be used in court (see Section 4.8.1). PGP does not support chip cards. PGP does not support MIME (but it plans to do so in future).
4.6.4 S/Mime
S/Mime stands for secure MIME and has been developed by RSA Data Security Inc. As the name says it supports MIME and also all formats which are compatible to PEM. It implements the secret key algorithm RC2 with a 40-bit key. This agrees with the US export regulations. DES and Triple DES are optional. Hash functions are MD5 and SHA. For key exchange RSA with 512-bit to 1024-bit keys is used. Due to the fact that it is supported by Microsoft and Netscape it will surely become the new standard soon.
33
4.6.5 Mailtrust
Mailtrust is a German standard from the Industrieverband Teletrust. It is an improvement of PEM with better algorithms. It speci es an interface to a Personal Security Environment (PSE) which is usually a chip card. Mailtrust agrees with the German signature law and there are no problems with the US export regulations. S/Mime will be supported in a future version.
Conclusion
S/Mime will be the worldwide standard, because PEM is outdated, PGP will not be accepted for commercial use and Mailtrust is only of interest for German users. Netscape and Microsoft already support S/Mime and Mailtrust also wants to do so.
4.7 Authentication
Authenticity is the process of proving that a user is what he claims to be. Authentication is usually used to control authorisations. But is not a computer or Internet problem thats why the fundamentals of authentication will be explained in this section. Often digital signatures are used to prove authenticity, sometimes they are really necessary. Authentication systems are also very important for remote access, therefore the description of two of them can be found in Appendix A. There are three fundamental things to prove authenticity (Schmeh, 1998): Personal characteristics such as ngerprint. This method is called biometric authentication and the basic principle relies on something belonging to your physical body. An object which is hard to forge such as an ID card. The basic principle relies on something that you own. Certain Information such as a password or a secret number. The basic principle relies on something that you know. It is the easiest method but the problem is that anyone who gets to know this information can fake your identity. Biometric methods are not so common in the Internet. The best known method is the iris-scan where a picture of the iris is made which is at least as unique as a ngerprint. Many products utilise tokens which can be hardware such as an ID card or software which can be stored on a disk. The most common method is
34
Final Report
4.8. KEY MANAGEMENT
still the password check. A password in cryptology is a key. Passwords or keys can be used for symmetrical encryption. This has also the advantage of guaranteed integrity of the message. In this case two communication partners need to agree on a common key. If one of them can decrypt a message he can be sure that it comes from his communication partner. The problem of all symmetrical encryption system lays in the secure exchanging of the key. Digital signatures which provide also non reputation beside authenticity and integrity solve this problem.
4.7.1 Digital Signature

It must not be forgeable.
The aims of digital signatures are the following: The authenticity must be provable. It must not be transfered unnoticed from one document to the other. The accessory document must not be altered unnoticed. One algorithm I have already mentioned is the public key system RSA. This can be used for encryption as well as for digital signature (see Section 4.4.3.2). The other one is DSA (see Section 4.4.3.3) which is a discrete logarithm signature systems (DLSS). There are some more but they don't play any rule in the Internet. A comparison between RSA and DLSS can be found in (Schmeh, 1998, p.106). Problems occur when longer messages has to be divided into smaller blocks and each of them has to be signed. A digital signature is like all public key algorithm very slow. To solve this problem, not the whole message is signed. But instead there is a function compressing the message to an adequate length that is called the hash value or footprint. This function is called hash function. The value is then signed with the digital signature. Authentication and in particular digital signatures are closely connected with key management.
4.8 Key Management

Key management includes all aspects related to keys such as key generation, key storing, and key distribution. Two examples for public key distribution, the web of trust and trust centres are shown in this section as well as one system for distribution of symmetric keys. But the most important fact for symmetric as well as for asymmetric encryption is that the secret or private key remains really secret. If anybody is able to steal the key all messages encrypted with this key
35

can be compromised. That's why it is useful to change the secret key after each communication and to delete it. The public key can not be changed so often but it is important to make sure when generating the key that it is truly random. The private key should be encrypted before storing. The problem of public key encryption is not the compromising of the key because the key is already public. the problem lies on the question of how anybody receiving a public key can get to know if it really has been sent from the person he thinks it is from. This is a problem of authenticity. If someone just sends the public key to the communication partner a man-in-the-middle attack is possible (see Section 4.4.1.1). The solution for this kind of threat is that someone known by both communication partners signs the public keys. An even better solution is to sign a structure including the key and the name this is called a certi cate. If two communication partners have no common friend they will need a chain of persons who will sign the certi cates. This principle of verifying the certi cates of the two communication partners with the help of a chain of trust became popular with the software PGP (see Section 4.6.3) and is called Web of Trust. Its problem is that it does not work very well. The Internet is to big thus it is nearly impossible to nd a chain of trust from one user to another. If only one link is not trustworthy the whole is worthless. However it can still be used if the member of this Web of Trust give up the idea of waterproofed authenticity. Nevertheless there are some disadvantages: Certi cates for promised private keys can not be cancelled as easyly as in trust centres, because a lot of persons have to be informed. Even if a court accepts digital signatures a person can deny that a it is its key.
4.8.1 Web of Trust
4.8.2 Trust Centre or Certi cation Authority
Trust centre or Certi cation Authorities (CA) are trusted third parties which were established to sign certi cates. Each CA has its own public key which is used to sign certi cates of other people. A person who wants to use the public key of someone else has to get the public key of the CA and make sure that it is authentic. This can be realised by a phone call. The advantage is that it has to be done only once and then all certi cates from this CA can be veri ed with this signature. To reach the acceptancy of the users a CA has to be a trustworthy organisation such as a state department. After all, a digital signature is something like an ID
36
Final Report
4.9. VIRTUAL PRIVATE NETWORKS
card. Several CA can be certi cated from a higher CA and thus can build up a hierarchy of CAs. In Germany o cial CAs must agree with the German signature law. This means that they have to meet very high requirements and must be valuated, e.g. from the Bundesministerium fur Sicherheit in der Informationstechnik (BSI). However enterprises might have their own trust centre to handle the keys of their employees which does not have to be valuated. Trust centre also plays an important role for the X.509 standard from the ISO and ITU-T.
4.9 Virtual Private Networks

The new application of cryptography in the Internet, Virtual Private Network (VPN), is object of many publications. All computer or Internet journals publish articles, each producer or seller of VPNs has a Web-side and white papers. Some of these descriptions make the idea of VPNs clear: The Internet has irreversibly changed the way business is done. Being an outgrowth of Internet technology and thinking, VPNs transform the daily method of doing business faster than any other technology. A VPN typically uses the Internet as the transport backbone to establish secure links with branches and business partners and signi cantly decreases the cost of communications for an increasingly mobile workforce. Basically, the private network overlays a public IP network infrastructure such as the Internet or any other commercially available network. A VPN provides secure connections between several points it is a kind of express lane on the information superhighway, where communication travel along the Internet after being encrypted for security reasons. (Check Point a, 1998) A VPN is a connection that has the appearance and many advantages of a dedicated link but occurs over a shared network. \Private" in a VPN means that there are higher demands according to access control, con dentiality, and integrity than for normal Internet connections. Therefore a technique called \tunneling" and end-to-end authorisation as well as end-to-end encryption are used. Tunneling means that data packets are packed up into IP packets and transmitted across the public routed IP network via a private \tunnel" that simulates a point-to-point connection. \This approach enables network tra c from many sources to travel via separate tunnels across the same infrastructure. It allows network protocols to traverse incompatible infrastructures. It also enables tra c from many sources to be di erentiated, so that it can be directed to speci c destinations and receive speci c levels of service." (3Com, 1998, p.3) There is no prede ned concept for the building of VPNs, because the demands for security di er depending on the organisation and application. This chapter gives reasons why VPNs are developed and lists the advantages of VPNs. This is
37

done by showing the most popular scenarios using VPNs. Then the di erent tunneling methods which are used for VPNs are explained including the standards which already exist. Beside some general advantages of VPN, the advantages and disadvantages are given in relation to each problem, because there is no general solution. The standards for VPNs are not already xed and the development is in full swing, therefore the di erent approaches, like hardware or software based and encryption on di erent layers, are described on the basis of the solutions from di erent producers.
4.9.1 Why do organisations need VPNs?
VPNs o er cost-e ective solutions to some of today's most critical networking challenges. Organisations need a more a ordable, scalable way to meet the demands of a growing community of remote users and to manage branch o ce connectivity. They need to be able to accommodate the pace and unpredictability of business by linking customers and partners into extranets on an ad-hoc basis. And they need to be able to provide access to networked resources, including existing systems and protocols, without compromising security. (3Com, 1998) Reasons for using VPNs: increasing number of external and mobile users, increasing number of branches and cooperating partners which need access to parts of the local network All these points can be combined in one word: \globalisation". Business processes require exibility. The place of work nowadays can be in the central o ce, at home, in a branch o ce, at the customer, at the airport, in the hotel room, or even in a temporary o ce which is set up for a special project. Enterprises cooperates with worldwide partners or they merge and then a branch o ce can be at the other end of the world. (Bendl, 1998) Before VPNs were developed, the classical ways for remote access were ISDN or modem connections via public telephone lines or leased lines. These methods are cost-intensive relating to call charges and equipment and it takes some time to establish the connection. Therefore the advantages of VPNs are clear: low-priced exible and scalable
4.9.2 Advantages of VPNs
38
Final Report
huge number of users can be served only one interface for Internet access and all remote user easy to supervise remote users can be handled in the same way than local users The low price results from the local call charge, independing from wwere the user works, and from the lower costs for maintenance, because there is only one connection for remote access instead of ISDN connections and/or modem pools. The exibility and scalability is higher, because connections can be set up and also disconnected as required. One call to the Internet Service Provider (ISP) allows to order more bandwidth. Users can be added without informing the ISP and the ISP can be easily changed or multiple ISPs can be used for redundancy. VPNs have another advantage: no routing is necessary, only tunneling is and therefore no o cial Internet address is needed and the administrator can use his own address scheme. But the most important fact is that all these advantages can be used without any compromises concerning security related to access control and con dentiality. (Bendl, 1998) As mentioned in Section 4.9.1 there are di erent possible scenarios using VPNs or in other words: \There are as many types of VPN implementations as there are companies taking advantage of the concept's bene ts, each with its own speci c set of technology requirements. However, VPN con gurations can be grouped into three primary categories:" (Check Point a, 1998, p.4). Intranet VPNs between internal corporate departments and branch o ces, Remote Access VPNs between a corporation and remote or mobile users, Extranet VPNs between a corporation and its strategic partners, customers, and suppliers. Intranet VPNs connect the central o ce with its branches and also internal departments if encryption or authentication is necessary (see Figure 4.5 on page 40). This can be in case of exchanging sensitive data like nancial or personal data. For intranet VPNs fast and strong encryption is required. The latter because it is easy for employees to eavesdrop messages in a LAN and the former to accommodate the high-speed links present in internal LANs.
4.9.3 Typical VPN Implementations
39
Figure 4.5: Intranet VPN
to use data or applications from the local network (see Figure 4.6 on page 41). Mobile employees are often limited to slow modem speeds therefore the reliability of the connection is important. In addition, strong authentication to ensure the remote and/or mobile users' identity is di cult to realise, because the working place of remote and/or mobile employees is not particularly protected and other persons may have access to the employees' computer. Remote Access VPNs also require centralised management and a high degree of scalability for being able to handle multitude VPN links and a great number of users.
Remote Access VPNs o er remote and/or mobile employees the possibility
Extranet VPNs connecting between a company with its partners, customers,
and suppliers require an open, standard-based solution to ensure interoperability with various solutions that can be implemented by the business partners (see Figure 4.7 on page 41). The pictures and descriptions are taken from (Check Point a, 1998). Companies usually implement more than one type of VPN, because they may have e.g mobile users and some suppliers which are linked via a VPN to the central o ce. In addition, VPNs should be integrated in an overall security policy and therefore the idea of \one size ts all just doesn't apply in the VPN market" (Check Point a, 1998, p.6).
40
Final Report
Figure 4.6: Remote Access VPN
Figure 4.7: Extranet VPN
41

Tunneling is in general a technology to build up a secure (private) network between an external network or a single PC and a central Secure Server Network (SSN) via an insecure public network. Tunneling via the Internet means that data packets are encapsulated into IP packets and then tunnelled via a VPN. Tunneling is not a recent technology. For over 30 years telephone systems support independent connections for data and for signalling via a shared network. However, recent developments use implementations of tunneling via public networks. Standards for tunneling are the following protocols taken from (Check Point b, 1998, p14):
4.9.4 Tunneling
Point to Point Tunneling Protocol (PPTP) { An extension of Point to Point Protocol (PPP) that encapsulates IP, IPX, or NetBEUI inside of IP packets. This protocol is used primarily by ISP equipment providers because it accommodates end to end and server to server tunneling. It is largely a proprietary protocol developed by Microsoft and only recently a proprietary encryption mechanism has been added, but which is still considered as being optional. Layer 2 Forwarding (L2F) { A forwarding protocol used to tunnel higher
level protocols into a link layer protocol. This protocol has been developed by Cisco and Shiva and is o ered by some ISPs. Although it facilities remote dial-in connectivity, the information in an L2F tra c stream is not encrypted.
Layer 2 Tunneling Protocol (L2TP) { This is a hybrid protocol of L2F and
PPTP that tunnels tra c via various networks (e.g. IP, SONET, ATM). It is used to provide multi-protocol dial-up services for ISP's Point of Present (POP). Like L2F, L2TP does not de ne any kind of data privacy mechanism. Further a draft exists which proposes the use of the IPSec protocol suite to provide data privacy of L2TP tra c via IP networks.
IP Security (IPSec) is only IP based and a Layer 3 tunneling method. This
protocol is standardised and therefore not proprietary. Because of this it is advisable to use VPN solutions based on IPSec. More details of IPSec are described in Section 4.9.5. The basic components of a tunnel are: a tunnel initiator (TI), a routed network, and a tunnel terminator (TT).
42
Final Report
Tunnel initiator and terminator can be various network devices and software. This depends on how the VPN is implemented. However, there are two di erent approaches: Link and End-to-End VPNs.
4.9.4.1 Link
If the trust in the ISP and his employees is high enough, it is su cient to use VPN gateways at the two ends of the public network (see Figure 4.8). This solution is suitable for all VPN implementation: intranet, Remote Access, and extranet. tunnel is initiated and terminated at the POPs the way from and to the POPs is not protected (\last mile"-problem)
POP
l
Remote PC
e nn Tu
POP
Internet @
Corp. H.Q.
of the ISP
Figure 4.8: If the tunnel is only established between the two POPs security is the task
In this solution problems can occur, if the tunnel is not only established over the network of one ISP but over several networks as shown in Figure 4.9 on page 44. The routers of one ISP are compatible and adjusted to one another, but the problems occur with di erent ISPs having di erent VPN implementations from di erent manufacturers. In this case it has to be clari ed whether the tunnel can be established from the POP of one ISP to the POP of another ISP or not.
43

? Router C ? Router A Netz 1 ? Remote PC Router A Router B ? Netz 2
Router B
Router D
Corp. H.Q.
Figure 4.9: A tunnel which goes through all networks of di erent ISP is often not possible, because of incompatibilities of VPN implementations of di erent manufacturers
This means that the tunneling methods has to be compatible for all applications regardless whether ISDN, X.31, modem, or GSM is used. Problems with the packet length can occur and fragmentation can become necessary, because of the overhead of the tunneling protocol. There is also the question whether other protocols such as IPX, SNA, or NetBIOS can be used or not. The solution for these problems are end-to-end tunnels which will be described in the next section.
4.9.4.2 End-to-End
In case of requiring high protection only end-to-end tunneling can be taken into account. The expenditure for this is considerable, because each client has be specially equipped and a VPN gateway is necessary. This is shown in Figure 4.10 on page 45. With this solution remote access VPNs can be realised. For this approach the router at the end becomes super uous. The end points of the
44
Final Report

VPN Client ISDN, GSM, or Modem
POP
Internet @
POP
Router A
Router A
Remote PC with VPN client software
e nn Tu
Router D
VPN Gateway
Corp. H.Q.
Figure 4.10: The tunnel is establish from the company's VPN gateway to the remote or mobile user tunnel are the VPN gateway and the VPN-client software on the remote PC. The advantages of this solution are: transparence for all network components: no VPN support from the ISP is required low cost of ownership maximum security ease of administration between the VPN gateway and the client only IP is used
45

intranet VPNs to connect branches or extranet VPNs with external partners who have similar systems. These systems form the end points of the tunnel as it can be seen in Figure 4.11. Similar systems are compatible and guarantee perfect functioning of tunneling method as well as for compression and encryption.
Router-to-Router VPNs are end-to-end connections which can be used for
st
VPN Router
POP
Internet @
POP
Router A
e nn Tu l
Router A
VPN Gateway
Remote LAN clients
Corp. H.Q.
Figure 4.11: The tunnel is establish from the company's VPN gateway to the VPN
router which is connected to the remote LAN clients
The advantage of this solution is the capability to support multiple protocols such as IP, IPX, NetBios etc. Also multiple connections can be established over one tunnel. Encryption and compression end at the VPN router which is no problem if the LAN is secure otherwise it would be better to established the tunnel between each client. This solution can be also used if a router does not support VPN (see Figure 4.12 on page 47). It can be implemented on intranet VPNs to connect branches, because there it is no problem to install special software on the remote LAN clients. For extranet VPNs this is unsuitable, because of the reason of di erent business partner in the extranet would all need the same software.
46
Final Report

Not VPN capable !
Router
POP
VPN Client
Internet @
POP
Router A
e nn Tu l
Router A
VPN Client
VPN Client VPN Gateway
Remote VPN LAN clients
Corp. H.Q.
Figure 4.12: The tunnel is established from the company's VPN gateway to each single remote LAN client
4.9.5 IPSec
If an organisation plans to introduce a VPN system they should chose a solution which is based on an open standard. The advantage is that standards will be supported by di erent manufacturers. This often means that standard based products are supported for a longer time and that you are not bound to a proprietary solution. Thus investigations are more e cient over a longer period. In this section IPSec (IP Security) is described in a few words and compared to other techniques for VPNs. IPSec is a working group of the Internet Engineering Task Force (IETF) which de nes standards and protocols related to Internet security. One of the most important aspects is the IPSec standard itself, which de nes the overall IP packet structure, and a security association relative to VPN communication. Everything about IPSec that is not mentioned in this text can be found in (Smith, 1998), (Schmeh, 1998), (Raepple, 1999), or at www.ietf.org/html.charters/IPSec-charter.html IPSec is an extension of IP which o ers protection of con dentiality, integrity and authentication of datagrams. IPSec is encryption on layer 3 of the OSI reference
47

model (see also Section 4.5). These new security functions are realised in the IP Authentication Header and in the Encapsulating Security Payload. Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for an entire IP datagram. Encapsulating Security Payload (ESP) provides authentication and encryption for IP datagrams with an encryption algorithm determined by the user. In ESP authentication, the actual message digest is now inserted at the end of the packet, whereas in AH the digest is inside the authentication. AH provides data integrity only. ESP, formerly for encryption only, now provides both encryption and data integrity. AH authenticates the entire packet, while ESP does not authenticate the outer IP header. The IPSec packet structure can be seen in Figure 4.13. The picture and the information about IPSec are taken from (Check Point b, 1998). Implementations of IPSec has to support at least MD5 for authentication and DES in CBC mode (see Section 4.4.2.1 and 4.4.2.4) for encryption.
Authenticated Encrypted IP Header
Includes new source and destination information
AH
Includes message digest for authentication
ESP
Includes encapsulated data
Original IP Header
Includes original source and destination information
Original data
Encapsulation Headers
Original Data
Figure 4.13: AH provides data integrity only and ESP provides both encryption and data integrity
48
Final Report
Before the transfering of a message, a Security Association (SA) has to be negotiated between the to VPN end points. The SA is an agreement about the security parameter of a concrete communication which are de ned with the receiver's address and a Security Parameter Index (SPI). SAs contains all information required for executing various network security services. These are: Authentication and encryption algorithm Key for authentication and/or encryption Initial vector for encryption Validation time of the key and the SA Address of the sender The receiver de nes the SPI and the SA. These formats provide a consistent framework for transferring key and authentication data which is independent of the key generation, encryption algorithm, and authentication mechanism. Di erent transmission modes used in VPN solutions determine which pieces of the message are encrypted. Some solutions only encrypted the data whilst others encrypted the entire message with header. In Figure 4.14 these modes are described. Only the second and third are IPSec (ESP) modes.
Original IP Header
addressed to destination device and packet size not affected
In-place
Packet Payload Encrypted In-place
Original IP Header
addressed to destination device
IPSec Header
Transport Mode (IPSec)

Packet Payload Encrypted In-place
New IP Header
addressed to destination device with additional security header added
IPSec Header
Tunnel Mode (IPSec)

Entire Packed Encrypted and Encapsulated
New IP Header
addressed to "VPN" Device
Tunnel Mode - No Encryption

Entire Packed Encapsulated
Indicates encrypted Information
Figure 4.14: Encryption and Non-Encryption Transmission Modes
49

In Place Transmission Mode { Typically a vendor speci c solution where only data is encrypted. Packet size is not a ected which in turn ensures downstream transport mechanisms to be not a ected. Transport Mode { Only the data is encrypted and the packet size will increase. This mode provides adequate data privacy for node to node VPNs. Encryption Tunnel Mode { The IP header information and the data are encrypted with a new IP address created and mapped to the VPN end points providing excellent overall data privacy. Non-Encrypted Tunnel Mode { Nothing is encrypted which means that all data are transported in clear text. This is not an e ective solution for data privacy. One bene t of a solution that uses the standardised IPSec packet structure and SAs for VPNs is that third party VPN solutions can interoperate at data transmission level. Unfortunately they can not use a further bene t of the IPSec standard which is the key management infrastructure. As mentioned in Section 4.8, key management is important for symmetrical encryption systems. A standardised packet structure and key management would facilitate complete interoperable third party solutions.
4.9.5.1 SKIP and ISAKMP
After having de ned the packet structure, the working group IPSec also standardised the key management. There were to di erent approaches: The information about the key are sent in additional headers with the IP packet. This means that the key management protocol remains on the same layer. A separate and general key management protocol is added which can only run at the application layer. This has got the disadvantage that it violates the layered model. The Simple Key Management over IP (SKIP) developed by SUN, a represent of the rst category, has been rst the favourite in the rst approach. But in the meantime the development of the second category is favoured by IETF and Cisco with the Internet Security Association and Key Management Protocol (ISAKMP). An implementation of ISAKMP is ISAKMP/Oakley which is now called Internet Key Exchange (IKE). This automated key management schemes include the concept of a Public Key Infrastructure (PKI). A PKI is an open community of Certi cation Authorities (CA) (see Section 4.8.2) which in most
50
Final Report
cases uses a hierarchical model to construct trust associations. Setting up a VPN between a corporate network and a business partner or supplier requires a secure key exchange. A third party CA which is trusted by both VPN nodes is necessary. Using a PKI for automated key management allows an administrator to easily and securely create, distribute and revoke VPN encryption keys.
51
52
Chapter 5 Technical Approach

5.1 Security Concept
Depending on the size of a company a Security concept can be very complex and it takes a lot of time and e ort to set up a Security Concept. Usually companies have parts of a security concept already written e.g. a backup concept. A more general Security concept is often necessary or suggested to be necessary when the company connects to the Internet. The developing of a Security concept can be divided into certain steps. 1. Risk analysis 2. Developing a security plan 3. Developing a disaster plan First the total risk has to be analysed. Helpful for the risk assessment are the following questions: What am I trying to protect? What do I need to protect against? How much time, e ort, and money am I willing to expend to obtain adequate protection? (Gar nkel and Spa ord, 1996, p.27) Risk assessment is a very important part of the security concept. A company can
5.1.1 Risk Analysis
53
CHAPTER 5. TECHNICAL APPROACH

not be protected if nobody knows what to protect and against whom to protect. So all the risks have to be known before policies can be developed and implemented to reduce the risk. As an answer to the rst question all assets have to be identi ed. This will result in a list of items which should be protected. The list should contain tangibles (like disk drives, monitors, network cables etc) as well as intangibles (like the ability to continue processing, public image, computer access etc). This list will require a lot of knowledge in a lot of di erent elds or areas of the company. Therefore the best thing to do is to built a group of di erent users, managers and executives from throughout the company. This will not only improves on the completeness of the list, but also make the people aware of security. As an answer to the second question all threats have to be identi ed. This will result in a list of threats for the listed assets. The list should contain environmental threats like re, explosions etc., as well as threats coming from personnel and outsiders. Even very rare but possible events such as structural failure of the building should be in the list. As an answer to the third question the threats have to be quanti ed and evaluated. The likelihood of each threat which can occur has to be estimated. This can be done on a year to year basis. Than the cost of the risks have to be measured against the cost of prevention taking into account the likelihood of the occurrence. This will prove whether the measures are convenient or not. A security plan contains organisational, technical and structural measures. It also contains detailed lists of measures, necessary controls and reactions if rules are broken. Before writing down the measures a general security policy should be developed. In this general statements should be made. Is the security policy rather open or very restrictive? Is every employee involved or is security a matter only for management? The security plan should contain parts with more general measures. This measures should be rather independent from the technology or structural changes. General measures could be general rights of user groups. The general measures are then further de ned according to the actual technology used or structure there. It is like developing a software, where rst the functionality of the whole software is written down, then the one of the actual modules before the software is implemented.
5.1.2 Security plan
5.1.3 Disaster Plan
With the implementation of security measures 100% security is not possible. Therefore to limit the damage which is done if an incident occurs a disaster plan
54
Final Report
5.2. INTRODUCTION OF A SECURITY CONCEPT
is developed. The disaster plan contains a backup concept, a contingency plan, a recovery concept and a restart plan. So it not only contains measures to recover but also measures how to behave during an incident.
5.2 Introduction of a Security Concept

The following items help developing a workable security concept: Assign an owner Every piece of information and equipment to be protected should have an assigned \owner". The owner is the person who is responsible for the information, including its copying, destruction, backups, and other aspects of protection. This is also the person who has some authority with respects to granting access to the information. Be positive People respond better to positive statements than to negative ones. Instead of building long lists of \don't do this" statements, they should be formulated positive. Remember that employees are people too When writing policies, the users have to be kept in mind. They will make mistakes, and they will misunderstand. The policy should not suggest that users will be thrown to the wolves if an error occurs. Concentrate on education It will be wise to include standards for training and retraining of all users. Every user should have a basic security awareness education, with some form of periodic refresher material. Trained and educated users are less likely to fall for scams and social engineering attacks. They are also more likely to be happy about security measures if they understand why they are in place. Have authority commensurate with responsibility People who have a responsibility for a task or information should also have the authority to take measures to ensure the protection of the item.
55

Pick a basic philosophy A decision should be taken if either everything is permitted that is not speci cally denied or everything is denied that is not speci cally permitted. The chosen rule should be the basis of the whole concept. Defend in depth It is advisable to institute multiple, redundant and independent levels of protection. Included auditing and monitoring ensures that the protections do work. (Gar nkel and Spa ord, 1996, p.38 ) A security concept is not once written and forever good. It has to be reviewed on a regular basis. New developments within the company have to be taken into account. Developing a Security concept is always only the rst step. The Security concept has to be reviewed and altered.
5.3 Criteria for VPN solutions

In this section criteria for the selection of VPN solutions and products will be given. In most cases an existing network with remote access via ISDN or modem shall be protected. An exact analysis of the existing hardware and software is useful, before a product can be chosen. If the existing hardware can be used for the VPN solution costs can be saved. Usually the organisation has got or plans to get Internet access, then a rewall concept is necessary. In this rewall concept consideration can be done whether or not a VPN solution will be supported by the chosen rewall product, which is normally the case. Then the requirements for the VPN solution have to be de ned. This can be done by describing the VPN scenario which will be realised. These scenarios can be very di erent. The scenarios which can be found most frequently can be divided into three main categories: intranet, extranet, and remote access VPNs (see Section 4.9.3). The rst criterion is therefore for what the VPN should be used. Is it only to connect mobile users or should branches be connected or should even external partners be connected to an extranet. In most cases, there is a combination of these scenarios. The VPN solution should meet these requirements. The second criterion and just as important is the medium and the protocols which will be used via this medium. Shall the VPN solution bases on ISDN connections or over the Internet with a router. Sometimes the manufacturers o er di erent products for di erent requirements, then the right has to be chosen.
56
Final Report
5.3. CRITERIA FOR VPN SOLUTIONS
One point which is taken into account is whether the solution is based on standards like IPSec (see Section 4.9.5). For a moment, this may be unimportant, because there shall be only a VPN between two branches and a proprietary solution may be very cost-e ective, but this solution is perhaps not capable of development. When this VPN shall be extended to an extranet, the partners may have other solutions which are not compatible. If an extranet is planned right from the beginning standardised solutions should be used. A VPN shall protect communication, therefore it is necessary to use good encryption algorithms and the key length has to be long enough. Criteria for this are given in Section 4.4. Most of the cryptographic systems which are developed in the USA are to weak because they are subjected to the export restrictions for key lengths. For exibility it is useful to have VPNs which can change the algorithm and key length easily. With that, di erent level of security can be realised for di erent connections. For a high performance it is useful if the VPN solution supports hardware based encryption such as accelerator cards or co-processors. For the security level it is also important from where to where the VPN tunnel is established. For remote access VPNs this can be from the users PC to the rewall or to an VPN gateway which can be in front or behind the rewall. In the case of a double rewall concept there is a Demilitarised Zone (DMZ) where the tunnel terminates. Some products o er the possibility to terminate the VPN tunnel at an internal server (see Section 5.4.2. But if the network behind the rewall is secure enough and attacks from inside are not expected then the rewall is the right place for terminating the VPN tunnel. Most VPN solution can be combined with a security servers such as a Network Access Server (NAS) or AAA server such as RADIUS (see Appendix A.1). The integration in existing or planned management tools such as Tivoli from IBM or Unicenter from Computer Associates makes the handling of VPNs easier. If smart cards or biometrical procedures shall be used for authentication then the VPN solution has to support appropriate hardware. The VPN solution should meet the requirements and should be easily extendable but it should not be to complex. Features which are not necessary should not be included, because this also makes the handling more complex. The con guration, administration and operation shall be user friendly, because the higher the complexity the higher the possibility for mistakes and this means always a loss in security.
57
5.4 VPN Products
In this section di erent approaches for VPN implementations will described. More products can be found in Appendix C. The rst is a software based solution from NCP engineering GmbH. This software was tested during the project. Then will a solution from 3Com who is a manufacturer of active network components like switches and nally Check Point's VPN solution which is an extension of their rewall product Firewall{1 be described. A list of VPN products can be found in Appendix C.
5.4.1 NCP
The solution from NCP o ers the possibility to connect mobile workers or branches with the central o ce. The VPN can be established via the Internet independent from the Internet Service Provider (ISP). NCP is a seller of ISDN cards therefore the client software Remote Workstation for Global Access (RWS/GA) is able to handle connections via ISDN, modem, or GSM (Global System for Mobile Communication). At the central o ce the Multi Protocol Router for Global Access (MPR/GA) can be used or the Narac Enterprise VPN which is a VPN gateway. Di erent protocols are supported like IP, SNA and NetBios. The tunneling protocol L2F or L2TP (see Section 4.9.4) can be used. An extension for IPSec is planned. For authentication a RADIUS server can be integrated. The encryption algorithms Triple DES and Blow sh can be used which are not restricted by the USA export regulations, because NCP is a Germen company. The administration of the system can be done with every tool which uses the Simple Network Management Protocol (SNMP). Our test scenario could not be realised because the existing remote workstation is a LAN client which is connected with a router to the POP. The remote access software for this case is not already developed. We got this information during the tests only on inquiry. Even though NCP already advertises for this solution. The software solutions NCP o ers in the moment are only for communication cards (ISDN, GSM or modem) which may be a good solution for smaller companies, but larger companies are normally connected to the Internet with a router. The con guration is not to complex for an advanced system administrator but the documentation is not very clear. The client software could not be installed (because a communication card is absolutely necessary), therefore no statements can be done about the user friendliness when using the software in operation.
58
Final Report
5.4. VPN PRODUCTS
5.4.2 3Com
3Com is a seller for network components. The following information is taken from a 3Com technical paper (3Com, 1998). All possible scenarios can be built up with 3Com equipment. The VPNs can be established between for example an end user's laptop equipped with an analogue modem card and VPN enabled dial-up software. It also could be started by a VPN enabled router on a branch LAN or at an access concentrator at the POP of an ISP. The tunnel could be ended as with the NCP solution by the rewall or by the VPN gateway. In addition 3Com o ers another solution in which the tunnel can be switched through the rewall to increase security and exibility. In this case, a tunnel switch at the company's router for remote access or in the DMZ ends the incoming tunnel and starts a new tunnel to a tunnel terminator on the internal network. The remote user is thus virtually plugged into the network inside of the rewall, where more network resources are available. This solution has the advantage that only a hole for the tunneling protocol has to be opened instead multiple holes, one for each application. Tra c from remote employees and from external partners can came into the network over the same interface but can then be separated and terminated at di erent locations. With the tunneling switch remote employees have no problems in using network protocols such as SNA, Novell Netware, or Apple Talk and the applications running over them. 3Com solutions support the tunneling protocols PPTP, L2F and L2TP (see Section 4.9.4). Encryption systems are Microsoft Point-to-Point Encryption (MPPE) with 40-bit key length and 128-bit key length. But also IPSec which is more robust than MPPE can be used for encryption and authentication. It is recommended for use with L2TP. IPSec can also be used to extend the tunnel from the tunnel terminator to the destination workstation. Together with IPSec the key management system ISAKMP/Oakley can be used at the ISP (see Section 4.9.5.1). A security server is recommended, for example a RADIUS server for user authentication.
59
5.4.3 CheckPoint
The information about CheckPoint is taken from the CheckPoint Web-sites, in particular (Check Point a, 1998) and (Check Point b, 1998). Checkpoint's FireWall{1 is a software solution available for SUN Solaris, Windows NT and shall be developed for Linux. VPNs can be realised between several FireWall{1 systems to establish an extranet. The VPN{1 Gateway is a software solution which extends the FireWall{1 with VPN technology. The client software which is available for Windows 95/98 or NT is called Securemote. In addition, the Accelerator Card is a hardware to speed up the time for encryption to o er high performance. FireWall{1 supports three encryption schemes: A proprietary FireWall{1 encryption system Manual IPSec (see Section 4.9.5) SKIP for key management (see Section 4.9.5.1) For authentication a strong two-factor system is recommended, i.e. not only user ID and password are checked but also something the user possesses such as an electronic token. Also the authentication server RADIUS (see Appendix A.1) is supported. The VPN solution from CheckPoint is able to combine di erent scenarios for mobile employees, external branches, partners and customers. The management can be centralised together with the administration of the rewall system. This means that a security policy con be realised over the whole network, including both the intranet and the extranet. With the management tolls for FireWall{1 all components can be con gured, including routers, switches, gateways, and servers. Therefore it is important that standards like IPSec are used. For CheckPoint tra c control is an basic component of a VPN. They o er a bandwidth management system called FloodGate{1 which shall be able to manage and prioritise encrypted VPN tra c. FloodGate{1 is integrated with CheckPoint VPN solutions, sharing the same Stateful Inspection technology for tra c control and uses the same policy de nitions as FireWall{1. However, how the bandwidth management is realised with connections via the Internet which can not o er certain bandwidth or prioritised tra c is not clear. The most important advantage of the CheckPoint solution is the centralised security management which includes all security aspects of the whole network. With this solution a company security policy can be realised and the complexity may be decreased, because the same rules can be used for all ways of communication.
60
Final Report
5.5 Evaluation of a VPN solution
5.5. EVALUATION OF A VPN SOLUTION
For the evaluation of a VPN solution the requirements has to de ned. Requirements (for example): { High level of security, especially for con dentiality and authentication { High performance for special applications { Deployment of existing hardware such as ISDN router { Realisation of a connections to external partners { Possibility for mobile employees to connect from all over the world etc. Then a product assortment has to be checked which product can meet which requirement. Sometime not all requirements can be met, then compromises has to be found. Product selection { All requirements are met { or a the most important requirements are met After the product is selected and agreed with the client, the VPN can be realised. At this point, it has to be evaluate whether the requirements are met or not. If not all requirements are met, the most important should be realised. The administrator of the client who will be responsible for the maintenance of the VPN should be able to easily con gure the VPN. Tests { Testing of the implementation of the encryption algorithm (the common algorithms themselves are thoroughly tested) { Testing whether it is possible to evade the authentication process to get authorisations { Testing whether authorised users have really only access to the objects the should have { Testing the performance etc. Without test it is normally not possible to say whether the product met the requirements, because the promises of the sellers are not always true. And also the whole system has to be tested especially related to compatibility with other hardware and software components. The test can be done manually or with tools which are available on the market or in the Internet.
61
62
Chapter 6 Results
In this chapter the results of our risk analysis and the recommendations for the security plan are described. The risk analysis is not fully completed because the communication pro le is missing which is necessary for the rewall concept as well as for the VPN concept. The recommendations especially those for organisational measures are given as examples out of the security plan. More information can be found in the IT Baseline Protection Manual (Bundesministerium fur Sicherheit in der Informationstechnik, 1998).
6.1 Risk Analysis

For the risk analysis assets and possible threats must be identi ed. Security countermeasure will be then recommended which should protect these assets. Most important of all assets is sensitive data, because this must be specially protected. Sensitive Data is stored on di erent servers of the company, most of them are located in the computer centre but there are also servers with sensitive data at the branches. The communication pro les are only given in general statements, but it can be seen that sensitive data is also exchanged for processing. These communication is only over leased lines and in the local network. Therefore this whole network shall be protected. There are some external partners whom the organisations o ers Internet access, a common e-mail server and a WWWserver. The organisation wants to protect against the Internet and these external partners. They fear attacks from the Internet which was the impulse to order a security concept. In the analysis some more threats were identi ed. Remote access points for example which the organisation does not look upon as threats. These remote access points are connections for smaller branches via modem or ISDN. There is also sensitive data exchange over these connections. The costbene t analysis could not be done, because there are no information of costs for breakdown, damage, or theft and how critical this is for the daily work. The
63
CHAPTER 6. RESULTS
following sections shows the results of the risk analysis. First point is the analysis of assets and threats.
6.1.1 Identifying Assets
The network is built up with some powerful central switches and routers which realise the connections to branches and external partners. There are also routers for remote access via ISDN. In the local network there are di erent servers in the computer centre: Fileserver MS Exchange server for e-mail Server for nancial programs BS 2000 Mainframe CD-ROM server and in the technical equipment rooms: Central le server DNS server Backup servers Department servers Remote access servers The single branches have local servers at their sides which also store and process sensitive data. The clients in the local network and in the branches should not store any sensitive data locally. The breakdown of one of them concerns only the user working at this client. Therefore the security level for clients is very low.
6.1.2 Identifying Threats
For identifying the threats it is important to know against whom the countermeasures should be e ective. First, there is the Internet access with possible attackers which may intrude the system. There are a lot of threats from the Internet. A list can be found in Appendix B. But beside the Internet access there are other access points to the network.
64
Final Report
6.2. SECURITY PLAN
These remote access points are connections for smaller branches via ISDN or modems. At the moment, there are dial-in possibilities which are controlled by RADIUS servers. An ISDN connection which is once established can be used from unauthorised persons who have access to the external network. Beside the known access points for modems there are a lot of connections via modems which are not very well documented. Also each working place has the possibility to connect a modem. All these remote access points are threats for the intranet, because the give the possibility to intrude. External partners are connected via leased lines to use e-mail and the Internet access. These external networks belong to other administration sectors and their security policies and the threats of these networks are unknown.
6.2 Security Plan

The security plan contains technical, organisational, and structural security measures. These measures can be for risk avoidance or for protection. The main technical aspects of this security concept are the protection of the Internet access, the connection to the external partners and the communication with smaller branches via modem or ISDN. The organisational measures are more general, because the organisation does not lay great emphasis on it. But some important points should be mentioned. The recommendations for structural measures are limited to those which are for protecting the computer centre or technical equipment rooms. All other structural measures which are in most cases related to protection against structural destruction or protection of the buildings are not part of this security concept. Most of the general recommendations are taken from the IT Baseline Protection Manual (Bundesministerium fur Sicherheit in der Informationstechnik, 1998) and (Schaumuller-Bichl, 1992) respectively. The technical measures are based on the rewall concept. The rewall concept de nes which connections will be protected, the protection level, where the installation of remote access points is allowed, and how the communication is controlled.
6.2.1 Technical Measures
6.2.1.1 Firewall Concept

Figure 6.1 on page 66 shows the simpli ed structure of the network and the rewall concept. The real structure of the network is more complex. The intention of the picture is not to show the netstructure, but the rewall concept.
65
CHAPTER 6. RESULTS
External Branch External Partner
Internet
Client Client Router Router / Packetfilter Router / Packetfilter
Client
Client Router Router / Packetfilter
ISDN
Mail WWW Server Server
Firewall
Server
Figure 6.1: Firewall Concept The customer has its own Mail- and WWW-server. These two servers shall be available to the external branches as well as to the external partners and of course to the internal users. These servers are protected against the Internet with a packet lter, but they are standing outside the internal network which is protected by a rewall. This is called a Demilitarised Zone (DMZ). The packet lter in front of the external partners makes sure, that the external partners only use the Internet access, e-mail and WWW-services provided by our client. The external partners sould not have access to the internal network. The dial-in users are allowed to access to the internal network. This access is secured with the rewall and the packet lter protecting their entry point into the network. In contrast to the packet lter of the external partner this packet lter will allow packets to access the rewall. The external branches are treated in the same way as the local users. Their networks are seen as secure so that it is possible to connect them over a packet lter to the internal network. The packet lter will mainly reduce the tra c allowed into the internal network. Another reason for using only a packet lter to secure the connection is that the external branches use a performance critical application from out client. Our client has also a great in uence on the security concept of the external branches. The dial-in users also have to use applications from our client, but these are not performance critical.
66
Final Report
6.2. SECURITY PLAN
Rules for the rewall and the packet lters can not be de ned, because the data given from our client does not allow to develop a communication pro le. But this communication pro le is absolutely necessary to set up the rules for the rewall and the packet lters. One basic rule at least was agreed: Everything that is not explicitly permitted is denied. So the basic rule is very restrictive. An other rule was agreed: A communication between two branches can not take place over the internal network. Our client provides Internet access, e-mail and WWW-services which have to be charged. Therfore a recommendation on the rewall concept is that it is possible to do accounting. An actual product can not be suggested at the moment, because the services which shall be provided are not clearly stated.
6.2.1.2 Router
The branches are connected via leased lines to a router in the local network. Because these branches are part of the protected network the security measures are on a low level. To o er additional security and control functions within the network, packet lter and access control list on the router are adequate means. The rules for the packet lter have to be adapted to the individual connection. This allows an exact regulation which protocols can pass the router in which direction and which clients or subnetworks are allowed to communicate. The use of packet lters on the routers has another advantage, the local network is kept clear of unauthorised data tra c and the rewall system as well as the other components of the network are facilitated and can better ful l their primary task.
6.2.1.3 Remote Access Points

Remote access points are at special risk, because if an attacker can intrude into the network he can go further on and attack more computers both clients and servers. For remote access points countermeasures against intruders are just as important as for the Internet access. There it is useful to put all remote access point within the DMZ. Though the security functions of the rewall have also e ect on the remote connections. There are additional security measures for modem and ISDN connections such as call back, authentication and identi cation functions, disconnect of the physical link if something critical for the security happens or if the user disconnects from the system. A good idea is to use di erent lines for incoming and outgoing connections. ISDN has security features which should be used, for example Calling Line Identi cation Presentation (CLIP) and Connected Line Identi cation Presentation (COLP) which can be used for authentication. Many ISDN router supports the communication over Point-To-Point Protocol (PPP) after the connection is set up. Within this standard also authentication protocols
67
CHAPTER 6. RESULTS
like the Password Authentication Protocol (PAP) or the Challenge Handshake Authentication Protocol (CHAP) are o ered. PAP only ensures that the user has to authenticate during the set up. But it o ers a basic security when the user connects other networks or routers. CHAP makes a periodically handshake to proof the identity of the communicating partners.
6.2.1.4 VPN Concept

For the VPN concept it is useful to analyse the scenario for which the VPN solution should be used. The connections to the external branches via leased lines are regarded as very secure. The only reason for changing this would be the costs. VPNs which can use the Internet are much cheaper, but the organisation does not want this change. The trust in VPNs and the Internet is not high enough. But the communication to smaller branches via ISDN should be protected with VPNs. Because the branches are all quite near, there is no need to do this via the Internet. The telephone charge will be the same. In the future, there will be also mobile employees who work at home or in various o ces. This development has to be taken into account for the VPN solution. So there are two scenarios one is the connection of smaller branches and one is the connection of mobile employees. Both solutions are connections via ISDN, thus they are very similar. The only di erence is that the mobile employees can have di erent numbers for call back whereas the smaller branches have always the same number which can be used for additional authentication. The second criteria is the existing equipment. The branches already have the ISDN equipment and the equipment for the mobile employees has to be purchased in any case. For the mobile employees ISDN equipment is recommended because of the advantage of performance compared to modems and then the same technique can be used for all remote users. Solutions based on standards are recommended, because the development for the future will be that there are more and more external partners. Some time, the communication via the Internet may be used. The advantages of this beside the cost e ectiveness is that there will be only one remote access point which is much easier to handle. At this point the communication pro le is necessary to check which protocols the VPN solution must support. For example the solution from NCP can also handle IPX packets and also the BorderManager from Novell but the VPN solution from CheckPoint can't which means that there will be a hole in the rewall. The NCP solution with RWS/GA is specially made for connections via ISDN, this will be an advantage. The communication pro le is also necessary to decide where the tunnel of the VPN should end. Because the servers in the intranet are not specially protected,
68
Final Report
6.2. SECURITY PLAN
the VPN tunnel can end at the rewall. Then it is advisable to use a rewall based solution. Another advantage of a rewall based solution is that the conguration can be made with the rewall tools, this centralises the con guration and maintenance. A concluding decision could not be made, because of the missing communication pro le. The VPN solution also depends on the rewall product which is not yet chosen.
6.2.1.5 Remote Maintenance

Remote access for maintenance of the system by external companies is for two reasons a risk. Firstly, the external company can intrude into the network and secondly attackers can try to use this connection. For security reason it is recommended to abolish the remote maintenance. This means that a employee from the company has to come and maintain the system. If this is not possible, security measures for remote access points and additional access control must be taken, for example restrictive access to the system with a special account. During the daily work the remote access should be physically cut o and only explicitly opened for maintenance.
6.2.1.6 Clients
Clients will not be specially protected, because they should not store any sensitive data and the breakdown does not a ect other clients or components of the network. But a PC guideline is useful.
6.2.1.7 Passwords
A secure system should refuse trivial words. Because \dictionary attacks" can be done with programs. All words out of a dictionary, names etc. are tried in di erent variations. Where feasible in data processing terms, the following complementary rules should be observed: The selection of trivial passwords (BBBBBB, 123456) must be prevented. For initial log-on of new users, one-time passwords should be assigned, i.e. passwords which must be discarded after their rst use. In networks in which passwords are transferred in non-encrypted form, the constant use of non-recurrent passwords is recommended. After three unsuccessful attempts to enter the correct password, a lockout should be imposed which can only be cancelled by the system administrator.
69
CHAPTER 6. RESULTS
During authentication of networked systems, passwords should not be transmitted in a non-encrypted form. The password must be entered covertly, i.e. the entry will not be displayed on the monitor. Passwords should be stored in the system in a way preventing unauthorised access, e.g. by means of encryption. Password alteration must be initiated by the system on a regular basis. Re-use of previous passwords in the case of password alteration should be prevented by the IT system (password history).
6.2.2 Organisational Measures
Organisational measures are the basis for all other measures, because access rights, authorisation, and controlling functions must be de ned here. For the realisation and maintenance of the security plan an organisational structure is necessary. Someone must be responsible for all regulations, controls, training etc.
6.2.2.1 Building of an organisational structure for IT Security

IT security is of particular importance to all IT projects, all IT systems and all IT users in the institution. The fact that the IT security process is not limited to one department makes it necessary to clearly de ne responsibilities. This is the only way to ensure that all important aspects are taken into consideration and that all tasks are carried out e ciently. Although this goal can only be achieved in various organisational ways which depend on the size, nature and structure of the institution, two functions must in any case be ful lled: the IT Security Management Team, which handles a airs at a management level and draws up plans, rules and regulations, the IT Security O cer, who is responsible for all IT security matters in the institution. Both the IT Security Management Team and the IT Security O cer must have clearly de ned tasks, responsibilities and authorisation in order to be able to ful l their tasks. The management of the institution must ensure that the IT Security O cer receives from IT users the support he needs. The duties of the IT Security O cer are determined by the IT Security Management Team. At this point, it should be noted that the above tasks do not necessarily have to be carried out by several persons. On the other hand, it should be emphasised
70
Final Report
6.2. SECURITY PLAN
Figure 6.2: The organisation of IT Security Management that IT security has its price. The persons in question must be released from their other duties in such a way that they can devote su cient energy to the task of \IT security". This has more than paid for itself if there are no more damaging incidents due to lack of security. Figure 6.2 on page 71 shows the recommended organisation of the IT Security Management for the organisation and shows the relations between the management, the IT Security Management Team, the IT Security O cer, the Divisional IT Security O cer (for departments or for branches), the IT Co-ordination Board and the IT users.
6.2.2.1.1 Tasks of the IT Security O cer

As the responsibility for IT security is delegated in the same way as the responsibility for the primary task itself, the danger presented by unclear delegation is that IT security becomes \someone else's problem". The responsibility for IT security is passed around until nobody is responsible any longer. In order to avoid this, the responsibility for IT security should be given directly to one person, the IT Security O cer. He is responsible for all a airs regarding IT security in the institution. As a result of the importance of IT security, however, it is useful to create a separate position for the IT Security O cer. This is particularly the case for organisations which are as large as our client and where the required resources are available. Very important is that the IT Security O cer directly subordinates the management.
71
CHAPTER 6. RESULTS
The duties of the IT Security O cer include: helping compile the IT security concept, reporting throughout the IT security process to the IT Security Management Team and thus to management, being responsible for the implementation of the selected IT safeguards, planning and co-ordinating training and sensitisation courses, guaranteeing IT security during current operation (e.g. by checking that IT safeguards are adhered to), organising the investigations of any security-relevant incidents. In order to carry out these tasks, it is desirable that the IT Security O cer has knowledge and experience in the areas of IT security and IT. As this task requires a variety of skills, the person appointed to this position should have the following quali cations: identi cation with the goals of IT security and appreciation of the necessity of IT security. the ability to liase and work as part of a team (few other projects require such a high degree of skill in working with other people - management must be involved in central issues of the IT security process, decisions must be called for and the IT users must be involved in the IT security process, possibly with the help of the Divisional IT Security O cers).
6.2.2.1.2 Tasks of the IT Security Management Team

The IT Security Management Team should consist of persons who are able to de ne IT security targets, formulate an IT security policy to reach these targets, determine the duties of the IT Security O cer, and to evaluate results. Because our client already has a rewall working group, the tasks of this body could be extended correspondingly. However, a separate IT Security Management Team with its own resources is preferable. The detailed tasks of the IT Security Management Team are as follows: determining IT security goals and developing a policy to reach these goals, determining the duties of the IT Security O cer, providing advice when compiling the IT security concept and checking whether the IT security goals are reached,
72
Final Report
6.2. SECURITY PLAN
developing an implementation plan of the safeguards stated in the IT security concept, monitoring the implementation of these safeguards, promoting awareness for IT security throughout the institution, monitoring the e ectiveness of safeguards during current operation, In order to be able to carry out its tasks e ectively, the IT Security Management Team should have one member with knowledge of IT security, technical knowledge of IT systems and experience in organisation and administration. The following persons should also participate: the IT Security O cer, a representative from the IT Co-ordination Board and a representative of the IT users. This is the only way to ensure that a practicable IT security policy is determined and implemented.
6.2.2.1.3 Tasks of the Divisional IT Security O cer

The various IT systems and IT applications of an institution often involve di erent IT security requirements, conditions, measures and incidents. This information is passed from the Divisional IT Security O cer to the IT Security O cer of the institution. On the other hand, the Divisional IT Security O cer carries out the instructions of the IT Security O cer with regard to the various IT systems. The Divisional IT Security O cer is responsible for all security a airs of the IT systems in his division (e.g. department, branch, IT system). His precise tasks are: reporting to the IT Security O cer, carrying out his instructions and being a contact person for the IT users, helping compile the IT security concept (supplying the necessary information on IT systems, results of IT user surveys etc.), drawing up a detailed plan for the implementation of the selected IT safeguards, implementing this plan, involving the adjustment of the selected IT safeguards to the on-site conditions, if necessary, informing the IT Security O cer of a need for training and/or sensitisation of IT users, regularly checking the e ectiveness and precise adherence to the IT safeguards used during current operation,
73
CHAPTER 6. RESULTS
Depending on the size of the division, the task of a Divisional IT Security O cer can be assumed by one person already familiar with similar tasks. When selecting the Divisional IT Security O cer, it should be ensured that he is familiar with the tasks, conditions and work processes in the relevant division. A detailed knowledge of IT is an advantage as this facilitates discussions with IT users on the site and when developing IT safeguards for special IT systems. Further, the Divisional IT Security O cer should have a knowledge of project management which is helpful for the organisation of IT user surveys and the compilation of plans for the implementation and checking of IT safeguards. Working together with IT users requires a high degree of skill as these users must rst be convinced of the necessity of IT security, which may involve additional work. Equally difcult is questioning IT users about critical incidents and hot spots. In order to guarantee success here, the IT users must be convinced that honest answers will not cause them problems.
6.2.2.2 Regulations for IT security

The importance of organisational regulations and requirements for IT security objectives increases with both the information processing volume and the protection requirement of the information to be processed. Ranging from the assignment of responsibilities to the allocation of control functions, the spectrum of regulations can be very broad indeed. Determining rules alone does not guarantee smooth IT operations. The rules which apply to a certain person must be known to that person. The damage which can be caused by insu cient knowledge of the existing rules may not be excused with ignorance. The requirement for IT security is that for all tasks responsibilities and authorities are laid down. Overall regulations governing IT security, as an aspect of IT use, must be laid down in a binding form. It is advisable to lay down regulations on: documentation on IT procedures, software, IT con guration entry rights access rights resources control maintenance and repair work auditing data privacy data transmission
74
Final Report
use of passwords protection against computer viruses emergency precautions
6.2. SECURITY PLAN
approach in case of infringement of the security policy.
6.2.2.2.1 Monitoring of IT security measures

Following the introduction of IT security measures (e.g. data protection), their consistent implementation often is incumbent on the users. Where no or only inadequate monitoring of IT security measures takes place, neither abuse nor e ectiveness can be veri ed. A due reaction is thus not possible. In addition, there are IT security measures which can be e ective only when appropriate controls are implemented. These include, for example, audit functions, the security features of which will take e ect only after evaluation of the audit data.
6.2.2.2.2 Response to violations of security policies

The response to violations of security policies should be laid down so as to ensure a clear and prompt reaction. Investigations should be carried out to establish how and where such violation has originated. Subsequently, the appropriate measures must be taken to remedy or minimise the damage caused. If required, additional loss-prevention measures must be taken. The action to be taken will depend both on the nature of the violation and on the o ender.
6.2.2.3 Documentation
The quality of the documentation is an important aspect of the security concept. If documentation, for example on the IT components used, is inadequate or lacking, this can have signi cant e ects both on the selection and decision-making processes regarding a product and in terms of a loss occurring during actual operation. Documentation on system con guration, authorised users and on rights pro les must also be made. Documentation is the basis of a security concept, because it contains all regulations and all information about the organisation.
6.2.2.4 Entry rights, access rights, and resources control

Rights of entry and of access to hardware and software are applied as organisational measures to ensure secure and proper use of IT systems and processes. If such rights are granted to the wrong person or in case a right is abused, the
75
CHAPTER 6. RESULTS
result may be a large variety of hazards which can impair the con dentiality and integrity of data or the availability of computer power.
6.2.2.5 Division of responsibilities and separation of functions

Entry rights, access rights, and resources control depend on the function of a user, therefore responsibilities and functions should be wisely separated. In particular, in most cases operational functions are not compatible with controlling functions.
6.2.2.6 Granting of (application/data) access rights

Such access rights determine what person will, on the basis of his function, be authorised to use applications or data. The access rights (e.g. read, write, execute) to IT applications, parts of applications or data depend on the function ful lled by the given person, e.g. application supervisor, scheduler, system programmer, application developer, system administrator, auditor, data entry clerk, desk o cer. In any case, only so many access rights as are required for task performance (need-to-know principle) should be granted. Enforcement of access rights must be done through the administration of rights of the IT system. A variety of IT systems allow various rights to be de ned as group rights or as pro les (e.g. data entry operators). This de nition corresponds to the technical implementation of rights allocated to a function. It is bene cial for the administration of the rights of an IT system to compile such groups or pro les, thus considerably simplifying the allocation and updating of rights. The person responsible in each given case must arrange for, and document, the assignment of, and changes in, access rights.
6.2.2.7 Granting of system/network access authorisations

This type of access authorisation allows the person concerned to use IT systems, systems components and networks. This must be laid down in detail for every person authorised to use such facilities on the basis of his function and with due regard to the separation of functions. Access to a computer must be de ned depending on the function, e.g. access to the operating system (system administrator), or access to an IT application (application user). Moreover, it must be ensured that sta ng and task-related changes are promptly taken into account. Where feasible in ADP technical terms, access should be possible only after the identi cation (e.g. name, user ID or smart card) and the authentication (e.g. password) of the authorised person, and should be logged. The issue and retrieval of access-granting means such as user IDs or smart cards must be documented. Also, provisions must be laid down as regards the handling of access-granting and
76
Final Report
6.2. SECURITY PLAN
authentication means. It is necessary to make sporadic checks for compliance with the before mentioned requirements.
6.2.2.8 Granting of site access authorisations

The building of the organisation are not specially protected for example by gatekeepers. Therefore it is necessary to protect the most important rooms such as computer centre or technical equipment rooms. If unauthorised people can get into theses sensitive rooms damage can occur due to deliberate acts or human errors. The site access to these rooms must be regulated and controlled. The realisation of site access control mechanisms is always a compromise between security and costs. Cost for installation, operation, and regular revision must be in a justi able relation to the possible security risk. In most cases missing regulations for cleaning or external personnel lead to high dangers, because these people are allowed to work in security zones. If they are regularly present no one looks at them. External personnel can damage things due to improper use of the technical equipment, playing around with IT systems, or theft of computers. Cleaning personnel can unintentionally plug out a connection or water can get into the computers, papers can be misplaced or put in the dustbin. For a site access control system technical and structural measures should be realised to support the organisational measures. For the site access concept the following aspects must be de ned and written down. Security zones. These are the computer centre and the technical equipment rooms which can have di erent level of security. Policy for site access authorisation. Here it is generally laid down which persons or groups are authorised to enter which security zone. These authorisations should as restricted as possible. Therefore a spatial separation related to the responsibilities of the di erent persons is useful. Security O cer who is responsible for giving and revoking site access and for monitoring. Time dependencies can occur if a site access is only given for a project. Then the revoking of site access authorities must be e ectively done. Site access control media can be special keys or ID cards. Recording of information to proof who entered a room, how long does he stay etc.
77
CHAPTER 6. RESULTS
When site access controls are de ned, the acceptance from the users has to be taken into account. They look upon supervision as a necessary evil and often disapprove it. Rules which are easy to understand and realise, information for the user why and how security measures are realised are useful to make the acceptance as high as possible.
6.2.2.9 Personnel measures

Security is not only protection against attacks form outside but also from inside. There is danger due to \criminal energy", but more due to play instinct, ignorance and carelessness. Also frustration or even blackmail of an employee can lead to damage. Internal attacks can even less securely prevented than attacks from outside but it is possible to take precautions to minimise the risk. The most important point after de ning access authorities, authentication for servers etc. is the training of the employees. This leads also to a higher awareness for security aspects and a higher acceptance for security measures. For most of the employees security means additional work for example use of an ID card or the realisation of security checks. An employee who doesn't want to accept or doesn't understand the sense of a security measure will boycott it { consciously or unconsciously.
6.2.2.9.1 Provisions governing the con guration of users and of user groups
Provisions governing the designation of users and of user groups are the prerequisite for adequate allocation of access rights and for ensuring orderly and controlled operations. A blank form should be in existence so that, as a rst step, the required data can be obtained from each user or each user group: surname, rst name, organisational unit Proposed user name and group ID, if not already allocated by convention, where to be reached (e.g. telephone, room) where appropriate, information on the planned activity within the system and the rights required for that purpose and on the duration of the activity
78
Final Report
6.2. SECURITY PLAN
6.2.2.9.2 Non-compliance with IT security measures

Due to negligence and insu cient checks, persons frequently fail to implement, in part or full, recommended or prescribed IT security measures. Damage may be caused which otherwise would have been prevented or at least minimised. Depending on the function of the given person and on the importance of the disregarded measure, even severe damage can occur here. Often, IT security measures are disregarded due to lack of security awareness. A typical sign is disregard of recurrent error messages after a certain habituation period. In the majority of cases, damage in the IT eld is caused by negligence. In order to prevent this, everybody must be motivated to exercise care in the use of information technology. In addition, rules of conduct must be provided which help the individuals concerned to better understand IT safeguards. In particular, the following subjects are to be included in training on IT safeguards: Building IT Security Awareness Every sta member must be made aware of the need for IT security. A suitable rst step to initiate the sta into the subject-matter is to make them aware of the dependence of the agency/company, and thus of their jobs, on the smooth functioning of IT systems. In addition, the value of information should be highlighted, especially with regard to con dentiality, integrity and availability. These awareness-building activities should be periodically repeated, possibly also by providing practical information, e.g. through in-house circulars. Product-related IT safeguards Under this heading, information is provided on IT safeguards inherent in a particular product and those already present when the product is supplied. These can, for example, be registration passwords, screen savers, or encryption features for documents or data elds. Conduct in Case of the Presence of a Computer Virus in a PC - detection of any infection by computer - action and types of computer viruses - immediate response when virus infection is suspected - measures to eradicate the computer virus - preventive measures.
6.2.2.9.3 Education on IT security measures
79
CHAPTER 6. RESULTS
Here, sta members should be instructed on how to handle computer viruses. Proper Use of Passwords In this context, the importance of a password for IT security and the overall prerequisites for ensuring e ectual use of passwords should be explained. Handling of Personal Data Personal data require particularly careful handling. Sta members having to deal with personal data must be trained in the legally stipulated safeguards required. Subjects to be covered are: handling of information requests, modi cation and recti cation requested by the data subjects, legally stipulated deletion deadlines, protection of privacy, and communication of data. Prevention against social engineering Sta should be informed of the dangers of social engineering. The typical examples of attempts to gain con dential information by sounding out certain persons should be explained, as well as the relevant methods of protection. As social engineering often involves the pretence of a false identity, sta are instructed to check the identity of business partners and not to provide con dential information by telephone, in particular. The behaviour of the employees who work in critical areas related to security or who have access to sensitive data has to be regularly checked. Special attention must be paid with new employees, transfers or during the period of dismissal. Also checking of external personnel and temporary workers must be done regularly.
6.2.2.9.4 Control of the employees
6.2.2.9.5 Passwords
Without mechanisms for identifying and authorisation of users control over unauthorised using of the IT system is impossible. Even with user ID and password the unauthorised using is possible if these information can be detected. Password can be found out by try not all possible combinations. But more e ective is to try the most likely passwords. This can be done with programs which start a \dictionary attack", i.e. all words out of a dictionary, names etc. are tried in di erent variations. A secure system shall refuse these trivial words. Even better is a well educated user who uses secure password without the preconditions of the system. Attackers can use these preconditions, because they reduce the number of passwords which can occour. For this purpose, it is advisable to introduce a set of provisions governing password use and to inform the users accordingly.
80
Final Report
6.2. SECURITY PLAN
The following rules regarding password use should be observed: It must not be possible to guess the password as easily as names, motor vehicle licence numbers, birth dates, or the like. The password should comprise at least one non-letter character (special character or number). The password should consist of at least 6 characters. The number of password digits checked by the computer must be tested. Pre-set passwords (e.g. by the manufacturer at the time of delivery) must be replaced by individually selected passwords. The password must be kept secret and should only be known personally to the user. The password must be altered regularly, e.g. every 90 days. Entry of the password should be made away from general view.
6.2.2.10 Security checks and logging

The system administrator should do regular security checks, at least once a month. Some operating systems o er programs which automate this checks. The events which shall be recorded must be de ned for example users without password, many failures with passwords, users which are in the system during night hours etc. Because most of the protocol les contain personal data it must be secured that the data is only stored and used for security control. The recording of data in protocol les allows to see if security violations occurred or if someone tried to do so. Another reason for making protocols is that they act deterrent for the users who has to be informed about it. But the deterrence is only e cient if the recorded data is evaluated. The protocol of security relevant events is only useful if the data is regularly checked and evaluated by a reviser. For controlling the work of the system administrator which is a very important aspect, because he has a lot of rights in an IT system, an independent reviser is necessary. From this it can be seen that the functions of realisation and controlling must be separated. It has to be laid down who is responsible for the realisation and the evaluation and in what way the evaluation is documented to make the right reactions. These reaction can be very di erent depending whether the event was an attack or only a human error. Whatever the reaction is it must be checked if the event has any consequences for the security plan which must be reviewed and if necessary changed.
81
CHAPTER 6. RESULTS
Most e ective is to record critical events at the servers. But the protocol les should not become to big, because then security relevant data may be overlooked. This can be avoided with short intervals between the checks and a useful choice of relevant events. Also the use of appropriate tools for evaluation is recommended. These tools should be easy to use, various critical events should be eligible and the most critical events should be emphasised. Additional to the revision of protocol les online audits should be done in real time. This is not only useful for security checks but also problems of network performance or hardware failures can be detected. Structural measures are in most cases related to protection against structural destruction or protection of the buildings. Therefore the recommendations listed here are limited to those which supports the realisation of organisational measures protecting the computer centre and technical equipment rooms. The most important structural measure is the realisation of functional separation within the technical equipment rooms. Persons with di erent functions and from di erent departments or administration sectors have di erent responsibilities. Therefore they should not be allowed to use the same room, because control can not be guaranteed. If the spatial separation is not possible, all persons authorised to this room must be informed about the other persons, thus they know who is allowed to be in the room. Then they can identify unauthorised person and check them. For the site access control of the computer centre and the technical equipment rooms, ID card or smart cards are recommended for authentication. The access control is easier to realise, because the authorisation can be given and revoked with a centralised management system. This is very important when someone lose a key the lock must be changed with an ID card this is not necessary. Also access to di erent sites can be given without having a bundle of keys or using a general key. Another advantage is that the entry can be recorded with time and duration. So revision can be made and there is a piece of evidence if something has happened.
6.2.3 Structural Measures
82
Chapter 7 Discussion
Security in the Internet is one of the most important subjects recently discussed. This can be seen on all the fairs about security like the \Info Security 1999" in London (27 - 29 April). The usage of the Internet for exchanging information or e-commerce is more and more popular, therefore the demand for security is very high. But o lot of companies have not the resources and the knowledge to develop a security concept. They need additional sta or the help of a consulting company. The development of a security concept requires a good knowledge of all security aspects, information has to be collected from books and from the Internet. Therefore it is important to know where to nd these information. Then they have to be put together and be applied to the special situation of the client. The knowledge to evaluate the recommendations is necessary to nd out which of them are relevant and useful for the client. Therefore the help of specialists is required. Externals often see security holes more clearly than internals. They also have the advantage that they are not within the organisational structure and have more authority. A security concept is as individual as the company the concept is for. To compile the right security concept for a company not only a lot of information of the company has to be known but also a broad knowledge of available hardware and software and their security holes have to be known. This will insure that the company will get the most suitable security concept with suitable security products. The best basis for this extensive knowledge is experience in security aspects. We hadn't this experience, because it takes a long time to learn all these things. Normally it is not recommended to order a security concept from someone who has no experiences in this eld. To compensate this lack of experience we looked at products and recommended solutions which are tested by other people like rewalls tested by ICSA or encryption algorithms which are tested by a lot of crypto analysts.
83
CHAPTER 7. DISCUSSION
Our aim to develop an overall security concept is not fully reached, because it could not be reached in the limited space of time and because of our limited knowledge about all aspects of security. Therefore we laid the emphasis on technical aspects of the IT system. Some problems have occurred which were more or less our fault. The person to turn on in the organisation wasn't able to give us all the information we needed, because he had not the knowledge about all aspects and did not ask the appropriate persons. He couldn't answer the rst questionnaire we sent to him. Only after our meeting with him where we discussed the questions together we got some information. Among other things, the problem seemed to be that he didn't understand why we needed this information.
84
Chapter 8 Conclusion and Recommendations for Further Work

The main aims of this Final Project are reached. The most common encryption algorithms and applications are described in the way that a client who wants to use encryption can evaluate di erent solutions and knows which are the important aspects related to security such as key length. As well criteria are given to the client to decide which kind of Virtual Private Network concept is the best for his situation. Some products are presented to show the client which solutions are possible and how complex these can be. A complete product assortment could not be given, because there are so many di erent VPN solutions. They are still in the process of development, because standards are not already de ned. Therefore it is necessary to analyse the special situation of the client and to take into account how the company develops and what possible VPN solutions will be on the market in future. Main results: Evaluation of cryptographic systems Important points for encryption systems to look at Overview of di erent VPN concepts and products Criteria to nd out which VPN solution best ts
85
The main aim of the group work was to develop an overall security concept for an organisation. The overall security concept is nearly completed { Risk analysis is done { Recommendations for security measures are given in the security plan { Firewall concepts and VPN concepts are described but no nal product is selected The security concept is nearly nished. The risk analysis where assets and threats are identi ed is done. The security concept contains all general recommendations and most of those which are specially related to the organisation. A product assortment is shown but a de nite selection could not be done. Also detailed rules related to access control could not be de ned, because of the missing communication pro le of the organisation. Therefore the realisation and the tests could not be done. The following points: { Communication pro le { Product requirements and selection { Realisation { Tests are recommended for further work. The questionnaire has been developed This questionnaire can be used for a rst meeting with a client to get an overview of the aspects related to security: the infrastructure, responsibilities, remote access points, requirements for the Internet access and for the availability of services, usage of rewall and encryption systems, training of the people etc. This questionnaire has to be adapted on future developments in IT technology and it has to be developed further on with questions related to the already furnished information. These can be answered in later meetings together with the client. For the better understanding of the questionnaire it is advisable to give the client an introduction to security and security concepts. What technical and structural measures can improve security? What does security or a security concept mean? Where can be threats? What has to be covered? A lot of information is needed in from the organisation. Therefore it will be a good to have a team of specialists from di erent departments of the organisation.
CHAPTER 8. CONCLUSION AND RECOMMENDATIONS FOR FURTHER WORK
86
Final Report
Together with all these specialists the information needed to compile a security concept can be gathered. It is a good idea to go through the questionnaire with the client and further explain which information is needed and why. Giving examples is a good idea, too. Then the client will understand why the information is so important and it is more likely that the information will be delivered. A regular contact with the client is very important. This will make sure that you are still doing what the client wants you to do and that the client is still collecting the right information over his network. From meeting with the client further questions can arise. Writing a security concept is a lot of work. The client has to be aware of the fact that even though he pays for the writing of a security concept he still a lot of work, too.
87
CHAPTER 8. CONCLUSION AND RECOMMENDATIONS FOR FURTHER WORK
88
Bibliography
3Com (1998). Private Use of Public Networks for Enterprise Customers, 3Com Technical Papers. 3Com, http://www.3com.com. Bendl, R. (1998). Virtuelle private netze: Die neue art der einwahl. LANline Spezial Internet/Intranet, 3:40{42. Bundesministerium fur Sicherheit in der Informationstechnik (1998). IT Baseline Protection Manual. Bonn: BSI. Check Point a (1998). Rede nig the Virtual Private Network. Check Point, http://www.checkpoint.com/products/vpn1/vpndef.html. Check Point b (1998). Virtual Private Network, Security Components. Check Point, http://www.checkpoint.com/products/vpn1/vpnwp.html. Gar nkel, S. and Spa ord, G. (1996). Practical UNIX & Internet Security. Cambrige: O'Reilly & Associates, Inc., second edition. Landesbeauftragter fur den Datenschutz Niedersachen (1998). Grundschutz durch Firewall. Hannover. Pohlmann, N. (1998). IT-Sicherheitsstudien. Kryptokom, Aachen. Raepple, M. (1999). Transportsicherung, virtuelle private netze. iX, 1:118{122. Russell, D. and Gangemi Sr., G. (1991). Computer security basics. Sebastopol: O'Reilly & Associates, Inc. Schaumuller-Bichl, I. (1992). Sicherheitsmanagement. Mannheim: BIWissenschafts-Verlag. Schmeh, K. (1998). Safer Net: Kriptogra e im Internet und Intranet. Heidelberg: dpunkt-Verlag. Schmidt, T. (1998). Virtual Private Networks, White Paper. BinTec Communications GmbH.
89
BIBLIOGRAPHY
Schneier, B. (1996). Applied Cryptography. NEW YORK: JOHN WILEY & SONS, INC., second edition. Smith, R. E. (1998). Internet-Kryptographie. Bonn: Addison-Wesley Longman Verlag GmbH. Wobst, R. (1997). Abenteuer Kryptologie. Reading: Addison-Wesley Longman Verlag GmbH.
90
Appendix A Secure Remote Access

There are more and more mobile workers. These users should have the possibility to log in the company's local network from there home PC. It could also be that suppliers or customers should be able to get information from servers in the local network. This can be done via the Internet, ISDN, or modem. But it must be guaranteed that these users have only access to the resources for which they are authorised. Therefore authentication is necessary to identify the remote user. Authentication can be done with AAA-servers (Authentication, Authorisation, Accounting). These servers allow that a remote user must authenticate only once. The advantage is that the user do not authenticate for each server or application he wants to use. Once, he has authenticate he gets the authorisation to use all the de ned resources. It is also possible to do accounting for example using a service like the Internet. AAA-servers simplify the handling because all access controls are centralised at one place and when a user leaves the company, there is only one access which the administrator has to stop. AAA-servers allows to realise a user policy. The procedure is that all information for authentication such as password, key etc. and all information for authorisation are centralised stored on one server, the AAA-server. These information are made available to the remote access points which are called AAA-clients. 1. The user who wants to have access connects to the AAA-client. 2. The AAA-client orders the user to authenticate for example with user ID and password. 3. The AAA-client decide whether he can do the authentication himself or whether he needs the AAA-server. 4. If the client can not do the authentication, he sends a request to the AAAAserver that a user wants to authenticate himself. Therefor the AAA-client
91
APPENDIX A. SECURE REMOTE ACCESS

sends to the AAA-server the user ID and password of the user together with ID and password of the AAA-server. 5. The AAA-server authenticate the AAA-client with the password. 6. The AAA-server checks the user's password and discovers the access rights of this user. Therefor the AAA-server uses a database. There can also be a system of AAA-servers where each server has a part of the database. Then each AAA-server can send request to other AAA-servers. 7. The result of the password check and the access rights are sent back to the AAA-client. 8. The AAA-client grants or refuses the access of the user. Typical for this kind of procedure is the double authentication: the user has to authenticate against the AAA-client and the AAA-client against the AAAserver. This makes it more di cult to intrude into the system. But the server must be specially protected, because all informations are hold here. The best known implementations of AAA-servers are RADIUS and TACACS+.
A.1 RADIUS
Remote Authentication Dial-In User Service (RADIUS) is developed by a company called Livingston and is speci ed in RFC 2058. RADIUS is no Internet standard but is realised in many products. RADIUS uses UDP as the transport protocol.
A.2 TACACS+
TACACS which is developed assisted by CISCO is described in RFC 1492. It uses a double authentication similar to RADIUS. TACACS+ has additionally authorisation and accounting and now, there are no more important di erences to RADIUS except that TACACS+ uses TCP as transport protocol. There all also many implementations of TACACS+ thus there will two standards for AAAservers.
92
Appendix B Internet Threats

The following list gives a little overview of the di erent threats and which security risk are to face when a connection to the Internet is established. It is impossible to name all risks. The threats listed here are mainly taken from the paper \Grundschutz durch Firewall" from the \Landesbeauftragter fur den Datenschutz Niedersachen" (1998).
B.1 Protocol depending Security Risks

B.1.1 Password sni ng
Passwords and user IDs are transfered in plain text through the Internet when using certain Internet services. This is the chance for packet sni er or LANAnalyser to get to know the user ID and the password and so to get unauthorised access to the network. Countermeasure: Encryption
B.1.2 Packet manipulation

Packets can be manipulated e.g. forging of IP-addresses and the TCP sequence number from packets can often be guessed. Countermeasure: Digital signature
B.1.3 Re-routing
To snatch packets attacker often try to re-route packets. This is very easy especially if the router uses dynamic routing or when source routing is active. Countermeasure: Only static routing, no source routing
93
APPENDIX B. INTERNET THREATS
B.1.4 Replay-Attack
Here the attacker tries to record a communication and replay it later on to get access to the system. Countermeasure: Authentication with one-time passwords or Challenge-ResponseSystems
B.1.5 IP-Spoo ng
Often authentication is only done over the IP-address. The attacker can alter the source-address of the packet to become trustworthy. Countermeasure: Packet lter who does not allow packets to pass with invalid or altered IP-Addresses (e.g. Packets arriving outside but with internal IPAddresses)
B.1.6 ARP and ICMP Attacks

Attacks with manipulated packets of ARP (Address Resolution Protocol) and ICMP (Internet Control Message Protocols) are based on the fact that computers are only identi ed by their IP-address as legitimate senders. It is possible that a attacker when misusing ARP to take over the address of another user in a local network and use this to built up connections or deny the accessibility of another computer completely. With ICMP attacks the attacker is sending manipulated status messages which could enforce a re-routing or a denial of service. \Pingof-Death" is an ICMP attack where such a big packet is sent that will bring the computer to make a shutdown. A similar e ect has the sending of special packets (Out-of-band) to port 139 of Windows computers (Winnuke). With the TCP Syn Flood attack it is possible to block a computer completely. Here WWW-servers are penetrated with connection requests, which will be broken o from the other side and over a long period the server is busy with trying to serve the former requests. Countermeasure: Installation of Patches, strong authentication
B.2 Service speci c Security Risks

B.2.1 E-mail and Usenet-News
Private messages (e-mails) can be read from other persons as long as they are not encrypted. E-mail and news articles without a digital signature can easily be manipulated. It is possible to download programs and documents which contain
94
Final Report
B.2. SERVICE SPECIFIC SECURITY RISKS
viruses or Trojan horses. Countermeasure: Encryption, digital signature, virus protection systems
B.2.2 Telnet
An unrestricted telnet service may allow an attacker to gain user privileges on the computer which may be used for further attacks on other computers in the network. Countermeasure: Restriction of telnet and similar services to necessary addresses and ports through a rewall. It is also possible to take over a telnet session completely. Countermeasures: Instead of using telnet, rlogin, rsh and rcp use SSH (Secure Shell)
B.2.3 FTP
Badly administrated FTP-server are a security risk because in older versions of certain FTP-servers (ftpd) there are security bugs. Which allows attackers to get administration privileges. Special care has to be taken because several manuals who tell how to install an anonymous-FTP-server contain security relevant mistakes. If the server is malcon gurated it is possible for the attacker to download the encrypted password le which contains all users. This le can be decrypted at home. If it is permitted to put les somewhere on the server where others can get them, the server may soon be used as an unlicensed software server. Countermeasures: Use programs from the SSH-Packet, limitation of access rights
B.2.4 WWW
Dangers may occur at WWW-server through faulty software or con guration. Without the use of SSL (Secure Socket Layer) or other encryption it is possible to control the communication. Additionally it is possible that scripts for dynamic generation of documents contain security bugs. At the end of 1996 an attack called Web-Spoo ng became known. With this attack the attacker connects his server between the actual target-system and the user. The attacker displays an almost identical copy of the original data and can control and modify it entirely to suit his needs. Then he has the possibility to gather and manipulate the data sent from the user. Countermeasure: Encryption and digital signature for the communication, certi cates for the Web-server, reciprocal authentication of the user and the Web-server.
95
APPENDIX B. INTERNET THREATS
B.2.5 DNS
With Domain Name Service (DNS) spoo ng it is possible to redirect data streams, if the user uses the name of the computer instead of the IP-address. Countermeasure: Addressing through numerical IP-Addresses, usage of own DNSserver
B.2.6 Finger
Data displayed by the nger-service can give attackers useful information about the user on the system, which then can be used explicitly for attacks. The service got famous through a bu er-over ow bug. With the call of nger the parameter were written into a bu er with xed length. Data that couldn't t into the bu er was overwriting the stack in the working memory, where it was treated and executed as executable code. So with careful choice of characters almost any code could be executed. Similar programming bugs can be found in a lot of other server programs. Countermeasure: Switching o the services which will give attackers security related information about the system like nger, rup, rusers, rwho Installation of patches against bu er-over ow bugs
B.2.7 SNMP
With the help of SNMP (Simple Network Management Protocol) service it is possible to centralise the administration of network components. Con guration and status of the components can be gathered and changed. This provides the attacker with valuable information about the hardware and software at the site, which can be used for further attacks. Special signi cation has the so-called community string, which allows an easy way of authentication at SNMP. The prede ned value is often set to \public" which makes it easy to gain unauthorised access to the service. Countermeasure: Use of hard to guess community strings, minimising of the information SNMP is giving to the absolute necessary.
B.3 Security Risks from Active Elements

B.3.1 ActiveX
ActiveX components are a great risk to security because they are not liable to any restrictions relative to the Windows- and system functionality. The following risks are known:
96
Final Report
B.3. SECURITY RISKS FROM ACTIVE ELEMENTS
Investigation of users and computer systems Installation and execution of viruses and Trojan horses Damage of system resources System overload Countermeasure: Switching o the ActiveX support, use of microsoft-authenticodes, activation of a high security level in the Internet Explorer, employment of ActiveX lters and the Internet Explorer Administration Kit at networks Java o ers a su cient security, but due to implementation bugs it is possible to attack the system with Java-applets. The threats are modi cation of the system and resources, overload of the system, investigation and annoying of users. Countermeasure: Switching o the Java functionality, employment of Java- lters, working with signed applets Browser plug ins are software modules which are running on the client to extend the browser functionality e.g. to display audio- or videodata. Plug ins are platform independent. They occupy local disk space and have to be installed by the user. Countermeasure: Training of users to prevent unintentional installation of plug ins Cookies can give information of the user pro le to the Web-server. This is done without the notice of the user. The web pages can then be con gurated according to the user pro le. Countermeasure: Browser con guration: cookies are not or not automatically accepted or stored deleting of already stored cookies employment of cookie lters
B.3.2 Java
B.3.3 Plug Ins
B.3.4 Cookies
97
Appendix C VPN Products

The following list gives an overview of VPN products which supports IPSec. Manufacturer 3com http://www.3com.com Ascend Communications http://www.ascend.com Axent Technologies http://www.axent.com Borderware http://www Cabletron http://www.cabletron.com CheckPoint http://www.checkpoint.com Cisco Systems http://www.cisco.com Electronic Frontier Foundation http://www.e .org E-Lock Technologies (Frontier Technologies) http://www.e-lock.com Gemini Computers http://www. geminisecure.com Name Secure VPN Secure Access Eagle VPN Borderware Firewall Server NE-Secure Firewall{1 Cisco IOS S/WAN Linux Key Management manual, IKE(ISAKMP/Oakley) manual IKE(ISAKMP/Oakley) manual IKE(ISAKMP/Oakley) proprietary manual, proprietary manual, IKE(ISAKMP/Oakley) SKIP, proprietary IKE(ISAKMP/Oakley) manual System Netbuilder Ascend Router Windows NT, Solaris, HPUX Stand-aloneFirewall Cyberswitch Solaris, SunOS 4 HPUX, AIX Windows NT Cisco
Linux 2.0.28 NetBSC-current IPSec BSD/OS 2.0 e-lock VPN manual Windows NT, IKE(ISAKMP/Oakley) geplant: Windows95/98 Trusted Security manual, Gemini Trusted Firewall-Guard proprietary Firewall-Guard (GTFW-GD)
98
Final Report
Manufacturer IBM
http://www.ibm.com
NCP Engineering http://www.ncp.de Netmanage

http://www.netmanage.de Network Associates http://www.nai.com Novell http://www.novell.com OpenBSD Project http://www.openbsd.com Storagetek
Name IBM SNG (Secured Network Gateway) NARAC Onnet Gauntlet Firewall Border Manager OpenBSD
Key Management manual, proprietary SKIP manual
System IBM AIX
V.34 Modem Windows 95/98 Windows NT manual Windows 95 IKE(ISAKMP/Oakley) Winwos 3.11 manual, proprietary manual,SKIP, IKE(ISAKMP/Oakley) manual, Pluto (Photuris) manual, proprietary TIS Gauntlet NetWare/ Intranet Ware OpenBSD (all systems) Network Systems
Borderguard and http://www.storagetek.com Security Router Timestep Corporation Permit/Gate manual + Client IKE(ISAKMP/Oakley) http://www.timestep.com VP Net Technologies
http://www.vpnet.com Toshiba http://www.toshiba.com
VPN Ware Systems Crypto Gate VPN
Router Embedded + Windows NT 4.0 Windows 95, MAC SKIP Windows 95/98 IKE(ISAKMP/Oakley) Windows NT, OS/2 manual, BDD/OS SKIP
99
APPENDIX C. VPN PRODUCTS
100
Appendix D Project Planning

This nal project started at the 1th of February and the duration was four months. The interim report was submitted on the 12th of February as it was planned. This can be seen on the initial plan (see Figure D.1 on page 103) as well as on the modi ed plan (see Figure D.2 on page 104). The research was planned from the rst day until the 19th of March but had to be extended until the 8th of April, because there were a lot of di erent aspects for the security concept which were for themselves very small but the summation of all took a little bit more time. An example for this is to look at whether the existing router of the organisation supports any security functions. This had to be looked up in the Internet or the specialist at OptiNet had to be asked for. Another point which took more time than expected was the organisational measures for the security concept. Di erent sources had to be compared and the recommendations had to be evaluated which of them were sensible and useful for our client. Also the technical recommendations for ISDN and modems took a long time, because I hadn't the knowledge in this eld before. These additional aspects I had to look at were not mentioned in the research part of the nal report, because there I concentrate on my main subjects but they were taken into account in the results. The research could not be separated into the di erent points, instead it was more mixed. But anyway, this detailed separation was only for controlling the time and therefore it was always a good possibility to check the time which was spend on one subject. The time schedule for the questionnaire could be met. It was reviewed before we had the rst meeting with the client and some more detailed were questions added after the meeting. The collecting of product information was planned for the rst week in March but had to be postponed to the end of March. The research had a higher priority at this moment to be well prepared for the meeting with the client on the 23th of March. The comparison of the products were mainly used to nd out the criteria
101
APPENDIX D. PROJECT PLANNING

for product selection. This were done after the collection of product information as planned. Additionally a company provided a test version of a VPN software which was tested between the 21th and the 27th of April. The security concept for our client which is written in German was planned to be nished during one week, but it took a lot more time because it is much more extensive than I thought it could be. The main point which changed the planning was the milestone \All Information from the Organisation" which could not be met. The initial plan was that we send the questionnaire to the organisation and then we get it back after a few week perhaps with some questions which can be quickly cleared. But it was totally di erent: the questionnaire had to be answered together with the client, then we had a few information. This happened on the 8th of February. Then we had another meeting on the 23th of March were we got more information. We presented an interim report on the 4th of May which was initially planned for the 16th of April but was cancelled owing to illness. At this meeting we got information which were relevant for the security policy of the client. The procedure for the meetings was one day for preparation of outstanding questions. During the meeting we got some information and request for answering the rest. Then we needed another day for processing the information. But between the meetings we got nearly no further information and therefore the outstanding questions had to be asked again on the next meeting. The analysis of the data was planned to do in two parts: rst the \Analysis of joint data" together with Christa Eekho and then the \Analysis of special data". This was mixed because the analysis was teared apart due to the cutting up of the ow of information. Because our client has a lot to do with his network, the security concept has a lower priority. Therefore we have not all information and the security concept could not be nished. The analysis of the furnished information have been closed after the last meeting but there are still some outstanding information, for example the communication pro le which still has to be analysed. Because the security concept is not already completed it can be seen from the initial plan that the realisation and the test had to be postponed to a later date. The documentation was nearly done as written in the initial plan. \Background an Theory" was planned between the 15th of February and the 23th of March. This was a little bit extended until the rst week of April. The documentation of the product information was shifted related to the collection of \Product Information" and extended after the product test. The whole documentation could not be separated so clearly into the di erent parts. The documentation is not shown in detailed in the modi ed plan, because the details are not so relevant. Instead the other events are fully shown to get an better overview. Last but not least, the presentation for OptiNet was not held on the 12th of May. It was advanced to the 28th of April due to internal reason of OptiNet.
102
Final Report

ID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 Security Concept Research
Item
Begin 01.02.99 01.02.99 01.02.99 03.02.99 08.02.99 15.02.99 22.02.99 24.02.99 18.03.99 02.02.99 02.02.99 12.02.99 15.02.99 01.03.99 08.03.99 22.03.99 22.03.99 22.03.99 29.03.99 12.04.99 19.04.99 03.05.99 15.02.99 15.02.99 08.03.99 24.03.99 12.04.99 26.04.99 10.05.99 20.05.99 31.05.99 07.05.99 07.05.99 12.05.99
End 31.05.99 19.03.99 02.02.99 05.02.99 12.02.99 19.02.99 23.02.99 16.03.99 19.03.99 12.02.99 11.02.99 12.02.99 26.02.99 09.03.99 19.03.99 22.03.99 09.04.99 26.03.99 09.04.99 16.04.99 30.04.99 07.05.99 31.05.99 19.03.99 23.03.99 09.04.99 23.04.99 07.05.99 19.05.99 28.05.99 31.05.99 12.05.99 11.05.99 12.05.99
1999 February March April May June

Security Concept in general Cryptographic methods Digital Signature Key Management Trust Centre VPN Viruses Interim Report Interim Report INTERIM REPORT completed Questionnaire Revision Product Information Comparing Products All Information from the Organisation Analysis Analysis joint data Analysis special data Concept Realisation Test Documentation Background and Theory Product information Data Analysis Technical Approach Results Conclusion and recommendations for further work Documentation of Realisation and Test, Report Revision FINAL REPORT completed Presentation of Final Year Project Preparation Presentation at OptiNet
Figure D.1: Initial Plan
103
APPENDIX D. PROJECT PLANNING
ID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
Item Security Concept Research Security Concept in general Cryptographic methods Digital Signatur Key management Trust Centre VPN Interim Report Interim Report
Begin
End
Real Begin
Real End
1999 February Februar March Mrz April April May Mai

June Juni
01.02.99 31.05.99 01.02.99 28.05.99 01.02.99 19.03.99 01.02.99 19.03.99 01.02.99 02.02.99 01.02.99 05.02.99 03.02.99 05.02.99 08.02.99 16.02.99 08.02.99 12.02.99 17.02.99 22.02.99 15.02.99 19.02.99 23.02.99 02.03.99 22.02.99 23.02.99 03.03.99 04.03.99 24.02.99 19.03.99 04.03.99 08.04.99 02.02.99 12.02.99 02.02.99 11.02.99
INTERIM REPORT completed 12.02.99 12.02.99 12.02.99 12.02.99 Questionnaire Revision Product Information Comparing Products / Product criteria Informations from the Organisation Meeting with customer Organise new information Further Questions Meeting with customer Organise new information Preparation of Presentation Concept Presentation Organise new information Data Analysis Concept Realisation Test Documentation FINAL REPORT completed Presentation of Final Year Project Preparation Presentation at OptiNet 15.02.99 26.02.99 15.02.99 26.02.99 01.03.99 09.03.99 24.03.99 01.04.99 08.03.99 19.03.99 06.04.99 16.04.99 08.02.99 05.05.99 08.02.99 05.05.99 08.02.99 08.02.99 08.02.99 08.02.99 09.02.99 09.02.99 09.02.99 09.02.99 22.03.99 22.03.99 22.03.99 22.03.99 23.03.99 23.03.99 23.03.99 23.03.99 24.03.99 24.03.99 24.03.99 24.03.99 14.04.99 15.04.99 14.04.99 15.04.99 04.05.99 04.05.99 04.05.99 04.05.99 05.05.99 05.05.99 05.05.99 05.05.99 22.03.99 09.04.99 22.03.99 12.05.99 12.04.99 16.04.99 17.03.99 04.06.99 19.04.99 30.04.99 06.06.99 18.06.99 03.05.99 07.05.99 19.06.99 25.06.99 15.02.99 28.05.99 15.02.99 28.05.99 31.05.99 31.05.99 31.05.99 31.05.99 07.05.99 12.05.99 25.04.99 28.04.99 07.05.99 11.05.99 25.04.99 27.04.99 12.05.99 12.05.99 28.04.99 28.04.99
Christa, Christine
Christa, Christine Christa, Christine Christa, Christine Christa, Christine Christa, Christine Christa, Christine Christa, Christine Christa, Christine Christa, Christine Christa, Christine
Christa, Christine Christa, Christine Christa, Christine
Figure D.2: Modi ed Plan 104
02.02.99 11.02.99 02.02.99 11.02.99
Appendix E Questionnaire
1 Existing Infrastructure 1.1. Record Hardware Infrastructure - if possible in graphical form 1.1.1. How does the passive cable network look like? This must be exact recorded. 1.1.2. Which end devices are used? This means input and output devices. 1.1.3. Which active components are existing (router, switches etc.)? 1.2. Which technologies are used? (ATM, Ethernet, Token ring, etc.) 1.3. Specify physical and logical network transitions, network sovereignty and management zones. 1.4. Describe the address structure. 1.4.1. How are the addresses administrated? (DNS-Server, DHCP, etc.) 1.5. Which protocols are used? (IP, IPX, DECnet, NetBIOS etc.) 1.6. Which Operating Systems are used? (Windows NT, Windows 95/98, Linux, Unix (which), Novell NetWare etc.) 2 Security of operation 2.1. Are there any hardware redundancies (routers, switches, servers etc.)? 2.2. Is there a backup concept? 2.2.1. What kind of tools are used for the backup? 2.2.2. Which data is stored (user, system)? 2.2.3. How often is data stored? 2.2.4. For how much time is the backup stored?
105
APPENDIX E. QUESTIONNAIRE
2.2.5. Where is the backup done? 2.2.6. Where is the backup stored? 2.2.7. What kind of medium is used for the backup? 2.3. Who is responsible for operational security? 3 Remote Access Points 3.1. Is there any access points from outside to the Intranet? 3.2. Is there any access from the Intranet to other networks? 3.3. Is there any access control and monitoring? 3.3.1. What kind of control and monitoring is used? 3.3.2. Who is responsible for carrying out? 3.3.3. What kind of consequences are drawn out of it? 3.3.4. Is there a standardised concept? 3.4. Are there any policies or user guidelines? 3.5. What does the communication pro le with external partners look like? 3.5.1. Is there a security policy of the external partner? 3.5.2. How is the access realised? 3.5.3. For what are the external users authorised? 4 Analysis of the security grade of the Intranet within the company 4.1. De ne relation of trust 4.1.1. Against whom shall be protected? 4.1.2. What shall be protected? 4.1.3. Against what shall be protected? 4.2. Which data is how con dentially? 4.3. Are there legal rules that must be paid attention? 4.4. To which extent is data integrity to be secured? 4.5. Which data is how to secure? 4.5.1. Is there already a list of goods which have to be protected? 4.6. Are there sensitive data points in the network? 4.6.1. Where are they? 4.7. Administration structure of the network operating system? 4.8. Communication pro le
106
Final Report
4.8.1. Who is communicating with whom? 4.8.2. Which services are used? (Facsimile, mail, phone etc.) 4.9. Is there a security policy in existence? 4.9.1. How does this look like? 4.10. Cost-Bene t-Analysis 4.10.1. Which nancial damage will be done if the data is lost? 4.10.2. How high is the expense to protect the sensitive Data? 4.10.3. How much time and work shall be invested? 5 Analysis of Security Risks 5.1. Are there any known security risks in the organisational structure? 5.1.1. Are there any security zones? 5.1.1.1. Are there any provisions governing the site access authorisations? 5.1.1.2. Are there any restrictions for site access? 5.1.1.3. What do access controls like like? 5.1.2. Where and how is sensitive data processed? 5.1.3. Are there any areas where sensitive data can be found in paper form? 5.2. Is there a security o cer? 5.3. Are the users trained in security aspects? 5.4. Are the security risks of operation systems known? 5.5. Are there any know security risks based on the complexity of the network? 5.5.1. Can the complexity of the network be reduced? 5.6. Are there any regular security checks of the IT system? 5.6.1. In what way are the results treated? 6 Firewall concept for access control 6.1. De nition of the requirements of the rewall-system (de nition of rules, recommendations) 6.2. Shall a packet lter be used? 6.3. Is NAT (Network Address Translation) needed? 6.4. Which lters are needed at application level?
107
APPENDIX E. QUESTIONNAIRE
6.5. Are Proxies needed? 6.6. Which services shall be used and in which direction (inbound or outbound)? (E-mail, WWW (HTTP, Java, Active-X, CGI etc.), News (NNTP), Telnet, Rlogin, FTP, etc.) 6.7. How high must the availability of the services be? 6.8. Which network protocols shall be used? (UDP, TCP) 6.9. Is there a preferred operating system which the rewall should have? 6.10. How important is the performance? 6.11. Operating concept (Monitoring, Alarming, Patches, how are and who is implementing changes? 7 Encryption Systems and Authentication 7.1. Are there any encryption systems in use? 7.1.1. Are there any e-mail encryption in use (PGP, PEM etc.)? 7.1.2. Which key length is used? 7.2. Do you use a trust centre? 7.3. Are there any authentication systems in use? 7.3.1. Do you use digital signatures or are they required? 7.3.2. Do you use smart cards or other systems for authentication? 7.4. Are VPNs in operation? 7.4.1. Where and what for are these VPNs? 8 Virus scanner 8.1. Are there any virus scanners in use? 8.1.1. Which virus scanner are used? 8.1.2. Which version number is in use and how old is this version? 8.1.3. Are there regular updates? 8.2. How are virus scanners used (automatically with the booting of the system, manually from the user etc.)? 8.3. Are the users trained in using a virus scanner? 8.3.1. Do the users use virus scanners?
108
Appendix F Abbreviations
AAA Authentication, Authorisation, Accounting ADP Automated Data Processing AH Authentication Header ANSI American National Standards Institute BSI Bundesministerium fur Sicherheit in der Informationstechnologie CA Certi cation Authority CBC Cipher Block Chaining CFB Cipher Feedback CHAP Challenge Handshake Authentication Protocol CLIP Calling Line Identi cation Presentation COLP Connected Line Identi cation Presentation DEA Data Encryption Algorithm DES Data Encryption Standard DLSS Discrete Logarithm Signature Systems DMZ Demilitarised Zone DSA Digital Signature Algorithm DSS Digital Signature Standard
109
APPENDIX F. ABBREVIATIONS
ESP Encapsulating Security Payload FIPS Federal Information Processing Standard GSM Global System for Mobile Communication IETF Internet Engineering Task Force IDEA International Data Encryption Algorithm IKE Internet Key Exchange IP Internet Protocol IPSec IP Security ISAKMP Internet Security Association and Key Management Protocol ISO International Standards Organization ISP Internet Service Provider L2F Layer 2 Forwarding L2TP Layer 2 Tunneling Protocol MIME Multipurpose Internet Mail Extension MPPE Microsoft Point-to-Point Encryption MPR/GA Multi Protocol Router for Global Access NAS Network Access Server NBS National Bureau of Standard NIST National Institute of Standards and Technology NSA National Security Agency PAP Password Authentication Protocol PEM Privacy Enhanced Mail PES Proposed Encryption Standard PGP Pretty Good Privacy PKI Public Key Infrastructure
110
Final Report
POP Point of Present PPP Point to Point Protocol PPTP Point to Point Tunneling Protocol PSE Personal Security Environment RADIUS Remote Authentication Dial-In User Service RC4 Rivest Code 4 RSA Rivest-Shamir-Adleman algorithm RWS/GA Remote Workstation for Global Access SA Security Association SHA Secure Hash Algorithm SKIP Simple Key Management over IP SMTP Simple Mail Transfer Protocol SNMP Simple Network Management Protocol SPI Security Parameter Index SSN Secure Server Network TCP Transmission Control Protocol TI Tunnel Initiator TT Tunnel Terminator VPN Virtual Private Network
111
APPENDIX F. ABBREVIATIONS
112
Appendix G Glossary
according to organisational policy or law. access control lists Rules for packet lters (typically routers) that de ne which packets to pass and which to block. access router A router that connects your network to the external Internet. Typically, this is your rst line of defence against attackers from the outside Internet. application-level rewall A rewall system in which service is provided by processes that maintain complete TCP connection state and sequencing. attack An attempt to bypass security controls on a system. An active attack alters data. A passive attack releases data. Whether an attack succeed depends on the vulnerability of the system and the e ectiveness of existing countermeasures. authentication The process of proving that a subject (e.g., a user or a system) is what the subject claims to be. Authentication is a measure used to verify the eligibility of a subject and the ability of that subject to access certain information. authentication header (AH) A part of the security protocol IPSec that provides authentication and optional replay-detection services. AH is embedded in the data to be protected (a full IP datagram, for example). AH can be used either by itself or with Encryption Service Payload (ESP). Refer to the IETF draft for AH. authorisation The granting of rights to a user, a program, or a process. For example, certain users may be authorised to access certain les in a system,
abuse of privilege When a user performs an action that he should not have,
113
APPENDIX G. GLOSSARY
whereas only the system administrator may be authorised to export data from a trusted system.
availability A security principle that ensures the ability of a system to keep

working e ciently and to keep information accessible.
bastion host A system that has been hardened to resist attack, and which is
installed on a network in such a way that it is expected to potentially come under attack. Bastion hosts are often components of rewalls, or may be \outside" web servers or public access systems. public key associated with this identity.
certi cate A cryptographically signed object that contains an identity and a certi cation A technical evaluation performed as part of, and in support of, ciphertext In cryptography, the unintelligible text that results from encrypting
original text. Contrast withplaintext. the accreditation process that establishes the extent to which a particular computer system or network design and implementation meet a prespeci ed set of security requirements.
compromise Unauthorised disclosure or loss of sensitive information. con dentiality A security principle that keeps information from being disclosed
to anyone not authorised to access it. Synonymous with secrecy. tos" meaning \hidden" and the \graphia" meaning \writing."
cryptography The study of encryption and decryption. From th Greek \krypdata encryption standard (DES) A private key encryption algorithm adopted
as the federal standard for the protection of sensitive information and used extensively for the protection of commercial data as well. nal text (called plaintext). Contrast with encryption. and the identity of the sender and receiver.
decryption The transformation of encrypted text (called ciphertext) into origidigital signature An authentication tool that veri es the origin of a message de-militarised zone (DMZ) A network which is located between a protected
and a external network to build an additional security layer.
Di e-Hellman A method of establishing a shared key over an insecure medium.
114
Final Report
the name service cache of a victim system, or by compromising a domain name server for a valid domain. dual homed gateway A dual homed gateway is a system that has two or more network interfaces, each of which is connected to a di erent network. In rewall con gurations, a dual homed gateway usually acts to block or lter some or all of the tra c trying to pass between the networks. encapsulating security payload (ESP) A security protocol that provides data con dentiality and protection with optional authentication and replay{detection services. ESP completely encapsulates user data. ESP can be used either by itself or in conjunction with AH. Check out IP Encapsulating Security Payload (ESP). This is the IETF draft for ESP. encryption The transformation of original text (called plaintext) into unintelligible text (called ciphertext). Contrast with decryption. rewall A system or combination of systems that enforces a boundary between two or more networks. hash A one way function that takes an input message of arbitrary length and produces a xed length digest. Examples are Secure Hash Algorithm (SHA) and Message Digest 5 (MD5) host-based security The technique of securing an individual system from attack. Host based security is operating system and version dependent. insider attack An attack originating from inside a protected network. integrity A security principle that keeps information from being modi ed or otherwise corrupted either maliciously or accidentally. intrusion detection Detection of break-ins or break-in attempts either manually or via software expert systems that operate on logs or other information available on the network. IP splicing / hijacking An attack whereby an active, established, session is intercepted and co-opted by the attacker. IP splicing attacks may occur after an authentication has been made, permitting the attacker to assume the role of an already authorised user. Primary protections against IP splicing rely on encryption at the session or network layer. IP spoo ng An attack whereby a system attempts to illicitly impersonate another system by using its IP network address.
DNS spoo ng Assuming the DNS name of another system by either corrupting
115
key In cryptography, a secret value that's used to encrypt and decrypt messages.
A Sequence of symbols (often a large number) that's usually known only to the sender and the receiver of the message. See also private key encryption and public key encryption. minimum amount of system privilege. This reduces the authorisation level at which various actions are performed and decreases the chance that a process or user with high privileges may be caused to perform unauthorised activity resulting in a security breach. rewall or network.
least privilege Designing operational aspects of a system to operate with a
logging The process of storing information about events that occurred on the Message Digest 5 (MD5) A one way hashing algorithm that produces a 128one-time cipher or one-time pad A type of encryption in which a cipher is
used only once. Two copies of a pad are created one copy goes to the sender,and the other to the recipient. The pad contains a random number for each character in the original message. with ciphertext. bit hash. Both MD5 and Secure Hash Algorithm (SHA) are variations on MD4, which is designed to strengthen the security of this hashing algorithm. SHA is more secure than MD4 and MD5.
plaintext In cryptography, the original text that is being encrypted. Contrast policy Organisation-level rules governing acceptable use of computing resources,
security practices, and operational procedures.
proxy A software agent that acts on behalf of a user. Typical proxies accept
a connection from a user, make a decision as to whether or not the user or client IP address is permitted to use the proxy, perhaps does additional authentication, and then completes a connection on behalf of the user to a remote destination. lated keys. The private key is known only to its owner. The public key is known by a group of users. Also called asymmetric encryption. Contrast with private key encryption. system vulnerability.
public key encryption A type of encryption that uses two mathematically re-
risk The probability that a particular security threat will exploit a particular
116
Final Report
risk assessment An analysis of a system's information needs and vulnerabilities

to determine how likely they are to be exploited in di erent ways and the costs of losing and/or recovering the system or its information.
RSA A public key cryptographic algorithm (named after its inventors, Rivest,
Shamir and Adleman) with a variable key length. RSA's main weakness is that it is signi cantly slow to compute compared to popular secret-key algorithms, such as DES.
screened host A host on a network behind a screening router. The degree to screened subnet A subnet behind a screening router. The degree to which the
subnet may be accessed depends on the screening rules in the router.
which a screened host may be accessed depends on the screening rules in the router.
screening router A router con gured to permit or deny tra c based on a set
of permission rules installed by the administrator.
secrecy A security principle that keeps information from being disclosed to anyone not authorised to access it. Synonymous with con dentiality.
secret key encryption A type of encryption that uses a single key to both en-
crypt and decrypt information. Also called symmetric encryption. Contrast withpublic key encryption.
secure hash algorithm (SHA) A one way hash put forth by NIST. SHA is
closely modelled after MD4 and produces a 160-bit digest. Because SHA produces a 160-bit digest, it is more resistant to brute-force attacks than 128-bit hashes (such as MD5), but it is slower.
security Freedom from risk or danger and the assurance of safety. security level A representation of the sensitivity of information. security policy The set of laws, rules, and practices that regulates how an
organisation manages, protects, and distributes sensitive data.
sensitive information Information that, if lost, altered and/or compromised,

would negatively a ect the owner of the information.
sni ng Sni ng involves observing and gathering compromising information about

network tra c in a passive way.
117
social engineering An attack based on deceiving users or administrators at the
target site. Social engineering attacks are typically carried out by telephoning users or operators and pretending to be an authorised user, to attempt to gain illicit access to systems. substitution cipher A type of cipher that replaces the characters being encrypted with other characters. threat A possible danger to a computer system. token A physical item that's used to provide identity. Typically an electronic device that can be inserted in a door or a computer system to gain access. transposition cipher A type of cipher that rearranges the order of the characters being encrypted, but does not change the actual characters. trojan horse A software entity that appears to do something normal but which, in fact, contains a trapdoor or attack program. trust Reliance on the ability of a system to meet its speci cation. virus A replicating code segment that attaches itself to a program or data le. Viruses might or might not contain attack programs or trapdoors. vulnerability A weakness in a computer system, or a point where the system is susceptible to attack. The weakness could be exploited to violate system security. worm A standalone program that, when run, copies itself from one host to another, and then runs itself on each newly infected host.
118
Index
Access control, 9, 13, 37, 39 AH, 48 Anonymity, 13 Application Layer, 28 Asymmetric algorithm, 19, 35 Auditing, 9 Authentication, 9, 28, 29, 31, 34, 35, 39, 40, 47{49 Authentication Header, see AH Availability, 9, 12 Backup plan, 11 Block cipher, 20, 24 Blow sh, 23 Brute-force attack, 14 Brute-force attacks, 18 CA, 36, 37, 51 Certi cated systems, 13 Certi cation Authority, see CA Chosen-plaintext attack, 15 Ciphertext-only attack, 15 Con dentiality, 8, 12, 31, 37, 39, 47 Confusion, 17, 20 Consistency, 9 Cryptoanalysis, 14, 15, 17, 21 Cryptography, 13, 14, 18, 19, 31, 37 Data Encryption Standard, see DES DES, 21{24, 32, 33 Di e-Hellman, 25{27, 32 Di usion, 17, 20, 24 Digital Signature, 27{29, 31{33, 35, 36 Digital signature, 34 Digital Signature Algorithm, see DSA Digital Signature Standard, see DSS Disaster, 54 Disaster plan, 11, 53 Discrete Logarithm Signature Systems, see DLSS DLSS, 27 DSA, 27 DSS, 27, 28 E-mail, 31, 32 ElGamal, 27 Encapsulating Security Payload, 48 ESP, 48 Extranet VPN, 39, 40, 46 Firewall, 65 Green Book, 12, 13 Homophone substitution, 16 IDEA, 23, 24, 32 Integrity, 8, 12, 29, 31, 35, 37, 47, 48 Intranet VPN, 39, 46 IPSec, 42, 47{50 IP Security, 42 ISAKMP, 50 Key management, 35, 40, 49{51 Known-plaintext attack, 15, 16 L2F, 42, 59 L2TP, 42 Layer 2 Forwarding, 42 Layer 2 Tunneling Protocol, 42
119
INDEX
Level of Security, 12, 30 Link Layer, 30 Mailtrust, 34 Man-in-the-middle attack, 15 Network Layer, 29 Non-brut-force attack, 18 Non Reputation, 9, 28, 31, 35 One-time-pad, 16 Orange Book, 12 Organisational measures, 11, 70 Originality, 13 OSI reference model, 28 PEM, 32{34 PGP, 32{34, 36 Physical Layer, 30 Point to Point Tunneling Protocol, 42 PPTP, 42, 59 Pretty Good Privacy, see PGP Privacy Enhanced Mail, see PEM Private key, 18, 19, 25, 35 Pseudonymity, 13 Public key, 17{20, 25{27, 31, 35, 36 RC4, 25 Recovery concept, 11 Remote Access VPN, 39, 40, 44 Restart plan, 11 Risk Analysis, 9, 11 Risk analysis, 53, 63 Risk Avoidance, 10, 11 RSA, 26, 27, 32, 33, 35 S/Mime, 33, 34 Safety, 7 Secret key, 17{21, 36 Secure Hash Algorithm, see SHA Security, 7 Security Concept, 9, 11, 53, 55, 56 Security measures, 7 Security plan, 11, 53, 54, 65 Security Policy, 11, 40 SHA, 27 SKIP, 50 Stream cipher, 20, 25 Structural measures, 82 Substitution, 16, 17, 21, 22 Symmetric algorithms, 19, 20, 22, 25, 35 Technical measures, 65 Threats, 8, 54, 64 Timing Attack, 15 Transport Layer, 29 Transposition, 16, 17 Triple DES, 21, 32, 33 Trust Centre, 36, 37 Tunnel, 37, 42{46 Tunneling, 42, 44, 46, 59 Unobservability, 13 Vignere cipher, 16 Virtual Private Network, see VPN VPN, 7, 14, 37{40, 47, 49, 56{61, 68, 69 Web of Trust, 36
120

Crptograpy

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Crptograpy

Hochgeladen von

Copyright:

Verfügbare Formate

Analysis and Assessment of Secure Mechanisms for the Building of a Secure Server Network

{ Cryptographic Systems and Applications, in particular Virtual Private Networks {

4.1 4.2 4.3 4.4 4.5

VPN Products Project Planning Questionnaire Abbreviations Glossary

98 101 105 109 113

Chapter 2 Aims and Objectives

CHAPTER 2. AIMS AND OBJECTIVES

Chapter 4 Technical Background and Context

4.1 Safety and Security

CHAPTER 4. TECHNICAL BACKGROUND AND CONTEXT

4.2. SECURITY CONCEPT

4.2 Security Concept

CHAPTER 4. TECHNICAL BACKGROUND AND CONTEXT

DISASTER PLAN SECURITY PLAN

SECURITY POLICY SECURITY CONCEPT

4.3. EVALUATION OF A SECURITY CONCEPT

4.3 Evaluation of a Security Concept

CHAPTER 4. TECHNICAL BACKGROUND AND CONTEXT

D | Minimal Protection C | Discretionary Protection B | Mandatory Protection A | Veri ed Design

CHAPTER 4. TECHNICAL BACKGROUND AND CONTEXT

4.4.1.1 Cryptanalysis and Attacks on Cryptosystems

CHAPTER 4. TECHNICAL BACKGROUND AND CONTEXT

4.4.1.2 Substitution and Transposition

4.4.1.3 Di usion and Confusion

4.4.1.4 Secret or Public key

CHAPTER 4. TECHNICAL BACKGROUND AND CONTEXT

CHAPTER 4. TECHNICAL BACKGROUND AND CONTEXT

4.4.1.5 Stream cipher and block cipher

4.4.1.6 Strength of Cryptographic Algorithms

4.4.2 The most important methods for secret key systems

4.4.2.1 Data Encryption Standard (DES and Triple DES)

CHAPTER 4. TECHNICAL BACKGROUND AND CONTEXT

CHAPTER 4. TECHNICAL BACKGROUND AND CONTEXT

4.4.2.4 Block cipher modes

using the operation XOR - exclusive OR

4.4.3 The most important methods for public key systems

CHAPTER 4. TECHNICAL BACKGROUND AND CONTEXT

4.4.3.3 Digital Signature Algorithm

CHAPTER 4. TECHNICAL BACKGROUND AND CONTEXT

4.5 Encryption in di erent Layers

4.5.1 Encryption in Layer 7 (Application Layer)

4.5. ENCRYPTION IN DIFFERENT LAYERS

4.5.2 Encryption in Layer 4 (Transport Layer)

4.5.3 Encryption in Layer 3 (Network Layer)

CHAPTER 4. TECHNICAL BACKGROUND AND CONTEXT

4.5.4 Encryption in Layer 2 (Link Layer)

4.5.5 Encryption in Layer 1 (Physical Layer)

4.6 E-Mail Security

4.6. E-MAIL SECURITY

4.6.1 Security Problems in connection with e-mail

CHAPTER 4. TECHNICAL BACKGROUND AND CONTEXT

4.6.1.1 Attacks on Servers

4.6.1.2 Attacks on Clients

4.6.2 Privacy Enhanced Mail

4.6.3 Pretty Good Privacy

4.6. E-MAIL SECURITY

CHAPTER 4. TECHNICAL BACKGROUND AND CONTEXT

4.8. KEY MANAGEMENT

4.7.1 Digital Signature

4.8 Key Management

CHAPTER 4. TECHNICAL BACKGROUND AND CONTEXT

4.8.1 Web of Trust