Secure Communication System
Page 1
University of Portsmouth
Computing & Mathematics Programme Area
Final year project undertaken in partial fulfillment of the requirements for the
BSc (Honours) in Computer Sciences
Secure communication system
By
Chi Keung Li
Supervisor: Dr. Kit Lester
Project unit: PJE20
2004
Abstract
This project sets out to investigate about security: by building a secure protocol and analyze the different aspects of the resulting product.
The secure protocol will be implemented as a chat system first. Then the system will be analyzed about the strength and performances. However, the protocol could be used for other purposes as well.
Security is a matter of balancing different tradeoffs. In this report, there are many comparisons about why different tools and algorithms are chosen.
Ultimately, this project strives to find out why people keep away from implementing security mechanisms properly; and give suggestions about what can be done to educate people with security in mind.
Contents
Acknowledgments......
1.Introduction......
1.1.Background......
1.2.Problem Definition......
1.3.Aims......
1.4.Objectives......
1.5.Limitation......
2.Analysis......
2.1.Fundamentals of Cryptography......
2.2.Modern Cryptography......
2.3.Complexity and Strength......
2.4.One-way hash functions......
2.5.Academic papers reviewed......
3.Requirement Analysis......
3.1.Feasibility analysis......
3.2.Specification......
3.3.Methodology......
4.Design......
4.1.The login model......
4.2.The program design......
4.2.1.Message Passing......
4.2.2.Inheritance......
4.2.3.Interface Outputable......
5.Implementation......
5.1.Tight Control by export laws......
5.2.Java......
5.2.1.JCE......
5.2.2.Unlimited Strength Jurisdiction Policy File......
5.2.3.keytool......
5.2.4.Netbeans......
5.3.Secret algorithms or Open algorithms......
5.4.Ciphers......
5.5.A typical session......
5.6.The Challenge Process and Hashing Functions......
5.7.Theoretical Strength......
5.8.Random numbers......
5.8.1.Entropy source comparison among different OS......
5.9.Key Stores and Certificates......
6.Evaluation......
6.1.Testing......
6.1.1.Test case listing......
6.2.Performance Issues......
7.Conclusion......
7.1.Specification revisited......
7.2.Things to be improved......
7.3.The flexibility of the system......
7.4.The lack of real experts......
7.5.Security’s genuine owner......
Bibliography......
Appendix......
ADesign Diagrams......
BTest machine configuration......
Cjava.security configuration file extract......
DGantt Chart......
EList of Figures......
FSource Code......
Acknowledgments
For this report I would like to thank my current supervisor Kit Lester for filling me the missing part of the concepts of academic projects (and correcting my “Chinglish” as well). Without him, maybe this project would be “yet another e-commerce system”, or having a report that has 50% of design diagrams like what I did before.
Also Bruce Schneier, for writing books about cryptography, especially the “legendary” Applied Cryptography that enlightened me about cryptography. For the readers feeling uncomfortable about the security terms, I recommend you to read that book to get the whole picture about security: because security is not a collection of individual parts – but a whole system. However, for the ones who are impatient or in a hurry, wikipedia.org is a good source to find out the meanings of the terms.
1.Introduction
The introduction chapter will discuss about the background of the project; the problem identified. Aims and Objectives that are made to solve the problem will be listed.
1.1.Background
Security plays an important role in our lives, that is the reason there is a lock on almost every door, and people carry keys around wherever they go. If all people are assumed to be good, the locks on the doors (the locks on the semaphores are exception) need not exist after all.
In the real world, it is never a safety place. People would like to break other’s security, privacy and identity for their advantage. The very first thing is, humans are curious – the curiosity that cannot be satisfied by the right means. For example, many parents are actually reading their children’s letters; celebrities fans would chase the celebrities until they got home; and government agencies like FBI and CIA (as seen on TV) will actually wiretap your phone, your car[Smith03], or even your sandwich for lunch if they could.
Leaking information can cause harm, from an admirer of you appears in front of you all the time to losing a contract worth $1.4 billion (Military Intelligence Organizations Involved) [Schneier96, page 55].
Moreover, if the attacker not only curious, but also use the information collected against you: such as impersonate you and use your card to shop (both in real life and cyberspace) then maybe you will need some means of security to protect yourself.
1.2.Problem Definition
In my observation, many people developing projects in this university did not ever realized what security is – some of them are building a game, security is not that important; but some of them are actually building an inventory system, or even an online e-commerce system: that is similar to passing in a football game and expecting no one will steal or intercept the ball. This could be solved by encryption – protection against eavesdropping. Moreover, what if someone replaced the ball passed to you with a bomb? Integrity checks could be used to ensure the message passed has not been tampered.
Apart from encryption, authentication is also important – having secure transaction to someone whose identity is not confirmed does not make you secure – they could be impersonators or dishonest people[1]. However, authentication is a difficult task to perform – the user name and password approach does not work very well. It is fairly easy to get stolen and the disadvantage of passwords will be discussed later in this report. To overcome the insufficiency of the strength of the password, digital keys are used in the project instead (and the CA hierarchy, which will be discussed later).
From some of my friends who are in the industry, they just rely on some instant package to provide the security and without a person to verify (or at least have a brief idea of) the claims of security strength; also without someone to investigate the whole design of the security model. Simply implementing an instant package is never enough – attackers will try somewhere else. For example: random number generators, cache files and keyboard buffers are just a few examples where the real weaknesses are dwelling – Poor security implementation is simply wasting system resources for nothing.
Due to the time and labor constraints, developing a totally perfect system is out of the scope of this project; what this project attempted to do – is to develop a moderate secure system by of the shelf components with a security model; and analyze the possible attacks that could be mounted. This project will also try to show the performance and the degree of convenience of implementing a moderate secure system as well.
1.3.Aims
The aim of this project was to develop a simple security communication system and investigate the level of security and performance of it. The communication protocol can be deployed in chat; also preparing a base protocol allowing other forms of communication possible as well: such as FTP, online game server or any new services.
The system will be deployed as a chat system first. How authentication and cryptography benefit a chat system?
No eavesdropping – secret or serious communication can be conducted
Authentication – better trust of the messages, because there is a better guarantee that the users are exactly who they are.
With these new features, this chat system could fulfill the requirements of serious purposes such as business meeting.
Also, for better organization; padding and representation of the message hierarchy are added to the messages – organizing the message in the style of newsgroup and bulletin board – each replying message will reference to the parent message.
And of course, the application of the system can be more than chat with the protocol as previously mentioned.
1.4.Objectives
Find out the tools needed for the program.
The tools including: the hardware, the development language, development library and IDE etc.
Build the program.
Construct the artifact within the specifications, time and tools; solve development issues etc.
Analyze the security strength of the program.
To find out how security one can get from free software tools, as well as the performance of the cryptography tools
Analyze the performance.
The ciphers, especially the asymmetric ones, are known to be slow, but how slow?
1.5.Limitation
Security has many aspects – this project is about user authentication and encryption, the security about the data not being read by unauthorized third parties and the authentication of both ends of the communication. The system is not capable to withstand DoS (Denial-of-Service) attacks by means of flooding, signal jamming, physical damage to the server hardware etc.; and the system is not intended to have a strong protection for the key store files – modifying or even destruction of the key store file could already undermine the strength of the system. The system is to demonstrate the feasibility of implementing a system with moderate security.
2.Analysis
In this session, different mechanisms and theories about security will be discussed. This session will identify what a modern secure system is made of by investigating different parts of a secure system.
2.1.Fundamentals of Cryptography
Cryptography is the studies about encryption and decryption. What encryption does: is to transform the input message (plaintext) into unreadable form (ciphertext): except the ones with appropriate key. In order to do so, a cipher is used: it transforms the plaintext according to a puzzle. To reverse this process, the solution (key) of the puzzle and the ciphertext is brought to the cipher and the reverse is done.
Figure 1 Encryption and decryption with a key [Schneier96, Page 3]
In the past, the puzzles are simple: for example, the Caesar Cipher 2000 years ago. Caesar used the Caesar Cipher, which he used to convey commands to the battlefield. The Algorithm is simple, simply rotating the characters for a specific pattern – for example: the pattern is to rotate right for 3 characters [Schneier96, page 11]: then “ROMAN ARMY” becomes “OLJXK XOJV”. Ciphers that rotates the characters in a specific pattern such as this; is fairly easy to break by analyzing the repeating patterns: As you may see, there are 2 X and 2 O here; we can compare that pattern with the alphabet pattern of the plaintext’s language – the longer the plaintext, the easier to break. For people who are interested about the classic cipher’s history, I recommend the book [Singh99].
2.2.Modern Cryptography
From hand compiled Caesar Cipher, to the mechanical Enigma machine in World War II and today’s computerized asymmetric ciphers – as the technology progresses, cryptography puzzles have become more and more complex. With the aid of computer technologies, heavy calculations that were unfeasible for human to operate have become possible. Modern cryptography puzzles are mostly based on mathematical problems.
Ciphers were symmetric – encryption and decryption used the same key. This causes a big problem: how to exchange the key? The problem is considered impossible to solve until 1976 – when Whitfield Diffie and Martin Hellman demonstrated the first public-key algorithm at the National Computer Conference [Schneier96, Page 461].
Figure 2 Encryption and decryption with two different keys [Schneier96, Page 4]
In the public key algorithm, a user has a pair of keys – each key can decrypt the ciphertext encrypted by the other key. In actual implementations: one key will be chosen as the public key, and the other as the private key – the public key are allowed to be published without sacrificing the security; while the private key must remain secret.
To send a message to Alice; the message is encrypted in Alice’s public key, and then Alice could use her private key to decrypt the message. The process can be done in the other way: encrypt with the private key and decrypt the public key (this process is called signing); providing another function – authentication. If the public key could decrypt the message – then the message must have been encrypted by the private key; and only the key owner will have the access of the private key – as a result, the message is confirmed from the owner.
2.3.Complexity and Strength
Keys, random numbers and cipher parameters etc. have different lengths. The lengths of them are critical to the security strength of the system: the more the length, the more the complexity[2] – and harder to break. However, that will costs more time to generate and use. A general guideline is the lifetime of the data (e.g. a Patent’s lifetime is a few decades) – if the time that the data is compromised is later than then the lifetime of the data, and then it could be said strong enough. Another guideline is based on the effort – if the effort required compromising the data is more than the value of the data, and then it could be said strong enough.
2.4.One-way hash functions
Note that the asymmetric cipher is slow – slower than symmetric cipher for an order of magnitude – signing the whole message is inefficient. Thus, people come up with another idea – generate a unique representation of the message; and sign that representation instead of the original message; that representation is known as hash.
Hashing is a process to make a fingerprint of the input: the output hash will have a specified size (128bit for MD5), and each input will produce different output (ideally) – so that we can check the integrity of the input: for example a contract; by hashing it and compare with the hash provided by the other side.
One attack against hash functions is called Birthday Attack. What this attack is about is to produce two messages that hash the same value. A classic example that was proposed by Gideon Yuval (He works for Microsoft Research’s Cryptography Group)is [Yuval79]: Assume Alice is going to sign a contract with Bob. To gain advantage of the flaw, Alice would:
1Produce another version of the original contract, which:
1.1Hashes the same value
1.2More favorable to Alice (optional)
2Bob signed the original contract’s hash with his private key
3Later, Alice hand the modified version of the contract and Bob’s signature to the court; and claims that Bob signed the modified version
Step 1.2 is optional, because – in extreme cases, Alice could claim that the modified version (which is just plain garbage) was encrypted with one time pad (or whatsoever).
Thus, now it is recommended to use SHA-1 (160 bit) than MD5 (128 bit) to minimize the possibility of Birthday Attack.
2.5.Academic papers reviewed
To investigate about different parts of a security system; some papers were reviewed.
“Cryptanalytic Attacks on Pseudorandom Number Generators” [John Kelsey, Bruce Schneier, David Wagner and Christ Hall, 1998]
“Initial Cryptanalysis of the RSA SecurID Algorithm” [Mudge and Kingpin, @stake Inc., 2001]
These two articles are about the different aspects of a security system. The fist one is about the common weakness of the Pseudorandom Number Generators (PRNG), while the second one is to show that any algorithms can be decompiled – keeping the algorithm secret does not improve security.
3.Requirement Analysis
Before doing any real work, it is important to know if that is worth to do. If that is infeasible: maybe we will need another solution, or we need to check that if the aims or objectives could be compromised or not.
If the project is feasible, then to what extent the product can satisfy the aims and objectives (specification) need to be explored. If the aims were “Fill the stomach”; then the objective would probably be “Prepare tonight’s dinner”; and the specification could be “Make a sandwich” or “Pay a visit to a French Restaurant” – the degree of satisfaction of aims and objectives is what specification about.
The way to work is also important – that is the matter about methodology. Methodology divides the big project into stages – which you could divide and conquer. Different situations need different methodologies; the model chosen is to give an estimate of when to do what.
3.1.Feasibility analysis
The project is to integrate the available components into a secure protocol, which is technology feasible. Eventually produce the artifact according the specification.
The limiting factor is security – the actual strength cannot be determined in a specified time. Thus, possible attacks will be explored and fixed.
3.2.Specification
To fulfill the aims and objectives, a protocol and a system based on the protocol are built. What functionalities they are supposed to have will be listed here – for guiding the development.
The system should be secure
Each party can identify whom are they talking to
The system will consists of a server and a client program
Server
Able to receive multiple users’ connection simultaneously
Authenticate user
Decrypt and process users’ message
Manage users’ messages
Register users
Managing key entries of the server and users
Client
Using user’s key pair
Able to use the key pair of the user
Able to authenticate the server
System must be extensible, because the time reserved for this project is far from sufficient to develop a perfect system.
3.3.Methodology
To build an artifact, different methodologies are available. The waterfall model is widely used in many projects. Its advantage is every steps are in order and easy to follow. However, it would take huge effort to do back steps. Then we have Spiral model, which go through each steps repeatedly – performing incremental improvements in every cycle.
Figure 3 Boehm’s Spiral model [Boehm86], image extracted from