Secure MSN Messenger Messenger

Transcription

Secure MSN
Messenger
Darren McCourt
Supervised by
Ning Zhang
Darren McCourt
Secure MSN Messenger
Abstract
Secure MSN Messenger by Darren McCourt
Supervisor: Ning Zhang
This report sets out to provide an overview of the BSc Computer Science third
year project of Darren McCourt, entitled Secure MSN Messenger.
The report will start by discussing the initial project proposal and the aims and
objectives of the project. It will prove sufficient background information for
readers without specific cryptography and network security knowledge to
understand the report.
The design and implementation of the application produced will be discussed
paying particular attention to areas of interest or that proved challenging. The
testing of the software will also be analysed taking into consideration the tests
carried out and whether or not their results confirm that everything works
correctly.
The functioning application will be demonstrated showing key aspects of its
functionality and intended use. This will not only show the problems solution
but also the problem side by side to allow a direct before and after
comparison to be made.
The report will finally conclude with an evaluation of the, looking at the
success of the project, its achievements and failures, outstanding work and
potential future work in this area.
2
Darren McCourt
Acknowledgements
I would like to take this opportunity to thank several people for their continued
support through out my undergraduate career and specifically for my third
year and this project.
Firstly, I would like to thank my project supervisor Ning Zhang for her
excellent advice and guidance throughout the project.
I would also like to thank my friends and peers for the patience and effort in
helping me through this project, providing advice and help with testing the
application through endless frustrating crashes.
I would finally like to thank my parents and family for the support and love
they have given me through the good times and the bad and for their
continued faith in me.
3
Darren McCourt
Table of Contents
1
2
3
4
5
6
7
8
Introduction ...............................................................................................6
1.1
The Problem ......................................................................................6
1.2
The Project Proposal .........................................................................6
1.3
Other Work in This Area ....................................................................7
1.3.1
SimpLite-MSN ............................................................................7
1.3.2
Off The Record (OTR) Messaging..............................................8
1.4
The Proposed Solution ......................................................................8
1.4.1
Message Confidentiality .............................................................8
1.4.2
Authentication.............................................................................8
1.4.3
Perfect Forward Secrecy ............................................................9
1.4.4
Non-Repudiation ........................................................................9
Background and Literature Survey .........................................................10
2.1
Symmetric Cryptography .................................................................10
2.2
Public Key Cryptography .................................................................10
2.3
MSN Messenger..............................................................................11
2.4
Gaim ................................................................................................11
2.5
Open Source Messaging Application Development.........................12
2.6
NSS .................................................................................................12
2.7
Cryptography and Network Security ................................................13
Design ....................................................................................................14
3.1
Configuration GUI............................................................................14
3.2
Public / Private Key Pair Generation and Storage ...........................15
3.3
Saving / Loading Preferences..........................................................15
3.4
Key Transportation and Verification.................................................16
3.5
Dealing With Non SIM Clients .........................................................17
3.6
Object Oriented C............................................................................17
Implementation .......................................................................................18
4.1
Sending and Receiving Messages ..................................................18
4.2
Initiating a Secure Conversation......................................................19
4.3
The Hash Function ..........................................................................22
4.4
Encrypting and Decrypting...............................................................23
Results....................................................................................................25
Testing....................................................................................................34
6.1
The GUI ...........................................................................................34
6.2
The Hash Function ..........................................................................35
6.3
Symmetric Encryption......................................................................36
6.4
Sending and Receiving Messages ..................................................36
Evaluation and Conclusion .....................................................................37
References .............................................................................................38
4
Darren McCourt
Table of Figures
Figure 1: Ethereal in Action..............................................................................6
Figure 2: Proposed Configuration GUI...........................................................15
Figure 3: An unsecured conversation ............................................................26
Figure 4: A SIM secured conversation ...........................................................26
Figure 5: Implemented Configuration GUI …………………………………….. 26
Figure 6: Starting a SIM Secured Conversation ……………………………… 26
Figure 7: Ethereal, wakeup mesage ..............................................................28
Figure 8: Ethereal, initiation message............................................................28
Figure 9: Behaviour with a non SIM client......................................................29
Figure 10: Ethereal, acknowledgement message ..........................................29
Figure 11: Ethereal, public key message 1 ....................................................29
Figure 12: Ehtereal, public key message 2 ....................................................30
Figure 13: User authentication of a public key ………………………………... 29
Figure 14: Ethereal, symmetric key message ................................................30
Figure 15: Ethereal, symmetric key ok message ...........................................30
Figure 16: Ethereal, Conversation message 1 ...............................................31
Figure 20: Ethereal, end message .................................................................33
Figure 21: Gaim conversation, end message ................................................33
5
Darren McCourt
1 Introduction
1.1 The Problem
Most of our day to day communications today are unsecured. Telephone, email and Instant Messaging (IM) are only a few. Although it is quite obvious
that e-mail and IM travel across the internet on their journey from one user to
another it is perhaps less obvious that the telecoms industry are increasingly
using the internet to route long distance calls using voice over internet
protocol (VOIP). Any of the data packets used to carry any of these
communications can easily be intercepted by anyone with the right equipment
and knowledge.
Figure 1: Ethereal in Action
Instant Messaging is a huge business. According to Microsoft there are over
240million worldwide users of its Instant Messaging solution, MSN Messenger
[1]
. This is only one network, there are numerous others: AIM, ICQ, Jabber,
Yahoo, Google Talk and many others.
With IM being such a big business, with so many users using it so often it is
an obvious target for attackers seeking to breach the privacy of its users. It is
apparent that providing a method of securing these communications would be
a useful thing to do.
1.2 The Project Proposal
The initial project proposal was to create a piece of software to allow secure
and authenticated communications over the MSN Messenger Service. This
was to be achieved by providing message confidentiality and authentication.
6
Darren McCourt
Securing an existing instant messaging network is preferable to producing a
new network from the ground up for several reasons:
• Unified communications is some people’s idea of the future of
electronic communication. One person, one single point of contact. In
the world today anyone who makes frequent use of the internet will
have a huge list of accounts and points of contact. Taking the email
accounts of a typical computer science student as an example. When
he signed up for his internet access his ISP gave him an email address
and account. When he joined the University of Manchester they too
gave him an email account with multiple aliases. When he joined the
school of computer science he was given yet another email account
with even more aliases. He signed up for the MSN Messenger Service
which gave him another email account and email address. Which email
address do you use to contact this person? Do you even send an
email? A message on Facebook or MySpace might reach him quicker.
Looking at this tiny section of one person’s online presence reveals 6
accounts that could be used to contact them. Creating another service
with yet another account is not a step towards unified communications.
• Existing instant messaging networks already have many users. A given
circle of friends will likely all have accounts with the same service. All
these friends don’t want to move to a secure service because two of
them need to communicate securely. These two friends with security
requirements don’t want to have to use two different services to
communicate with their friends.
• By extending an existing instant messaging network there is already a
potential market ready and waiting.
The MSN Messenger Service has been chosen as the network to secure due
to the sheer volume of users it has. According to Microsoft there are over
240million users worldwide [1].
1.3 Other Work in This Area
The problem of unsecured Instant Messaging has been around for a long time
and is well known. As such this is not the first attempt to provide a solution to
the problem. A quick search on Google will reveal many products claiming to
provide secure Instant Messaging and many will successfully achieve this via
different approaches.
1.3.1 SimpLite-MSN
SimpLite-MSN [2] is the first MSN specific offering discovered. It appears to be
a very commercial product with a broad audience including novices and more
advanced users. Because it seems to target users with limited security
knowledge the detail of how it works is largely hidden. Because of this it is an
unattractive solution as hiding this detail may in fact be hiding flaws and
vulnerabilities.
7
Darren McCourt
1.3.2 Off The Record (OTR) Messaging
Off The Record Messaging [3] is an open source project which is available in
several forms. The main application is a plug-in for the open source, multiprotocol IM client, Gaim. As OTR is open source the details of its workings are
freely available for all to see. The documentation provided is comprehensive
and makes no attempt to hide the workings of the software for the
inexperienced. This makes OTR an attractive solution and was made popular
by news coverage and reviews in the not to distant past. However OTR has
one major shortcoming.
Deniability
“The messages you send do not have digital signatures that are
checkable by a third party. Anyone can forge messages after a
conversation to make them look like they came from you. However,
during a conversation, your correspondent is assured the
messages he sees are authentic and unmodified.” [3]
In certain situations this may desirable but by omitting digital
signatures the security of the conversation is reduced and more
susceptible to man in the middle attacks.
1.4 The Proposed Solution
There are many pieces of software in the world which fulfil the initial project
proposal of this project. However they are not all good. Some of the problems
with what currently exists are illustrated by the two examples above.
The proposed solution to solving this problem is to be achieved by
implementing up to four main security features as a plug-in to Gaim:
• Message Confidentiality
• Authentication
• Perfect Forward Secrecy
• Non-Repudiation
1.4.1 Message Confidentiality
Message Confidentiality ensures that any messages passed across the
network will be undecipherable to eavesdroppers. A message passed
between Alice and Bob will be readable only by Alice and Bob. This is what
most people think of when talking about encryption.
1.4.2 Authentication
Authentication ensures that each party in conversation is communicating with
exactly who they think they are. Alice can be confident that she is talking to
Bob and Bob can be confident that he is talking to Alice.
8
Darren McCourt
1.4.3 Perfect Forward Secrecy
Perfect Forward Secrecy is slightly more complicated to explain. Perfect
Forward Secrecy ensures that should an attacker manage to break the
encryption on one conversation or gain access to a user’s long term keys, any
other conversations (past or future) will remain secure. There is no single key
that connects the Message Confidentiality of every conversation.
1.4.4 Non-Repudiation
Non-Repudiation ensures that for any given message it can be proven to have
been created and sent by a given party and this party cannot deny creating
and sending it. If Alice sends a message to Bob, Bob can be sure the
message came from Alice (and only Alice) and Alice cannot deny sending the
message. The message can be proved to have come from Alice.
It would be quite a simple thing to also support Deniability as in Off the
Record Messaging by toggling between signing and not signing the
messages.
To simply implement these four features would produce solution very similar
to OTR which could be much quicker implemented by modifying the OTR
source. This project aims to go further than this and other solutions by giving
the user more control over how their messages are secured. The user will be
given control over which encryption algorithm is used and how keys are
exchanged. This project does not target the average MSN Messenger user
but the advanced user with the knowledge to be able to pick a security
combination to meet their needs.
The target user of this project is not a government agent with national security
in mind; he would likely require a much greater level of security. It is also not a
teenager girl using MSN to discuss the latest episode of Hollyoaks. It is the
users in the middle with the knowledge to understand and appreciate the
problem who believe they have something to talk about that requires security.
Think of a stereotypical script kiddie, a bedroom hacker or closet geek.
This report will continue by providing a brief background to cryptography and
network security. This should hopefully clarify any points of misunderstanding
experienced up until now and allow the reader to understand and appreciate
the remainder of the report. With this knowledge the design and
implementation of the application will be detailed and the final product will be
demonstrated. The report will focus on the most interesting points and
challenging areas of the application development. The report will finish by
looking at how the application was tested will evaluate the success of the
project before concluding.
9
Darren McCourt
2 Background and Literature Survey
2.1 Symmetric Cryptography
Symmetric cryptography uses a single key for both encrypting and decrypting.
In a secure exchange between two parties, both parties must be in
possession of the same key.
C = E (K, P), P = D (K, C)
Where:
P
Plain text
C
Cipher text
E () Encryption function
D () Decryption function
K
Symmetric Key
2.2 Public Key Cryptography
In contrast to symmetric encryption in public key cryptography a given entity
or person has a pair of keys, one public and one private. The two keys are
mathematically linked and are not independent of each other. Data encrypted
with one key can only be decrypted by the other. E.g. If Alice encrypts
something with her private key only her public key can be used to decrypt it,
and vice-versa.
C = E (Kprv, P), P = D (Kpub, C)
C = E (Kpub, P), P = D (Kprv, C)
Where:
P
Plain text
C
Cipher text
E () Encryption function
D () Decryption function
Kprv Private key
Kpub Public key
As their name suggests one key is private and the other public. Anyone can
be given a copy of the public key but only the entity to which the private key
belongs should have access to the private key. To further enforce this private
keys are often stored in an encrypted form using symmetric cryptography with
a pass phrase that only the owner of the key knows. It is therefore impossible
to use the private key without knowing the pass phrase to decrypt it.
One of the main ideas behind the development of public key cryptography
was to make the problem of key distribution easier. In symmetric cryptography
for two parties to securely communicate they have to first securely exchange
a common key, ensuring that no one else gets hold of this key. This is a
significant problem. With public key cryptography public keys are made freely
available and anyone can encrypt something using a person’s public key and
10
Darren McCourt
only that person will be able to decrypt it. If Alice wishes to send a secure
message to Bob all she needs to do is encrypt it with Bob’s freely available
public key and because only Bob’s private key can decrypt it, only Bob will be
able to view the message.
Public key cryptography also has other uses such as authentication and
digital signatures which are not be possible with symmetric cryptography.
Because only Bob has access to Bob’s private key, anything encrypted with
Bob’s private key has to have come from Bob. Alice, having access to Bob’s
public key, can be assured that a message came from Bob if she can decrypt
it using Bob’s public key.
In general it is much slower to encrypt or decrypt something with public key
cryptography than it is using symmetric key cryptography. The resulting cipher
text is also generally much longer. To overcome these problems a hybrid
approach is often used. A communication is authenticated using public key
cryptography but for the majority of the communication symmetric key
cryptography is used. A symmetric key is generated by one party and
securely transmitted to the other using public key cryptography. Once both
parties are in possession of this symmetric key they exchange data using
symmetric key cryptography. The symmetric key is often called a session key
as it is normally only used for the current session and then destroyed.
2.3 MSN Messenger
To develop an application to secure the MSN Messenger Service it is first
necessary to have a detailed understanding of how the service works. How
messages are sent and received and how the protocol can be exploited and
unofficially extended.
MSN Messenger, or Windows Live Messenger as it is now known, is
Microsoft’s instant messaging solution. Most recent versions of Windows
came with the software preloaded in one form or another, mainly Windows
Messenger. Whatever Microsoft’s client is currently called they all use the
MSN Messenger Network.
The MSN Messenger Network is a closed network and there is no publicly
available documentation on its protocol(s). However there are several
unofficial guides available online which have been complied by reverse
engineering the protocol using packet sniffing software and analysing the
messages transferred between the messenger client and servers.
As the service is closed it is obviously impossible to install any additional
software on the MSN Messenger servers and so the security must be end to
end and be transparent to the servers in between.
2.4 Gaim
Gaim was a multi-protocol instant messaging client. It ran on several
platforms including Windows, UNIX and BSD. Gaim provided a very flexible
11
Darren McCourt
plug-in structure which made an excellent base for instant messaging
development.
The Gaim project is still in existence but for legal reasons has had to change
its name to Pidgin. The Gaim core library, libgaim, is now called libpurple and
there have been several other changes in naming conventions [4].
This project was built using Gaim 2.0.0beta6. The most current release is
Pidgin 2.0.0beta7.
Because of this recent change (April 6th 2006) the Gaim API used when
building this project is no longer available and has been replaced by an
updated version using the new naming convention. This report shall try to use
the Gaim naming convention throughout but the reader should be aware of
the change. When referencing the Gaim / Pidgin API this report will attempt to
provide the reader with both the new and the old names.
2.5 Open Source Messaging Application Development
Egan, Sean. “Open Source Messaging Application Development: Building and
Extending Gaim”. ISBN 1590594673. Apress, June 16, 2006.
The book ‘Open Source Messaging Application Development: Building and
Extending Gaim’ proved to be an excellent source of information, not just on
Gaim, but on instant messaging and programming in general. It was this book
that was the inspiration to develop this software as a plug-in for Gaim rather
than building a separate application from the ground up. It became apparent
that by using Gaim as a base it would be possible to focus on the security
side of the application rather than getting bogged down with the details of
implementing the MSN Messenger protocol. It also became evident that
because Gaim abstracts the details of the protocol implementation and
provides protocol independent methods for sending and receiving messages
and so forth it would be possible to produce a solution that would not only
work for MSN Messenger but any protocol that Gaim supports. ‘Out of the
box’ Gaim supports twelve different protocols and more can be implemented
as plug-ins.
2.6 NSS
“Network Security Services (NSS) is a set of libraries designed to support
cross-platform development of security-enabled client and server applications”
[5]
. NSS is used by many high profile applications including Mozilla Firefox and
Thunderbird, OpenOffice and Apache, as well as by Gaim itself [5]. As NSS is
used in Gaim, anyone who has Gaim also has the NSS libraries and so it
seemed like an obvious choice to use these libraries to aid in implementing
the security features of this project. Their use in the previously mentioned high
profile software further supported this decision.
12
Darren McCourt
2.7 Cryptography and Network Security
Stallings, William. “Cryptography and Network Security”. ISBN 0131873164.
Prentice Hall, 16 Nov 2005.
William Stallings book provided an excellent reference for understanding the
security features that this project was going to implement. As well as
explaining general principles the book also looks at specific implementations
weighing up their pros and cons. AES as an example of a symmetric cipher is
an example of this. This formed the basis for selection of the algorithms that
would initially be implemented.
13
Darren McCourt
3 Design
Having discovered during research that it would be possible to provide the
same security to any instant messaging protocol that Gaim supports the
decision was made to call the resulting software Secure Instant Messaging
(SIM), which is how it shall be referred to for the remainder of this report.
This chapter will discuss the design of Secure Instant Messaging (SIM). It will
start by looking at the application as a whole from a high level before
descending into more detail for smaller components paying particular
attention to those areas where specific decisions had to me made.
In designing SIM the high level task of building an application to do x, y and z
was broken down into manageable tasks that could be considered on their
own before being integrated together to form the application as a whole.
These tasks included:
• Configuration GUI
• Public / private key pair generation
• Key storage
• Saving / loading preferences
• Key transportation and verification
• Initialising a secure conversation
• Dealing with non SIM clients
• Hash functions
• Symmetric key generation
• Signing and verifying data
• Dealing with failures
• Ending a conversation
3.1 Configuration GUI
As with most applications the main interaction with SIM will be through a
Graphical User Interface (GUI). Although most of the everyday use of the
application will be using the Gaim GUI it was important to make sure that
configuring SIM was as simple as possible. Even though its target audience
would very likely have a lot of computing experience it is in no way desirable
to have a frustrating to use user interface. Because of this, the design of the
configuration GUI was considered first. This would allow the GUI to be used
and tested for the longest period before the deadline and by doing this any
changes or areas of bad design could be ironed out. It also emphasises the
importance of usability in program design and implementation. Another
reason for starting the design with the GUI was that the GUI would be the first
thing that would be used by a new user to SIM and the developers in testing
the application.
The design of the GUI uses tabs to provide easy access to all the functionality
desired without overwhelming the user. The positioning of the tabs represents
what it was believed the average user would use the most, i.e. managing their
secure contacts. For example once the user has generated a key pair they
14
Darren McCourt
probably won’t need to go back to this tab except to view the hash of their
public key. Because this is potentially quite a frequent thing to want to do it is
probably more desirable to have the option of doing this without entering the
configuration GUI.
Figure 2: Proposed Configuration GUI
3.2 Public / Private Key Pair Generation and Storage
In an ideal world it would be preferable to have one pair of keys for
everything, physically and electronically. One set of keys for the house, the
car, the office and the parents’ house. In the same way it would be nice to be
able to use to use the same key pair for SIM, SSH, e-mail and so on.
However due to the varying types of key in use and the different ways they
are stored it seemed more practical, at least initially, to generate and use keys
from within the application itself. The key type and length decided was an
RSA key pair with a length of 1024 bits. In the security community in general
this seems to be an accepted length, 512 bits is too short and can be
relatively easily broken and anything much longer than 1024 has speed
implications.
The keys will be stored in individual files anywhere on the users system and
referenced and loaded by storing the full path in the preferences file. This file
would be in a known location and so able to be loaded by the application with
no user intervention.
3.3 Saving / Loading Preferences
The decision was made to store the preferences in a plaintext human
readable XML file. This has the advantage that it can be easily understood
and manually edited if required. Gaim provides a type called xmlnode which
represents a node in an XML file and can have data and attributes added to it
and be used to build trees representing entire XML files. Using helper
15
Darren McCourt
methods it can be exported to a string and subsequently saved in a well
known location ready to be read and processed upon loading the application
at a future date. As well as simple preferences the locations of the users
public and private keys will be stored in this file as well as details of any
secure contacts the user may have.
The intended format of this file is shown below:
<Preferences>
<Contacts>
<Contact protocol-id='…' account-username=’…’ screenname=’…’>
<key>…</key>
</Contact>
</Contacts>
<MyKeys>
<public-key>…</public-key>
<private-key>…</private-key>
</MyKeys>
</Preferences>
3.4 Key Transportation and Verification
In order for two users, Alice and Bob, to be mutually authenticated, that is for
both parties to be authenticated to each other, it is necessary for each party to
have the other party’s public key. Although public key cryptography set out to
overcome some of the problems of key distribution with symmetric keys, key
distribution is still a major problem. For example, an attacker Eve could give
Bob her public key claiming it is Alice’s. If Bob doesn’t verify the authenticity of
this key Bob could then initiate secure conversations with Eve, believing she
was Alice and the entire security effort would be wasted.
Digital certificates are one solution to this problem. In this situation Alice
would have her public key signed by a mutually trusted third party with a well
known public key. Because this third party has signed Alice’s key and Bob
trusts this third party, he therefore trusts that the key they have signed is
Alice’s.
However digital certificates with any real level of credibility are costly and it is
unfair to impose a monetary cost in order to have a secure and authenticated
conversation. Instead of using digital signatures SIM will use a second
communications channel to verify keys, a telephone call for example. Bob
recognises Alice’s voice and so can call her and compare the hash value of
the key he has been given with the hash value of the key Alice has. If the two
values match the keys are the same and because Bob knows he is talking to
Alice he now trusts that the key he has is in fact Alice’s.
Although this solution imposes a minor inconvenience to the user, it is a
novel, simple and cost free solution which is considered preferable to digital
certificates.
16
Darren McCourt
3.5 Dealing With Non SIM Clients
One other rather important decision that had to be made was how to deal with
non SIM clients. What happens when Alice tries to have a secure
conversation with Bob if Bob doesn’t have SIM installed? There is no way of
telling this without prior knowledge or by attempting to communicate with the
other client.
A simple solution to this is to make the secure conversation initiation message
as human readable and meaningful as possible. All SIM protocol messages
will begin with the string “~`SIM`~” to identify them as SIM messages.
Following this is the type of message and finally some payload. The first string
of characters and the type of message are quite short and so can be
considered a necessary cost. The payload of the message can be anything,
“Someone is trying to have a secure conversation with you using Secure
Instant Messaging. Visit http://www.sim.net for more information” for example.
If this message is received by a client running SIM the message will be
processed and the user will never see this. If however the user is not running
SIM the entire message will be displayed and with the exception of the first
10-20 characters the message will be meaningful to the user and he can then
do something. Hopefully this will be to get hold of SIM and go on have the
requested secure conversation.
3.6 Object Oriented C
One final thing worth mentioning here is the intended style of code which will
be used to implement SIM, Object Oriented C.
C is the language that will be used to implement SIM. The main reason for
this is that this is the native language of Gaim and NSS. C is not an object
oriented language but many object oriented principles can be implemented in
C with a little thought and creativity. In fact, the first C++ compilers converted
the C++ code into C and compiled the C.
An object can be represented as a structure. The methods of the object are
written as regular methods which take as a parameter the structure
representing the object. In Java one would write object.method () to call the
method function on the instance object of the object. In object oriented c this
can be written as method (object). This is the main object oriented feature that
SIM will take advantage of. Visibility can also be casually implemented by
placing those methods that one wishes to be public in the header file and
keeping those that are to remain private in the source file.
With these design considerations in mind the next chapter will analyse the
implementation of SIM.
17
Darren McCourt
4 Implementation
This chapter will look at the implementation of Secure Instant Messaging. It
will not attempt to cover every detail of the implementation or even every
module of the application; it will focus on those aspects which are considered
to be interesting or technically challenging.
As SIM currently stands the user is not given a choice over which algorithms
are used to secure the communication and there is no negotiation between
the two clients in a conversation to choose an algorithm. To speed up the
implementation process, standard algorithms were chosen and used so that a
working application could be built as quickly as possible.
4.1 Sending and Receiving Messages
To understand how SIM works it is necessary to understand how the program
uses Gaim to send and receive messages and intercept messages to encrypt
and decrypt them, sign and verify them.
When a user initiates a secure conversation messages are sent between the
two clients to exchange public keys, mutually authenticate the two users and
to exchange a symmetric key to use for the encryption of the user messages
which will follow. The majority of these messages are in no way human
readable, they are a base 64 encoding of binary data, and it is unnecessary
and off-putting for the user to see them. The function Gaim provides and
recommends
for
sending
messages
(gaim_conv_im_send
/
purple_conv_im_send) shows all the messages sent in the user’s
conversation window which is not desirable. To overcome this problem SIM
resorts to using a lower level method call which unlike the previous method
which sends the message to the conversation, sends the message directly to
the server. Because the message is being sent directly to the server rather
than the conversation it is not displayed to the user and is not intercepted and
subsequently altered by any other Gaim plug-ins watching for messages
being sent.
Messages are received by SIM by attaching a callback function to a Gaim
signal. A signal is emitted by Gaim when a message is sent to a conversation
(sending-im-msg) and when a message is being received (receiving-im-msg).
Signals can have callback functions attached to them which are then called
when the signal is emitted. The receiving-im-msg signal is emitted before the
message is displayed in the conversation and if a callback attached to it
returns TRUE the message is cancelled and not displayed to the user. This
means that when receiving messages the callback function attached to
receiving-im-msg can process the message and return TRUE so that the user
never sees the message.
It is also through these signals and callbacks that SIM intercepts the user’s
messages, encrypts and decrypts them, signs and verifies them. The callback
functions attached to these signals take as a parameter a pointer to the
18
Darren McCourt
message being sent or received. This allows the functions to modify the
message before it is sent or displayed.
When a message is being sent by a user and has been intercepted by the
SIM callback function SIM first checks to see if a secure conversation has
been initialised and set up. If a secure conversation exists the function
encrypts the message using the previously agreed symmetric key and signs it
using the sender’s private key. SIM finally adds the SIM indentifier (“~`SIM`~”)
and message type to the start of the message so that it can be identified by
SIM at the other end.
When a message is received by Gaim and the SIM callback function is called
SIM looks at the message to see if it is intended for it, i.e. it starts with
“~`SIM`~”. If it is it is then able to verify the signature of the message using
the sender’s public key and decrypt the message using the previously agreed
symmetric key. When the function returns FALSE the modified message is
displayed to the user in the conversation window as if nothing had happened.
4.2 Initiating a Secure Conversation
Now that it is understood how messages are sent and received by SIM it is
possible to explain how a secure conversation is initiated and set up. In the
following walkthrough the messages which are sent are highlighted in shaded
boxes. Alice and Bob will again be used to attempt to make the explanation
easier to understand.
Alice
Bob
1. ~`SIM`~:WAKEUP:
The wakeup message is perhaps the most unusual and unexpected
message in the entire initiation handshake. Ideally it would not exist at
all but for everything to work well it was necessary.
The easiest way for SIM to reply to a message is by knowing the
conversation that the message is intended for. By knowing this it is
possible to get a server connection and so send the message. As SIM
messages are intercepted and processed by SIM before they are
displayed in a conversation, Gaim doesn’t create the conversation until
it is needed. Therefore at the point that the messages are being
processed the conversation does not exist and it is more a more
difficult task to reply to the message. Nothing is done with the wakeup
message, it is simply allowed to be displayed by the receiving client
(Bob) and by doing so a conversation is created if necessary. Now that
a conversation exists any subsequent messages can easily be replied
to the recipient (Bob).
19
Darren McCourt
2. ~`SIM`~:INIT:Someone is trying to have a secure conversation with
you using Secure Instant Messaging (SIM). Visit http://www.sim.net for
more information.
The initiation message is the first real message in the handshake. It is
used to indicate to the recipient (Bob) that the sender (Alice) would like
to start a secure conversation. As discussed in section 3.5 the majority
of this message human readable plain text that will make sense if
received and displayed by a non SIM client.
3. ~`SIM`~:ACK:
This acknowledgement message is used to let the initiator of the
conversation (Alice) know that the other party (Bob) is capable of
having SIM secured conversations and that she can go ahead with the
rest of the handshake.
As it currently stands if the initiator (Alice) does not receive this
message nothing happens. She does not try to send the message
again as this could have the effect of harassing someone who does not
have SIM. She also does not give up and time out which would be the
best course of action. This is something that should be added to any
future versions of SIM there may or may not be. With limited use this
has negligible impact on the system as the additional structures used
for a secure conversation are small and contain mainly pointers and so
little additional memory is used. However if Gaim was running for a
long period where many secure conversations were created and never
ended, as would happen if no reply was received, a lot of valuable
memory could be wasted on something that is never used.
4. ~`SIM`~:KEY:PUBLIC KEY,PUBLIC KEY HASH VALUE
Once it is known that both parties are able to have a SIM secured
conversation they are now in a position to exchange public keys.
Having received the acknowledgement message the initiator of the
conversation (Alice) sends her public key first. The public key is sent
with a hash value appended to it. This serves no security function as
an attacker could easily replace the message with a different public key
and a correct hash value. Its purpose is to make it easy to detect any
corruption to the message as it was sent across the network. If the
hash value received does not match the hash value of the public key
computed at the receiving end something has changed in transit and
the key can not be trusted.
If the public key successfully passes this challenge it is compared
against the public key stored for the sender (Alice), if any. If the key
received and the stored key match this step is over, if there is no key
stored or the keys do not match, the hash value of the key received is
presented to the user in an easily readable hexadecimal format. It is
20
Darren McCourt
now up to the user to verify the authenticity of the message as
previously mentioned in section 3.4.
If SIM detects any errors during the handshake, if the user does not
accept the key received or if something goes wrong it sends the end
message to the other party and kills the secure conversation. The end
message can be appended with a message with the reason for the
termination which can then be displayed to the other party upon
receipt. SIM doesn’t currently take advantage of this.
5. ~`SIM`~:KEY:PUBLIC KEY HERE,PUBLIC KEY HASH VALUE
In order to reduce the number of messages used in the handshake a
separate acknowledgment message is not sent to confirm the
acceptance of the previously received public key. Instead the other
party (Bob) now sends his public key in the same format and with the
same processing as for step 4. As with step 2 no attempt is currently
made by SIM to recover from a situation where this message is not
received.
6. ~`SIM`~:SYMKEY:SIGNATURE,SYMETRIC KEY
Once again the public key is not acknowledged by a separate
message. If SIM receives a public key which is accepted and has
already sent its public key it acknowledges the acceptance of the public
key it received by generating and sending a symmetric key.
This method of key exchange is known as an RSA key exchange or
PKI (Public Key Infrastructure) exchange. One party (Alice) generates
the symmetric key and encrypts it using the recipient’s (Bob’s) public
key. By doing this only the recipient (Bob) can decrypt the symmetric
key and so only the sender (Alice) and the recipient (Bob) will have
access to it.
As both parties (Alice and Bob) are now in possession of each others
authenticated public keys they are in a position to start signing
messages. This provides non-repudiation and also assures the
recipient (Bob) that the message came from who he thinks it did
(Alice). By signing the symmetric key the recipient (Bob) can be sure
that the key came from the true sender (Alice) and as the sender
(Alice) is the only other person with access to the symmetric key any
messages that the recipient (Bob) encrypts using the symmetric key
will only be readable by the sender (Alice).
7. ~`SIM`~:SYMKEY OK:
If the recipient of the symmetric key (Bob) receives it and verifies the
signature with no problems they reply with this message indicating that
the symmetric key has been successful received.
21
Darren McCourt
Now that both parties are in possession of a common symmetric key
they are able to encrypt, transmit and decrypt secure and authenticated
messages.
8. ~`SIM`~:END:
The end message is used to terminate the secure conversation at any
point. On receipt of the end message the SIM client destroys the
symmetric key if it has been created and exchanged and frees up any
memory used by the secure conversation structures.
As with the other protocol messages used it is possible to include some
payload with the end message. Although it is mainly currently unused
the most appropriate use for this would be an explanation as to why the
conversation has been terminated that could be displayed to the
user(s).
4.3 The Hash Function
It was not until the implementation had started that it became clear how
important the hash function was to the entire security of the application. It is
used not only directly when comparing the values of two keys as discussed in
section 3.4, it is also used for error checking and most importantly in digital
signatures.
In its simplest form a digital signature is the hash value of a message
encrypted with the senders private key, appended to the message itself. If in
transit the message is altered, when the recipient decrypts the appended
hash value and compares it to the hash value of the message received the
two values will be different and the recipient will know the message has been
altered. If the recipient is unable to decrypt the signature using the expected
sender’s public key they will know that they cannot trust the message.
Due to the lack of understanding of the importance of the hash function it
wasn’t given much consideration until the implementation stage. Had its
importance been understood earlier it would have been more carefully
considered and the choice of hashing algorithm is probably another one that
should be given to the user due to its importance. The structure of the
implemented code should mean that the work required to do this is a minimal
addition to choosing and negotiating the encryption algorithm.
The hashing algorithm eventually chosen for use in the initial version of SIM
was SHA-1 as it offers the right balance between security and performance.
During the implementation and testing of the hashing function a problem was
discovered when hashing base 64 encoded data. For an unknown reason the
same hash value was given for vastly different input data. The reason behind
this problem is still unknown. The temporary solution adopted was to first
decode the data and hash the resulting data. This appears to work well,
different data produces different hash values, even when only one bit is
changed, and the same data consistently produces the same value. The
22
Darren McCourt
solution isn’t ideal as technically there should be no problem hashing the base
64 encoded data. It is quite possible that the problem is as simple as failing to
flush a buffer, but why this only happens with the base 64 data remains a
mystery.
4.4 Encrypting and Decrypting
As previously mentioned one encryption algorithm was chosen and used in
order to build a working solution as quick as possible. The user was given no
choice over the algorithm and no negotiation of the algorithm between clients
was made.
The algorithm first chosen was AES because of its security and performance
and the fact that it is well known and generally accepted to be secure. This
seemed to work fine initially; no errors were discovered when encrypting or
decrypting with short input. However when the input was made longer errors
started to appear in the decrypted text. When encrypting and subsequently
decrypting text strings the 13th character in the resulting string was incorrect, it
was an apparently random character. After spending a lot of time trying to
track down the error, writing the code again in different ways it seemed that
the problem was not with the code SIM implemented or the way the NSS
libraries were being used, but the libraries themselves. After trying several
other algorithms no problems were discovered and it would appear that the
AES implementation may be faulty. This does raise issues with the security
and implementation of NSS as a whole but its use in high profile applications
by people with more knowledge and expertise suggest that this is potentially
another unknown problem the implementation of SIM. The algorithm chosen
to replace AES was triple DES.
Other symmetric algorithms supported by NSS include [6]:
• AES
• DES
• Triple DES
• CDMF
• RC2
• RC5
• IDEA
• CAST
• CAST3
• CAST5
• CAMELLIA
These algorithms are specifically mentioned as they can all be used in CipherBlock Chaining (CBC) mode and the library itself takes care of padding. There
are further algorithms supported by NSS which do not support these features
and so have not been chosen.
Any of these algorithms can theoretically be used in SIM simply by changing
one parameter to the encrypt / decrypt functions. In order to give the user a
23
Darren McCourt
choice over algorithms further work is required to the configuration GUI and
the conversation initialisation in order for the two clients to negotiate which
algorithm is to be used.
Out of the 11 encryption algorithms above, DES, Triple DES, CDMF, RC2 and
CAST worked with no problems, AES threw no fatal errors but had problems
as previously mentioned, CAMELLIA could not be found in the library and the
remainder caused the program to crash.
As demonstrated by the list above there is a large choice of symmetric
encryption algorithms that can be used and it will require knowledge to
choose the best one for a given situation as many of these are relatively
unknown to the average user.
24
Darren McCourt
5 Results
This chapter will illustrate how SIM works in practice and how it is intended to
be used. As a lot of the theoretical workings have already been analysed in
previous chapters and so here the concrete solution will be demonstrated
showing both what the user sees on the surface and what is happening in the
background.
To aid in this packet sniffing will be used to grab messages as they are sent
across the network after leaving the application. These packets represent
what will be seen by anyone watching the network at any stage between the
two users. The software used to capture these packets was Ethereal [7]. One
benefit of using Ethereal is that it understands the details of many network
protocols including the MSN Messenger Service protocol and so is able to
display the information in a easy to understand, user friendly way.
As well as showing the solution here, aspects of the situation before using
SIM will also be shown here to allow a direct comparison to be made and to
better understand what SIM actually does.
25
Darren McCourt
Figure 3: An unsecured conversation
The images above show what two users in an unsecured conversation see.
On the left sim1 is talking to sim2, and on the right sim2 is talking to sim1. No
configuration or any additional work is required for the two parties to
communicate.
The images below show what two users in a SIM secured conversation see.
On the left sim1 is talking to sim2, and on the right sim2 is talking to sim1.
However in this situation additional work had to happen before the
conversation began. In the chat window that the user sees this is barely
noticeable but in the background much more is going on. Sim1, who initiated
the conversation, simply sees a message informing him that SIM is attempting
to secure the conversation and a confirmation message when this is
complete. Sim2 sees the same messages as sim1 with the addition of the
previously discussed wakeup message used to open the conversation for
sim2. After this the conversation progresses as usual and no other change is
noticeable to the users.
Figure 4: A SIM secured conversation
26
Darren McCourt
Before a user can use SIM for secure conversations SIM first needs to be
configured, the configuration GUI is accessed via Gaim’s plug-in window. The
configuration GUI is split into 4 tabs. The ‘Security’ tab and the ‘Other’ tab
currently have no function
and were to be used in
allowing the user to select
the security mechanisms
used. The only tab the user
needs to visit to configure
SIM and start using it is the
‘My Keys’ tab. From this tab
the user can generate an
RSA key pair to be used in
securing and authenticating
conversations. It is also on
this tab that the user can
view the hash value of their
own public key for use when
proving the authenticity of it
Figure 5: Implemented Configuration GUI
with another user via a
second channel. Once the keys have been generated and stored in the users
file system this dialogue can be closed and almost forgotten. The locations of
the users’ keys are stored in the XML preferences file which is saved when
SIM is unloaded and read again when SIM is loaded.
Starting a secure conversation is marginally more complicated for the user
than starting a regular unsecured conversation which is a simple case of
double clicking on a buddy in Gaim’s buddy list. To start a SIM secured
conversation the user has to select the option from a menu. This presents the
user with a dialogue box in
which he can input the screen
name or alias of a contact,
selecting from a list of
matches. Upon clicking OK
the
usual
conversation
window is opened and SIM
begins the handshake with the
selected contact.
The reason for this slightly
unorthodox
method
of
beginning
a
conversation
stems from one of the few
limitations of the Gaim plug-in
framework. No support is
provided for modifying the standard Gaim GUI with the exception of adding
menu items to the tools menu. Although it would be possible to modify the
Figure 6: Starting a SIM Secured Conversation
27
Darren McCourt
Gaim code this is not practical as it would require Gaim to be changed each
time an updated version was released.
In the background of the secure conversation all the messages discussed in
section 4.2 are transmitted, none of these messages need to be sent for an
unsecured conversation.
The following images are extracts from Ethereal screenshots showing the
contents of the MSN Messenger Service part of the packets sent.
Figure 7: Ethereal, wakeup mesage
This is the first message sent in initiating a secure conversation, the wakeup
message. As can bee seen from the MSN Messenger Service section of the
data the SIM message forms the payload of the MSN Messenger Service
MSG message. The three sections of the SIM message are separated by
colons and in this case the final section has no contents. This is the only
handshake message that is visible to users of SIM, specifically in this
example, sim2.
Figure 8: Ethereal, initiation message
The initiation message is contained here in the middle of two MSN Messenger
Service messages which have been sent in the same packet. The message is
mostly human readable plain text.
The screenshot below from the official MSN Messenger Service client shows
what happens when a SIM user attempts to initiate a secure conversation with
a non SIM client. The wakeup and init messages are displayed to the user in
their full form as there is no SIM software to intercept them. Although at first
glance it may be confusing to the user it is easy to notice the readable text of
the initiation message and make sense of what is happening.
28
Darren McCourt
Figure 9: Behaviour with a non SIM client
Figure 10: Ethereal, acknowledgement message
The previous two messages were sent from the initiating client to the
recipient. This is the first message that the recipients client sends. In this
scenario both clients were running on the same machine and so in the
Internet Protocol section the source and destination IP addresses are
identical. However if we look at the Transmission Control Protocol section we
can see that the source ports of the messages are different. This is how the
MSN Messenger Service identifies different conversations, not through a
destination user ID embedded in the message but the connection on which
the message is sent. Although as far as the MSN Messenger Service servers
are concerned this is one conversation, on the local machine there are two
conversations, one for each client.
Figure 11: Ethereal, public key message 1
29
Darren McCourt
The public key transmission messages above and below show the base 64
encoded public keys and the base 64 encoded hash value separate by a
comma.
Figure 12: Ehtereal, public key message 2
If either party does not posses the
public key for the other party, or if
the key has changed, a message
similar to the one on the right is
shown. This presents the hash
value of the key received in an
easy to read form that the user can Figure 13: User authentication of a public
then use to authenticate the new key
key. If the user says no the conversation is ended. If the user says yes the
key is accepted and added to the list of secure contacts.
Figure 14: Ethereal, symmetric key message
After the successful exchange of public keys the initiating client generates a
symmetric key, encrypts it with the recipient’s public key and signs the
message. In the SIM message above, the base 64 data before the comma is
the message signature, and the data after it is the encrypted symmetric key.
Figure 15: Ethereal, symmetric key ok message
Upon successful extraction and verification of the symmetric key it is
acknowledged by the receiving client.
30
Darren McCourt
A total of seven additional messages were required to initiate the secure
conversation. In practice when using SIM this process happens almost
instantly within a second or two. The additional cost of this handshake is
negligible.
From this point forward the user interaction with SIM is non existent. The
users continue to have a conversation using Gaim in the same way they
would if SIM wasn’t installed and running. In the background however SIM is
processing the messages. The following images show the network messages
sent and received by sim1 in the above unsecured and secured
conversations. The messages sent by the user in both conversations are
identical but in the background they are vastly different.
Figure 16: Ethereal, Conversation message 1
In the first message sent sim1 sends the message “hello” to sim2, in both
conversations all the users see is the message “hello”. In the unsecured
conversation above the message “hello” is sent across the internet in plain
text for anyone to see. However below in the secured conversation the
message sent across the internet is radically different.
The first thing to notice is that the message is now no longer human readable
plain text. The message is base 64 encoded binary data.
The message is also much longer. This clearly means that there is an
overhead in the size of every message when using SIM to secure
conversations. If we look at the message in more detail with an understanding
of what it means this overhead soon seems much more manageable.
The first section of the payload of the message, the section after the second
colon before the first comma, is the message signature. The length of this
section is going to remain consistent no matter what the message is as it is
simply an encryption of a hash value, which itself is a constant length.
31
Darren McCourt
The second section of the payload, between the second and third commas, is
the initialisation vector (IV). This is a randomly generated variable used to
make breaking the encryption harder as it increases the size of the field to be
searched and ensures that the output of the encryption function is different for
the same input data. This means statistical analysis and pattern recognition
on the encrypted data is much harder.
The third and final section is the encrypted message itself. Although longer
than the unencrypted message the difference is only small. This section is
also the only section whose length will vary depending on the length of the
input.
The remainder of the messages in the conversation follow the same format.
The unsecured and secured messages can be compared in the following
images.
32
Darren McCourt
When the conversation is over or either user closes the conversation window
the secure conversation is over and the client sends the end message to the
other user killing the secure conversation.
Figure 20: Ethereal, end message
The other user is notified that the conversation they have open is no longer
secure.
Figure 21: Gaim conversation, end message
33
Darren McCourt
6 Testing
The testing of every system is a major aspect of its development especially in
a system where the cost of failure is potentially so high. A breach in the
security of SIM could result in users’ private data being leaked to attackers.
Depending on the user this may mean effectively nothing but it could mean a
lot. Because of this high cost of failure testing this system is very important.
The testing that has been carried out on SIM focuses on the functionality
implemented by SIM itself and not on any libraries it uses. It has been
assumed that these libraries have already undergone their own thorough
testing before being released. Without fully testing of every library used it is
impossible to give a guarantee that everything works as it should but as far as
it is known this is the case.
As the majority of the security features have been implemented with the help
of the NSS libraries a lot rides on the strength of these. Due to the fact that
the NSS libraries are used in applications where the security is possibly more
important that it is in SIM, and that NSS has been chosen and developed to
meet these needs the NSS libraries are assumed to be secure. Of course
testing of how these libraries have been used has been carried out.
This chapter will not analyse every single test that was carried out during and
after the implementation of Secure Instant Messaging but will focus on the
testing of important aspects of the system or areas where tests failed.
6.1 The GUI
The GUI was the first section to be implemented and as such was the first
section to be tested. The only way to test a GUI is to use it, it isn’t
mathematical or scientific, there isn’t a given result for a given set of input
data, indeed there is no input data. There is a set of preconditions a set of
actions and a set of post conditions.
Preconditions: The GUI is loaded and displayed to the user.
Actions: Button X is pressed.
Post conditions: The callback function attached to button X has been
executed.
Initially the entire testing of the GUI followed this pattern. The callback
functions were merely stubs and had no function other than displaying a
message indicating that the button had been pressed. When functionality was
added to these callbacks the number of preconditions and post conditions
increased to ensure the correct behaviour was consistently observed.
Overall the GUI functions and works very well. It is simply presented but at the
same time gives the user a lot of control over the configuration of SIM without
34
Darren McCourt
overwhelming them. One possible improvement would be the ordering of the
tabs. E.g. the ‘Contacts’ tab is the first one displayed as it was originally
believed that this would be the most used tab. However when the user first
uses SIM they need to first go to the ‘My Keys’ tab first. It would be a nice
feature if this tab was dynamically positioned depending on the configuration
status of SIM, i.e. if SIM hadn’t yet been configured this tab would be
displayed first. As it turns out it is the ‘My Keys’ tab that is most frequently
used mainly to access the hash value of the users public key. It would be a
better idea to allow this functionality to be access directly from the Gaim Tools
menu as is the case when starting a new secure conversation.
6.2 The Hash Function
The hash function is one of the most important aspects of the security of the
system, it forms the basis of the digital signatures used to authenticate
individual messages and provided non-repudiation. Because of this a lot of
attention was paid to testing the hash function.
The hash function was tested with multiple different, similar and the same
pieces of data. Two identical pieces of data should always produce the same
hash value. A slight change in even one bit of the input data should produce a
different hash value. No matter what the input length of the data, the output
should always be of a constant length.
The length condition is the simplest to test. The hash function was presented
with strings of different lengths. Single words, phrases and whole articles
randomly selected from Google News [8]. As expected the hash value was
consistently the same length.
The same input should always produce the same output. Presenting the hash
function with the same data stored in different locations should result in the
same hash value as the data is exactly the same. The same data stored in the
same location should produce the same hash value no matter how many
times it is done. Both of these statements proved to be true. The same also
holds across different instances of SIM.
When even one bit of the input data is changed the hash value should be
different. As all of the previous tests were done using strings this test was also
carried out with strings. Instead of a single bit being changed, a single
character was changed. However using ASCII characters it is possible to
change a single bit by changing a single character. For example the ASCII
representation of B is 100 0010, and C is 100 0011 [9]. By changing a B to a C
only a single bit changes. By making changes like this it is possible to test the
hash function at the bit level. As expected the hash value produced was
different when these single bit changes were made.
One error found when testing the hash function during implementation was
when attempting to directly encode base 64 encoded data. For some reason
which still remains unknown vastly different input data would produce exactly
the same hash value time after time, even across different instances of the
35
Darren McCourt
application. The temporary workaround which satisfies all the above tests was
to firstly decode the base 64 data and apply the hash function to the
uuencoded data. Although this is not an ideal situation it is a practical solution
which works.
6.3 Symmetric Encryption
An error was discovered when testing AES symmetric encryption and as a
result of this SIM now uses triple DES for symmetric encryption.
When encrypting and subsequently decrypting data with the same symmetric
key using AES a problem was found with the 13th character of the output, it
made no sense at all and appeared to be random. It wasn’t an additional
character; it replaced one of the characters of the original input.
The problem was investigated and it didn’t seem that there was any problem
with the implementation of SIM and the problem seemed to be with the NSS
libraries although this has not been confirmed. Symmetric encryption written
in exactly the same way but using a different algorithm worked with no
problems. Triple DES was chosen as the next best thing to AES and used as
its replacement in this application.
6.4 Sending and Receiving Messages
The success or failure of sending a message is dependant upon the reliability
of the MSN Messenger Service. As there is no way to externally influence this
there is little benefit in testing the reliability of messages being sent and
received. It is however possible to test that messages sent from SIM are
encrypted and signed.
Packet sniffing was used to analyse messages being sent from SIM. The
packet sniffing software shows the messages after they have left the
application and in the format that they travel across the network in. It is these
messages that attackers and eavesdroppers will see.
As illustrated by the images in Chapter 5 the messages that SIM sends are in
no way human readable plain text. The messages are encrypted and signed
as discussed in chapter 5. The security of the encrypted data and signatures
has been tested and is discussed earlier in this chapter.
The ability of SIM to recover from failed messages undelivered by the MSN
Messenger Service has not been tested as there is no attempt currently made
to do this in the code. This was discussed in the Implementation chapter.
36
Darren McCourt
7 Evaluation and Conclusion
How successful is Secure Instant Messaging?
Overall the application produced, Secure Instant Messaging (SIM) is a
success. It meets the requirements of the initial project proposal. Secure
Instant Messaging allows secure and authenticated communications over the
MSN Messenger network. It provides the user with Message Confidentiality,
Authentication and Non-repudiation. It does not however provide perfect
forward secrecy. Perfect forward secrecy does provide an additional layer of
security which would be nice to have, but merely provides a fail safe should
any of the other layers of security fail.
SIM falls short on achieving the other goals it set out to do, namely giving the
user the choice over how their communications are secured. The main body
of the work required to do this is in place. The encryption and decryption
functions can take as a parameter the encryption algorithm to use, there are
at least five other algorithms that currently work with no problems. The GUI
has the components required to allow the user to make this selection, they
simply need populated. The main work required is to develop a protocol to
allow two clients to negotiate the algorithms to be used.
Another area that doesn’t require a huge amount of work to complete would
be to provide perfect forward secrecy. This would be achieved by
implementing a Diffe-Helleman key exchange. This is slightly more
complicated than the currently used symmetric key exchange method as it
requires the two clients to cooperate to independently produce the same
symmetric key.
The list of possible extensions to what has been proposed and achieved by
this project is almost endless. Secure file transfers, support for group
conversations, secure video calls, improved reliability and increased flexibility
are but a few. This project provides a solid foundation for these extensions to
allow improved secure communications over existing instant messaging
networks. For the ultimate security a network designed to be secure from the
ground up would be required. For some applications this may be necessary
but for most people, and the target audience for SIM this is probably an
unnecessary inconvenience. Unified Communications is the future and giving
users yet another point of contact is a step in the wrong direction.
37
Darren McCourt
8 References
1. http://imagine-msn.com/messenger/launch/en-GB/. “Windows Live
Messenger – The Next Generation of Messenger”. 01 May 2007.
2. http://www.secway.fr/us/products/simplite_msn/home.php. “MSN
Messenger encryption and security software – Encrypt and secure your
MSN Messenger IM conversations or chats”. 01 May 2007.
3. http://www.cypherpunks.ca/otr/. “Off-the-Record Messaging”. 01 May
2007.
4. http://www.cypherpunks.ca/otr/. “News – Pidgin”. 01 May 2007
Egan, Sean. “Open Source Messaging Application Development:
Building and Extending Gaim”. ISBN 1590594673. Apress, June 16,
2006.
5. http://www.mozilla.org/projects/security/pki/nss/. “Network Security
Services (NSS)”. 01 May 2007.
Stallings, William. “Cryptography and Network Security”. ISBN
0131873164. Prentice Hall, 16 Nov 2005.
6. http://lxr.mozilla.org/mozilla/source/security/nss/lib/softoken/pkcs11t.h#
906. “LXR Roots – mozilla Cross Reference”. 01 May 2007.
7. http://www.ethereal.com/. “Ethereal: A Network Protocol Analyser”. 01
May 2007.
8. http://news.google.co.uk/. “Google News U.K.”. 01 May 2007.
9. http://en.wikipedia.org/wiki/ASCII. “ASCII”. 01 May 2007.
38

Secure MSN Messenger Messenger

Transcription

Similar documents

George Middle School / Homepage

Hotmail/Live/ MSN/Outlook.com

CITY SCHLEPPAGE

M2M Ecosystem Development

fossmo helge

Sony Xperia XA Ultra

Add one sheet

GSM Security Camera - Jablotron Security

HAND CAR WASH

fiddle - Fancy Yourself Fiddling