Computer Science CSC4000W - Shenzi

Transcription

MODUS
Messaging for Office Doors through
Ubiquitous Systems
Computer Science
CSC4000W
Author: Neil Stuppel
Supervisor: Gary Marsden
Co-Supervisor: Donald Cook
6th November 2006
Abstract
Office door messaging is nothing new. A conventional method of communication with an office
occupant when not in their office is the use of post-it notes. These are often exposed to visitors
that randomly pass by the door and are often removed without the visitor or occupant s
knowledge.
This paper aims to research the technology required to implement such an application in a
ubiquitous environment, stepping through the implementation of the application for a secure
multi-functional messaging system.
The MODUS system has been built to provide office occupants a means of communicating with
visitors when not in their office. This implementation exists in a ubiquitous environment that
creates problematic conditions for both usability and security aspects of computing. Where
systems similar to MODUS have focused on usability in these ubiquitous environments, the
MODUS system focuses on security. This will allow for visitors at the office occupants door to
have a sense of security when communicating with the occupant and not having to be concerned
that their confidential messages are being viewed by a 3rd party.
The system has been implemented using both conventional and unconventional security
techniques. The security that has been provided includes: confidentiality, integrity, authentication,
and non-repudiation.
1
Table of Contents
ABSTRACT................................................................................................................................................... 1
TABLE OF CONTENTS ............................................................................................................................. 2
LIST OF ILLUSTRATIONS ....................................................................................................................... 4
1
INTRODUCTION AND MOTIVATION ........................................................................................... 5
2
BACKGROUND CHAPTER............................................................................................................... 6
2.1
RELATED WORK .............................................................................................................................. 6
2.1.1
Summary ................................................................................................................................. 6
2.2
RESEARCH THEORY ......................................................................................................................... 7
2.2.1
PDA Usability ......................................................................................................................... 7
2.2.2
Security Requirements............................................................................................................. 8
2.2.2.1
2.2.2.2
2.2.2.3
2.2.3
3
Summary ................................................................................................................................. 9
DEFINITION AND THEORY .......................................................................................................... 11
3.1
3.2
4
Security in Pervasive / Ubiquitous Environments ..............................................................................8
Wireless 802.11b Security ..................................................................................................................8
Availability.........................................................................................................................................9
PROBLEM DEFINITION.................................................................................................................... 11
RESEARCH QUESTION .................................................................................................................... 11
SPECIFICATION OF SOLUTION .................................................................................................. 12
4.1
SECURITY REQUIREMENTS ............................................................................................................ 12
4.2
FUNCTIONAL REQUIREMENTS ........................................................................................................ 13
4.2.1
Requirements......................................................................................................................... 13
4.2.2
Core Functional Requirements ............................................................................................. 13
4.2.3
Complete Functional Requirements ...................................................................................... 14
4.3
DIVISION OF WORK........................................................................................................................ 14
4.3.1
Non-Security ......................................................................................................................... 14
4.3.2
Security ................................................................................................................................. 14
4.4
METHODOLOGY ............................................................................................................................. 14
4.5
EVALUATION ................................................................................................................................. 15
5
DESIGN ............................................................................................................................................... 16
5.1
MODUS SYSTEM OVERVIEW ........................................................................................................ 16
5.2
CALENDAR CLIENT:....................................................................................................................... 17
5.2.1
Hardware Design Platform................................................................................................... 17
5.2.2
Programming Language ....................................................................................................... 17
5.2.3
Bluetooth Sensor ................................................................................................................... 17
5.3
CALENDAR WEB SERVICE ............................................................................................................. 18
5.4
HARDWARE DESIGN PLATFORM .................................................................................................... 18
5.5
PROGRAMMING LANGUAGE ........................................................................................................... 18
5.6
WEB SERVER ................................................................................................................................. 19
5.7
DATABASE ..................................................................................................................................... 19
5.8
SECURITY ...................................................................................................................................... 19
5.8.1
Confidentiality and Integrity ................................................................................................. 19
5.8.2
Device Authentication ........................................................................................................... 20
5.9
CALENDAR SYNCHRONIZATION ..................................................................................................... 21
5.9.1
Component Object Model ..................................................................................................... 21
5.10 CALENDAR INTERFACE DESIGN ..................................................................................................... 21
2
6
IMPLEMENTATION ........................................................................................................................ 23
6.1
SYSTEM OVERVIEW ....................................................................................................................... 23
6.2
PROGRAMMING LANGUAGE ........................................................................................................... 23
6.3
MODUS CLIENT ........................................................................................................................... 24
6.3.1
Interface ................................................................................................................................ 25
6.3.2
Class Implementation............................................................................................................ 27
6.3.3
6.3.4
Optimizations ........................................................................................................................ 29
6.4
MODUS SERVER........................................................................................................................... 30
6.4.1
Class Implementation............................................................................................................ 31
6.4.2
Database ............................................................................................................................... 32
6.5
MODUS WEB ADMINISTRATION .................................................................................................. 33
6.6
SECURITY ...................................................................................................................................... 34
6.6.1
Encryption............................................................................................................................. 34
6.6.2
Server Authentication............................................................................................................ 35
6.6.3
Device Authentication ........................................................................................................... 35
6.7
CALENDAR SYNCHRONISATION ..................................................................................................... 36
7
TESTING AND RESULTS ................................................................................................................ 38
7.1
FUNCTIONAL TESTING ................................................................................................................... 38
7.1.1
Encryption/Integrity .............................................................................................................. 38
7.1.2
Server Authentication............................................................................................................ 40
7.1.3
Client Authentication ............................................................................................................ 40
7.1.4
7.1.5
GroupWise Synchronizer ...................................................................................................... 41
7.1.6
Client/Service Faults............................................................................................................. 41
7.1.7
Web Administrator ................................................................................................................ 42
7.1.8
Web Service........................................................................................................................... 42
7.2
USER TESTING ............................................................................................................................... 47
7.2.1
MODUS Client...................................................................................................................... 47
7.2.1.1
7.2.1.2
7.2.1.3
7.2.2
Iteration 1 .........................................................................................................................................47
Iteration 2 .........................................................................................................................................49
Conclusion........................................................................................................................................50
Web Administrator ................................................................................................................ 50
8
CONCLUSION ................................................................................................................................... 52
9
FUTURE WORK ................................................................................................................................ 53
9.1
9.2
9.3
9.4
9.5
9.6
HARDWARE ................................................................................................................................... 53
CALENDAR DESIGN ....................................................................................................................... 53
BLUETOOTH SENSOR ..................................................................................................................... 53
GROUPWISE SYNCHRONIZER ......................................................................................................... 53
SECURITY ...................................................................................................................................... 54
COMMUNICATION .......................................................................................................................... 54
10 REFERENCES.................................................................................................................................... 55
3
List of Illustrations
FIGURE 1: MODUS SYSTEM DESIGN ............................................................................................................ 16
FIGURE 2: PAPER PROTOTYPE - INTERFACE DESIGN ...................................................................................... 22
FIGURE 3: SYSTEM OVERVIEW ...................................................................................................................... 23
FIGURE 4: MODUS CLIENT CLASS DIAGRAM ............................................................................................... 24
FIGURE 5: CALENDAR INTERFACE ................................................................................................................. 25
FIGURE 6: OPEN SLOTS INTERFACE ............................................................................................................... 25
FIGURE 7: CREATE APPOINTMENT INTERFACE .............................................................................................. 26
FIGURE 8: KEYPAD ........................................................................................................................................ 26
FIGURE 9: CALENDAR CLASS......................................................................................................................... 27
FIGURE 10: BLUETOOTH SENSOR PROTOCOL ................................................................................................. 28
FIGURE 11: BLUETOOTH REGISTRATION APPLICATION ................................................................................. 28
FIGURE 12: MODUS SERVICE CLASS DIAGRAM ........................................................................................... 30
FIGURE 13: CALENDARSERVICE CLASS ......................................................................................................... 31
FIGURE 14: SOAP RESPONSE ........................................................................................................................ 32
FIGURE 15: CALENDAR DATABASE TABLE .................................................................................................... 33
FIGURE 16: OVERLAPPING TIME SLOTS ......................................................................................................... 34
FIGURE 17: SSL AUTHENTICATION ............................................................................................................... 35
FIGURE 18: DEVICE AUTHENTICATION .......................................................................................................... 36
FIGURE 19: DEVICE AUTHENTICATION DATABASE TABLE ............................................................................ 36
FIGURE 20: GROUPWISE SYNCHRONIZATION ................................................................................................ 37
FIGURE 21: CLEAR TEXT RESPONSE .............................................................................................................. 39
FIGURE 22: ENCRYPTED RESPONSE ............................................................................................................... 39
FIGURE 23: INITIAL LOAD GRAPH ................................................................................................................. 43
FIGURE 24: IMAGE UPDATE LOAD GRAPH ..................................................................................................... 44
FIGURE 25: SINGLE CLIENT APPOINTMENT SCHEDULING LOAD GRAPH ........................................................ 45
FIGURE 26: TWO CLIENTS, APPOINTMENT SCHEDULING LOAD GRAPH ......................................................... 46
FIGURE 27: TWO CLIENTS, MESSAGING AND APPOINTMENT SCHEDULING LOAD GRAPH ............................. 46
FIGURE 28: CALENDAR INTERFACE ............................................................................................................... 48
FIGURE 29: OPEN SLOTS INTERFACE ............................................................................................................. 48
FIGURE 30: BOOK APPOINTMENT INTERFACE ................................................................................................ 49
FIGURE 31: KEYPAD ...................................................................................................................................... 49
4
1 Introduction and Motivation
Jane arrives at her professor s office to make an appointment. He is no where to be found and
Jane sees a PDA attached to his door with a picture of him on it. She sees that he is out for lunch
and notices that she can make an appointment with him or leave a message. Jane decides to make
an appointment and selects one of the free time slots. She books the slot and enters her name with
a message. She then posts the appointment to her professor. Jane then remembers that she needs
to remind her professor to send her the project specification. She decides to leave a message on
the PDA for her professor.
The professor is working on his laptop during lunch and sees that he has two new e-mails. The
first indicating that Jane has made an appointment to see him and the other a message from Jane
saying: Hi please send me the project specification .
The aim of the MODUS project is to provide a multi-functional messaging system that will
allow both lecturer and student to communicate in an environment that is unobtrusive, controlled
and confidential. The MODUS project realises that currently there is no efficient means of
communication between student and lecturer and intends to fix this communication gap. While
speaking is an efficient means used to communicate, students are often intimidated by staff
members to ask questions directly, it is not always possible to communicate directly if the owner
is out of their office. With the advent of the Internet and E-mail, communication between people
on different continents can take seconds. This provides the basis for the solution as digital
information can be transmitted quickly and efficiently between electronic devices.
Lecturers are not always in their offices and students are not always able to send e-mail. With
the advancement in mobile technology and an increase in computing power, mobile devices are
now capable of performing complex business tasks including operations across networks
allowing for communication with various electronic devices.
PDAs provide easy input mechanisms like touch screens, to keep the device compact.
Traditionally, lecturers allowed students to write messages on post-it notes or on white-boards.
While this provided a solution it was not always effective as students are able to remove the
notes and potentially alter them. This solution does not provide the 2-way communication
required for prompt and reliable interaction with staff members. While students are able to
communicate with the lecturers, the lecturers are not able to communicate with the students.
The use of mobile technology to enhance education and create an environment to help everyday
tasks is nothing new. The MODUS system provides a fully functional messaging system that
allows for convenient messaging, appointment scheduling and a mechanism for lecturers and
students to keep in contact. It establishes a secure ubiquitous environment allowing for
confidential and reliable messaging.
5
2 Background Chapter
This section deals with the previous work that has been done by other people that is beneficial in
creating the MODUS system.
2.1 Related Work
Chevest et al at the University of Lancaster developed the HERMES system [1]. The HERMES
system is made up of multiple PDAs on various office doors to provide messaging functionality
to the owner and visitors to the office.
Owners are able to display messages to passing visitors
Visitors are able to leave messages for the occupant
The setup of this system in a ubiquitous environment is intended to remove the need for
conventional post-it notes.
HERMES research has brought into context the difficulty in maintaining a secure system,
which is important in an open environment, over the usability requirements that are also
required to ensure that people will make use of the system.
In a particular scenario, occupants are able to create temporary messages on the PDA. Initially,
the attempt was made to prevent any user from setting a temporary message and required the
owner to authenticate themselves each time to access the area of the HERMES system to
change the message. The office occupant found this to be cumbersome and often decided not to
change a temporary message. The approach was revised and a compromise was made to require
the occupant to tap on the PDA screen twice to initiate the component to set a temporary
message . This however leaves the system at risk, and users can maliciously change the
temporary message without the occupant s knowledge.
The research indicates that both occupant and visitors to the office door refrained from using
the HERMES system as they did not believe it would work, where messages would not reach
their destination. This indicates a need for a security aspect where one can ensure availability
and ensure all messages reach their destination in a timely method.
The HERMES research provides valuable information on the usability issues that were found
when placing the system in a real environment.
2.1.1
Summary
The HERMES system has provided the grounding to create a messaging system in a ubiquitous
environment. They aimed to create a system that was usable and aimed to produce a system
with limited button pressing and therefore making the messaging process quick and efficient.
The MODUS developers, while focusing on creating a usable system, acknowledge the
requirement for a security platform embedded into a messaging system in a ubiquitous
environment. The use of security often involves increasing the number of button presses
involved to perform an action.
Fortunately HERMES has provided a system that has been tested for many months in a real
6
world environment and has provided valuable information with regards to:
Usability
The approach taken by HERMES has been to minimize the number of taps required to
complete an operation. Users are not often familiar with new technology and therefore
do not want to spend much of their time performing trivial tasks.
Required functionality
HERMES implemented a strict messaging system as its core functionality. The MODUS
system will, however, include a Calendar component where students can schedule
appointments with the lecturers.
Communication issues
HERMES based their communication on Wireless and realised that weak signals were
due to interference in the building. This, however, was due to the placement of their
wireless routers. They positioned their devices at positions at a distance from the
wireless access points.
2.2 Research Theory
Creating usable and secure environments often conflict and security can often degrade the
usability of an application. Much research has been done on both usability and security in
ubiquitous systems.
2.2.1
PDA Usability
In the book Designing the User Interface, Ben Schneiderman identified 8 principles that
should be adhered to when designing interfaces for desktop applications. [15]
[2] Discusses the limitations of mobile device interfaces using the 8 principles as specified by
Ben Shneiderman and moves to adapt these principles for the development of mobile devices.
It suggests that four of the original guidelines can be directly used when developing interfaces
for mobile devices
Enable frequent users use of shortcuts
Offer informative feedback
Design dialogs to yield closure
Support internal locus of control
The remaining 4 guidelines require modification to adapt to mobile devices due to resource
limitations including memory space, limited screen size and slow response times.
The paper moves on to propose new guidelines to developing interfaces for mobile devices
Design for multiple and dynamic contexts
Design for small devices
Design for limited and split attention
Design for speed and recovery
Design for top-down interaction
7
Allow for personalization
Design for enjoyment
2.2.2
Security Requirements
2.2.2.1
Security in Pervasive / Ubiquitous Environments
[3] Provides the current trends in securing applications in pervasive computing environments.
The trends are separated into core security sections that when combined produce an all round
secure environment.
Authentication and Authorization
Access Control
Service Discovery
Trust
[5] Investigates the possible threats that can occur in pervasive computing environments. It
establishes the current methods of providing security to conventional computing environments:
Symmetric encryption
Asymmetric Encryption
X509 Certificates
Specific aspects of security in pervasive computing are analyzed and solutions are provided to
create a secure environment. Both physical and network security is required to ensure a secure
environment. Current solutions to physical security ensure a user is authenticated to perform
authorization. Network security is performed at various levels of the Network Stack. Possible
solutions include SSL/TSL, IPSec, SSH.
2.2.2.2
Wireless 802.11b Security
Wireless networks based on the IEEE 802.11b standard are growing ever more popular.
Ubiquitous systems are integrated into ones surroundings. In order for these systems to
communicate they require a wireless connection. These devices can often transmit sensitive
data and there is a requirement for a specific level of security.
Much research has been done on the security flaws of the 802.11b standard and investigating
ways to secure wireless connections.
The 802.11x standard provides two methods of security [6]:
MAC filters used for access control
Wired Equivalent Privacy (WEP) used for encryption
MAC address filtering is used for access control. Each device contains a MAC address which is
used to identify each device. This method of access control is flawed as each MAC address of a
Wireless 802.11b network adapter can be easily changed.
WEP is used to encrypt all data being transmitted between wireless devices and to ensure
integrity of all data. It is based on the RC4 algorithm and uses CRC-32 to compute an Integrity
Check Value over all the data being transmitted. WEP however can be easily cracked and
8
therefore not strong enough to ensure all data is kept confidential.
[7] Outlines alternative security mechanisms that can be used to secure the communication
between the communicating devices. Including:
SSL
o
VPN
o
2.2.2.3
Provides security at the transport layer and ensures that all communication is
confidential and maintains integrity. It is also capable to authenticating both
client and server.
This creates a private secure connection over public networks. All
communication is secure and provides ways to authenticate users. It is also
responsible for ensuring integrity of all data being transmitted
Availability
Mobile devices do not have the computing resources Personal Computers have. However,
mobile devices are increasingly performing complex business and personal tasks that require
more resources that can slow down the device considerably and lessen its energy life span.
[8][9] investigates the energy consumption of PDAs when implementing security protocols and
cryptographic functions. The approach taken by the researchers is to apply various
cryptographic functions and security protocols using PDAs and measure the amount of energy
consumed with varying data sizes. The research indicates that Key initialization is more costly
than the encryption/decryption and therefore asymmetric encryption uses more of the PDAs
resources.
The implementation of SSL was found to increase resource use on the mobile device when
client authentication is enabled as more resources are used to negotiate client credentials.
[10] Investigates the impact of consuming web services based on SOAP called over the internet
using PDAs. The investigation tested two architectures. The first, using a direct connection
from the PDA to the Web service, where the web service is located across the internet, and a
different architecture, using a proxy server over the local area network which the PDA
communicates using a TCP connection. The second architecture consists of two different proxy
clients, one being JAVA based and the other C based.
Using the direct connection across the internet, requests take an average of 11 seconds.
Implementing the second architecture lowered the request time to 4.4 seconds. The times to
access web services are found to be delayed due to the cost of XML and SOAP parsing and low
bandwidth mediums being used that increase the transport time. While 802.11b protocol
operates at 11Mbps, tests showed that on average they operate at 47Kbps.
2.2.3
Summary
The research theory has provided a grounding to provide a usable and secure ubiquitous
environment for the MODUS system.
Schneiderman s design principles have been designed for desktop computers. While these are
most applicable for the desktop platform some can be applied to mobile computing to provide
usable interfaces.
9
The research has pointed out vital security vulnerabilities that exist in ubiquitous environments
Authentication
A solution to using certificates has been addressed that would provide a secure
method of authentication
Confidentiality over WiFi
The MODUS client s will be communicating with the MODUS server over a
wireless communication medium. The security research has provided, in great detail
the solutions that can be applied to provide a secure wireless infrastructure.
Availability
Creating a system for a ubiquitous environment will require on demand availability.
The weak wireless signals and slow responses from the server will create a delay that
will affect the efficiency of the system. The design of the MODUS system will
require an efficient method of transmitting information between client and server to
ensure availability.
Most solutions have been provided using conventional security techniques that will be adapted to
be used for the MODUS system
10
3 Definition and Theory
3.1 Problem Definition
The MODUS System is intended to provide an efficient means for students and lecturers to
communicate with each other in the Computer Science Department at UCT.
Currently students are able to leave messages and make appointments via e-mail, direct
communication and the use of post-it notes on the lecturer s office door. These are often
very inefficient as students are not always by a computer to send an email; post-it notes can
easily be taken off doors and often students are too scared to directly communicate with
lecturers and therefore decide not to confront the lecturer. For lecturers this is not an
efficient way of communicating with students either. Lecturers may be late, unwell for a
meeting or away from the office. The lecturer has no way of communicating with the
recipient to inform them that they will not be available for the meeting/lecture.
With the advancement in mobile technology and in the creation of ubiquitous computing
where mobile devices become integrated in the environment, PDAs have become advanced
enough to interconnect with high speed networks and able to compute information at an
efficient speed to meet users needs. Both lecturers and students are able to use PDAs to
communicate with each other.
While solving the problem of communicating with an absent lecturer there is also a need to
keep communication secure. The use of post-it notes, a popular method used by office
occupants leave messages open for others to view that are private.
3.2 Research Question
While there is a problem as noted above one needs to see if there is a solution therefore
Is it possible to create a solution to provide an efficient and convenient system which
can assist in communication between lecturer and student?
A similar project has been done by Lancaster University (HERMES), the focus being on
usability. Usability is important to our project but is not our focus. We will be focusing on
the security of a ubiquitous system such as the system being implemented here.
How can the 6 Network Security Services be used to secure a ubiquitous computing
environment created for messaging
11
4 Specification of Solution
The MODUS system requires two types of requirements. These include the research question in
mind How to create a secure ubiquitous messaging system and therefore having specific
Security Requirements as well as the end system functionality that will allow the MODUS
system to provide a convenient and efficient multi-functional messaging system.
4.1 Security Requirements
a) Confidentiality
The system will be required to ensure that all messages and appointments made by
students are kept confidential during transmission from the MODUS client to the
server. The system will need to make use of encryption algorithms that will encrypt
all information on the communication link.
b) Authentication
User Authentication
In a ubiquitous environment where it is not always possible to control who
is using the systems one can not ensure authentication. However new, quick
and efficient techniques are required to authenticate users at the PDA. The
technique must be relatively secure but must not endanger the usability of
the application.
Client Authentication
Potentially many office doors will be using the MODUS system and there
will be a requirement to authenticate each device to identify which client is
accessing the service. Client authentication is also needed for security
purposes to ensure that the server does not communicate with any rogue
client s and providing them a service that they are not authorized to access.
c) Integrity
All messages and appointments communicated over the communication link must
maintain its integrity to ensure that no information is altered during transmission.
d) Access Control
In an environment where multiple MODUS clients are operational, there
must be strict access control as to which client can access the specific data
requested.
Authenticated users will have access to extra functionality that requires a
user to be authenticated.
e) Availability
The system should be available at all times. It should run efficiently and effectively
on the mobile device.
f)
Non-Repudiation
The system is required to log all transactions that occur within the MODUS system.
This will remove any refutation of any transactions that may occur between client
and service.
Due to the nature of security, it is not an option to leave any security aspect out as any gap in
12
security can be used to an attacker s advantage and bring the system down. While no security
feature can be left out a priority has been given to ensure
Confidentiality
Integrity
Authentication
Access Control
Availability
These 4 features will ensure a high degree of security and reliability in the operation of the
system.
4.2 Functional Requirements
Other than the research question, there is a list of key features that are required to make a usable
multi-functional messaging system. The features have been defined based on user interactions
with a possible messaging system that both students and staff may find useful to their everyday
use of the system. The messaging functionality was the core functionality of the HERMES
system and is an important requirement to be included. To verify this and the other core
functionality, a focus group was held. The outcome suggested that HERMES was correct in
providing a messaging system and the focus group was in agreement that an appointment
scheduling system would be useful. Prior to the commencement of the project, it was decided
by the developers and project supervisor to provide each staff member specific functionality.
This included, calendar synchronization, RSS feeds and E-mail notification.
4.2.1
Requirements
Students can send messages to lecturer
Students can schedule appointment with lecturer
Lecturer can leave a temporary message displayed on the PDA
Lecturer can display free slots for students to schedule an appointment
Messages are E-mailed to the lecturer
Appointments are E-mailed to the lecturer
RSS feeds for new Messages
RSS feeds for new Appointments
Proximity Sensor can detect Lecturers Bluetooth device when in range
Lecturer can synchronize personal GroupWise calendar with the MODUS calendar
All these features are beneficial to creating a usable system that allows for convenient
messaging. Unfortunately in a limited time span allocated to the project. Not every feature can
be implemented. A priority list has been decided based on the developer s decisions on the key
features of the system.
4.2.2
Core Functional Requirements
The core functionality that will be implemented in the MODUS system includes:
Message functionality
Appointment functionality
13
4.2.3
Complete Functional Requirements
Email functionality
RSS functionality
Synchronization functionality
4.3 Division of Work
The development team decided to split the functional requirements into messaging and
appointment scheduling. All components (client, server, web administrator) will be divided
between these sections. This report will focus on the specific functionality that deals with
appointment scheduling.
4.3.1
Non-Security
Appointment functionality
RSS
E-mail
Synchronization
Bluetooth Sensor
4.3.2
Security
Confidentiality
Integrity
Device/Server Authentication
Access Control
Availability
Other functionality will be developed and implemented by the rest of the MODUS team.
4.4 Methodology
It has been decided by the MODUS developers to start development from the ground up. While
taking the results of the research done by the HERMES team, it has been decided to start all
coding from scratch. Building the system will involve creating a secure environment while
attempting to keep the system usable.
The software development approach of the MODUS system that we will take is XP
Programming. This is an adaptive, agile development methodology. We will focus on the fast
pace of development whereby coding, integrating, performing user acceptance testing and
creating prototypes.
Using the XP development approach also enforces user centered design where developers are
14
always in contact with the users to establish requirements and evaluate prototypes. XP practice
encourages pair programming, due to the small size of the development team and the limited time
each component will be coded individually. The MODUS project has been separated between the
developers into the Messaging component and Calendar component.
Extreme Programming methodology views a need for testing before coding has begun. Unit
testing will be performed. Automated test cases will be designed to test the core functions of each
component to ensure a well tested application. Integration is done on a continuous basis, as
specific functionality is completed for each component it is integrated with the base component
that controls both messaging and calendar component. These components form the pieces to the
final MODUS system that will provide a multi-functional messaging system.
The user centered design approach will allow for the creation of usable interfaces. Focus groups
have been held to design the interfaces. Designing for mobile devices is complex as the screen
size of the device is small and makes it difficult to display lots of information on a single screen.
This often creates an increase in the number of button presses required to complete an operation.
The developers will create a simple interface based on user requirements gained from previous
systems and allow a focus group to comment on the designs and comment on the usability of the
system and possible changes.
The interfaces initially took the form of a paper prototype. As the XP process evolves, more focus
groups will be held and high fidelity prototyping will be used. Users will interact with the PDA
containing a functional interface with various operations available. As this evaluation takes place
new requirements may be proposed and integrated into the final system.
4.5 Evaluation
The MODUS project as mentioned above consists of a security component and a basic
functionality component. These combine to provide the secure ubiquitous environment that will
provide a messaging system.
The project is deemed to be successful when both lecturers and students are able to communicate
messages and create appointments in a secure environment while leaving the user satisfied with
the usability of the system indicating that it can be a success in the real world environment.
15
5 Design
This section defines the design of the system. The design proposes possible solutions for creating
the MODUS system with regards to the technology being used and possible implementation
techniques that will be applied.
5.1 MODUS System Overview
Figure 1: MODUS System Design
The MODUS system is designed to provide a messaging and appointment scheduling system
that will allow office occupants and visitors to communicate in an environment where there is
no requirement for the occupant to be in their office.
The MODUS System it separated into three sub systems. These include the MODUS client,
MODUS server and Web Administrator. Each sub system is integrated to provide a multifunctional messaging system between office occupants and visitors.
16
5.2 Calendar Client:
5.2.1
Hardware Design Platform
Model:
HP iPAQ 4150
OS:
Pocket PC 2003
Communication:
WiFi 802.11b, Broadcom Bluetooth Adapter
5.2.2
Programming Language
Mobile devices are limited in functionality and do not interoperate with all existing
programming languages. Various programming languages exist that support an API for PDAs:
JAVA, C# .NET, embedded C++, Visual Basic .NET. It has been advised to the MODUS
development team by the project supervisor that it will be best to develop in the .NET Compact
Framework 2.0 which is supported by the PDAs Operating System: Pocket PC 2003.
The Compact Framework 2.0 is a compact version of the full .Net Framework that is designed
to run on mobiles devices such as PDAs and is compressed to 1.35MB in ROM. The .NET
Framework is Microsoft s Application development platform that allows developers to easily
create Windows applications. This platform deals with the low-level management of memory
management and processor-specific instructions. [11]
The .NET framework is language independent and C# and VB .NET are able to execute on the
platform. C# is a fairly new object oriented language that is derived from C and C++, it is also
derived from JAVA and supports garbage collection. C# is based from 3 powerful and well
developed languages and integrating the strengths of these languages into a single language.
[12]
Garbage collection is vital when developing for the PDA; resources are scarce and the garbage
collector can efficiently free resources when they are not being used.
The decision to use the .NET framework over JAVA is based on the amount of functionality
provided and the ease of developing and deploying applications to the mobile device.
5.2.3
Bluetooth Sensor
The Bluetooth Sensor is designed to use the Bluetooth adapter to determine when the office
occupant is in the office. The Bluetooth Sensor Component listens to broadcasts from various
other Bluetooth Devices in range. Each device broadcast contains a user defined name. Each
MODUS system PDA will be configured to listen for broadcasts containing the device name as
specified by the office occupant.
To develop applications using Bluetooth adapters one needs to interface with the Bluetooth
stack. Each layer of the stack maintains an interface to communicate with. Two stacks currently
exist, the Broadcom stack and the Microsoft stack. The Microsoft stack API is free with the use
of the .NET framework and Broadcom charge a fee to use the original Broadcom API. The
operating system that is used on the iPAQ 4150 (Pocket PC 2003) does not allow for the
17
Bluetooth stack to be changed.
High Point Software has created BTAcess. This 3rd party library is compatible with the
Compact Framework 2.0 and provides an API to interface with the Broadcom Bluetooth Stack.
Due to the high price of the Broadcom API, it has been decided to use the 3rd party library.
5.3 Calendar Web Service
The MODUS Calendar Web Service is designed to allow the Calendar Client to
View all Free Appointment Time Slots allocated per day
Create Appointments
E-mail Appointments to occupants
5.4 Hardware Design Platform
Model:
AMD 1.1 GHz
Operating System:
Windows XP
5.5 Programming Language
The two languages available for providing server side services are ASP .NET and JAVA
The .NET Framework provides extensive support for interoperability through web services
[13]. Web Services Packages exist to implement web services using JAVA. Apache SOAP can
be used to create a JAVA based web service. Due to developer s preference and the already
chosen C# languages for the MODUS System client, the Web Service will be developed using
C# and ASP .NET. ASP .NET web services automatically package C# data types into SOAP
messages and allows for seamless transmission to/from the client application.
To allow for interoperability, all communication between client and server will be transmitted
using SOAP messages. SOAP communication ensures that all messages are transmitted as
XML documents that are language independent. This will allow messages to be easily
consumed by clients or other web services written in a different environment if the MODUS
system is ever to be extended. Earlier research pointed out the overhead of using SOAP
messages from PDA s but the overhead was greatest when sending directly from PDA to the
internet, The MODUS system will be sending SOAP messages from PDA to Server in a local
area network, as the research did to speed up the connection and reduce the overhead.
REST (Representational State Transfer) is a software architectural style. It uses the HTTP
protocol to communicate between web services and is based on the design philosophy that the
current web works on. Information is transferred across the web using basic HTTP commands,
including:
Get
Post
Delete
18
Put
These basic commands are used to transfer information across web services.
It has been decided against using the REST architecture as Web Services Security will be used to
implement a secure environment using the SOAP protocol.
5.6 Web Server
The default Windows XP web server is IIS. IIS offers functionality that is required for the
MODUS System such as
ASP .NET support
SSL support
Client-Server Authentication
5.7 Database
To maintain Calendar entries and device information to authenticate multiple devices, all data
will be stored in a backend database. MS SQL Server 2005 integrates with the .NET
development environment (Visual Studio 2005) and offers ADO .NET. It is a data access
technology that provides connection pooling. It eliminates the requirement to manage
connections to the database and provides managed calls to query, update, insert and delete data
to/from the database.
5.8 Security
5.8.1
Confidentiality and Integrity
To create a secure environment in a ubiquitous environment, all communication must be
confidential and data integrity must be ensured.
This is achieved using:
Encryption
Hash Functions
Two standards exist to implement security over communication lines.
Secure Socket Layer (SSL) is implemented at the transport layer and is application
independent. SSL ensures that all contents of a message are encrypted.
SSL can be automatically implemented using the IIS web server. It provides a SSL
connection to every client that is served. Each client communicates over the HTTPS
protocol and both client and server can negotiate encryption keys to allow for a secure
communication.
19
Web Services Security is used to secure SOAP messages being transmitted between the
application and web service and operates at the application level. Web Services Security
can be implemented in the Microsoft .NET Framework using Web Security Enhancement
(WSE) 3.0 or Web Security Enhancement (WSE) 2.0. However the Compact Framework
does not support WSE 3.0. Freely available 3rd party library (OpenNETCF) provides
support for WSE 2.0 on the compact framework. WSE 2.0 is designed for the full .NET
framework 1.1 and not for version 2.0 which is the development platform that the
MODUS system will be implemented on.
WSE would provide a more efficient solution as less data can be encrypted. The development
environment however is not suited for the old technology that would be required.
To create Hash values of messages being transmitted, SHA1 is offered by the .NET framework.
The alternative that is also offered is the MD5 algorithm; this however has been proved to be
insecure in practice.
5.8.2
Device Authentication
IIS provides a secure method of authentication, client to server and server to client. X509
certificates can be generated using a freely available application (OpenSSL) which creates a
test Certificate Authority that is used to sign certificates of the client and server. Provided that
both PDA and Web Server contain the public key of the certificate authority as a root
certificate, the PDA will access the Server to be authenticated.
IIS provides client authentication where the web server can authenticate the client. The
Compact Framework does not support client certificate authentication and there is no means for
the client to send a certificate to the web server. An alternative option is the use of client
credentials where IIS uses its own Windows Login database to authenticate users. To store the
password (with out hard coding it) on the PDA can not be done securely. The password can be
stored encrypted but in a ubiquitous environment it is not possible to ensure the physical
security of the device and can potentially be accessed. The key can therefore not be stored on
the PDA either.
A solution using a 3rd party library (OpenNETCF) exists and supports the sending of client
certificates to the Web Server. The problem of storing the private key of the client on the PDA
is a security risk.
The solution to providing client authentication is based on MAC address authentication. As this
is often used to secure WiFi environments as achieved on the UCT network we feel it is best
suited for the limited options available in an open environment. Realizing MAC address s can
be spoofed it has been indicated by a Masters Student that it is more difficult to spoof a MAC
address over IP address spoofing. To filter MAC addresses of clients the use of a packet
filtering firewall is used. Sygate Personal Firewall is a free firewall that is able to filter clients
based on their MAC address.
MAC address filtering using a firewall allows access control to the web service but does not
allow for the tracking of individual access to specific services being accessed. To allow
multiple devices to communicate with the web server, knowledge of which PDA is invoking the
web service is required. ASP .NET fails to provide methods to retrieve a remote client MAC
address. Windows XP provides a library that is capable of performing ARP (Address
20
Resolution Protocol) functions. Using the iphlapi.dll library, low level networking calls can be
made. The SendARP function sends a request to a client machine to obtain the physical address
that corresponds to a specified IP address.
5.9 Calendar Synchronization
To easily integrate the MODUS calendar component into the office occupants personal calendar
there is a need to synchronize the MODUS calendar with the occupants personal calendar and
vice versa.
The two options as decided by the MODUS team are Microsoft Outlook 2003 and Novell
GroupWise. They are seen to be a popular choice by staff members and provide an API that
easily integrates with c# and the .NET environment using the Component Object Model.
GroupWise is also becoming the shared calendar system that will be used at the University of
Cape Town for all departmental members. For a successful system, it is in the developer s
interest to allow MOUDUS to integrate with its users every day life.
5.9.1
Component Object Model
Microsoft COM is a technology that allows software components to communicate [14].
Microsoft Outlook provides access to MS outlook using the COM model. Application
development can be performed using the .NET framework and all MS Outlook calendar
features can be accessed.
Novell GroupWise stores all personal data in a database that is accessed through the POA (Post
Office Agent). Users access the POA using the GroupWise client provided by Novell. The
decision to use GroupWise is due to UCT changing their shared calendar to use GroupWise.
The rollout is being planned for the middle of 2007 and due to security reason the MODUS
team have been refused direct access using SOAP messages to the POA and therefore access
the database. The alternative approach is to integrate the synchronization application with the
GroupWise Client using the COM model. Novell offers an ObjectAPI that makes COM calls to
their client which directly interacts with the POA and only allowing reliable code to be sent to
the POA.
5.10 Calendar Interface Design
The calendar component of the MODUS system will allow users to create appointments with
each MODUS device owner.
The interfaces for both client (Figure 2) and web administration site has been designed on paper
initially by the designers trying to minimize the number of button presses the user will be
required to perform in order to achieve the required task.
21
Figure 2: Paper Prototype - Interface Design
The designs have been created using a User Centered Design principal where the design of the
interfaces has been verified with a focus on what the users want and need. The focus group is
held and each member of the group becomes part of the design process and able to adjust the
interface according to their expectations, allowing them to be part of the system design.
To test these designs and find possible adjustments for them, prototypes will be created and
used by users. The two levels of prototyping will be
Low Fidelity
High Fidelity
Low Fidelity
This prototyping involves paper based designs as the system where the users are able to
imagine the MODUS system as the real system. The user is then able to familiarize them with
the system and find any faults that may exist with the design.
High Fidelity
The low fidelity prototyping will focus on the design of the calendar interface. The high fidelity
prototype consists of code that simulates the system and its functions that the final system
consists of. The focus will ensure the system meets user requirements on a functional level and
allow the users to evaluate the usability of the interfaces.
22
6 Implementation
This section describes the implementation of the MODUS system and describes the design
options defined in the Design chapter that have been implemented.
6.1 System Overview
The final system is a set of sub systems written in C# to provide a multi-functional digital
messaging system. The three sub systems include:
MODUS Client
MODUS Web Service
Web Administrator
The system also interacts with a synchronizer to keep the owner s personal calendar
synchronized with the MODUS systems calendar.
Figure 3: System Overview
6.2 Programming Language
The final system is implemented using Microsoft C# and the .NET compact framework version
2.0. The compact framework provided a variety of controls and functions to build sophisticated
user interfaces, and allows for seamless communication between client and server using SOAP
messages.
23
6.3 MODUS Client
Figure 4: MODUS Client Class Diagram
The Client is made up of multiple interface controls that interact to provide the client
functionality. The main calendar control is responsible for retrieving calendarItems from the web
service and then distributing these time slots to the DailyBlocks control. This control lists all the
items where a user is able to select a time slot to book. The slot details are then passed from the
Calendar control to the CalendarItem control that allows the user to fill in information, i.e. student
number and message. This is then returned to the Calendar control and sent to the web service to
update the database.
24
6.3.1
Interface
The idea behind a ubiquitous system involves the system becoming integrated into the
environment. Having a secure environment is not enough to ensure usefulness as a ubiquitous
application. Using common GUI components of the .NET framework, users are able to feel
familiar with the system.
To provide users with a larger writing pad on the PDA, the PDA is developed using a landscape
property. The extra width provided using landscape did not provide enough space for a single
calendar interface as was discussed in the Design chapter (Figure 2).
Three separate interfaces have been developed, each providing the next step in making an
appointment.
Interface 1:
Figure 5: Calendar Interface
Users are able to select a date from the calendar displayed and then able to click Check
Availability .
Interface 2
Figure 6: Open Slots Interface
25
The Interface displays the Free Slots available to the user to make an appointment.
Interface 3
Figure 7: Create Appointment Interface
The user is able to create the appointment and then directed to the main screen.
The default keypad provided with the compact framework does not allow for developers to
define its position on the application. The default position for the keypad does not fit the
calendar interface elegantly. A new keypad control has been created to enter in a user s student
number.
Figure 8: Keypad
26
6.3.2
Class Implementation
To encapsulate every appointment scheduled by visitors to the office door a separate class has
been implemented.
Figure 9: Calendar Class
startDate and endDate store the respective dates that the appointment has been scheduled
for
Attachment stores a serialized Bitmap (XML String) of the message left by the visitor
and stored as a string.
Status indicates if the appointment slot if free or busy.
newItem() takes in all the variables listed above and sets initial values to all private
variables. This is required due to serialization problems. Using XML serialization,
constructors can not take in parameters or perform and tasks. A new method is used to
initialize all the required variables.
6.3.3
Bluetooth Sensor
The HP IPAQ 4150 communicates with Bluetooth devices using the Widcom Bluetooth stack.
This stack does not have an open source API. It has been decided to use BTAccess, a 3rd party
library created by High Point Software. The Bluetooth sensor was implemented first as it was a
small component of the final system.
Figure 10 illustrates the process of sensing devices using BTAccess. The BTAccess class
listens for all Bluetooth devices that broadcast its identification. This triggers an event. The
BTModule class listens for these triggered events and in turn executes a method that determines
if the device found belongs to the owner.
27
Figure 10: Bluetooth Sensor Protocol
The original design for the Bluetooth sensor requires the owner of the PDA to specify the name
of the mobile device to be sensed. After first implementation it was found that using the same
mobile device with changing device names, the Bluetooth stack only returned the old device
name and never refreshed
The reason for this was later found to be for optimization reasons:
The Bluetooth standard does not require the device name to be sent on broadcast. An
extra communication call is required to retrieve a device s name. To eliminate the cost of
repetitively retrieving the device name on each discovery process, Widcom stores a table
of MAC address s and corresponding device name in the PocketPC registry. The issue is
created as this table is never refreshed. When a device name is changed, the Widcom
registry does not see this change as the MAC address already exists in the registry.
To avoid this problem, a separate application has been created. The application deploys on the
PDA, and displays a list of Bluetooth devices in range. The staff member is then expected to
select their Bluetooth device. On selection, the application stores the mobile device s MAC
address in the system s registry and eliminates the need for the owner to specify the device
name when it changes.
Figure 11: Bluetooth Registration Application
28
6.3.4
Optimizations
Developing for mobile devices require efficient and smooth functioning interfaces. To
communicate with the web service, RPC calls are made. The process waits until the method call
has completed and all results have been returned. This creates a delay in the application and
the interface locks until each web service request has completed.
Sending SOAP messages consume most resources and often is the most time consuming
operation. To eliminate the need for the users to wait for lengthy periods of time for an
operation to complete, threading has been implemented. When a user Posts an appointment, it
is scheduled in the background using multi-threading.
This creates a potential problem if a user checks the same slot listing immediately. The lookup
shows that the slot is free. To reduce the possibility of this occurring, a short delay has been
programmatically introduced using threading. The interface indicates that Scheduling is
taking place and then informs the user of its success and reverts to the main screen.
Transmitting data over 100kb to the web service causes the PDA to time out. To resolve this
problem the calendar object containing the image is split and sent across in pieces and
appended to each other on the server side. With the use of threading there is a risk that two
threads will execute the same function and then write to the same file and cause a error. To
avoid writing to the same file, each method takes in a random number. This random number is
created at every new thread and is attached to the filename to ensure no clashes occur.
For every appointment that is scheduled, a new calendarItem instance is created. The garbage
collection in C# operates periodically and creating multiple appointments in a short period of
time containing large images fills memory and puts strain on the available resources. The need
for the cleanup() method shown in figure 9, is used to remove the attachment from memory to
free up resources then allowing for garbage collection to free the other resources.
29
6.4 MODUS Server
Figure 12: MODUS Service Class Diagram
30
The calendar service is responsible for interpreting the client instructions and executing the
required methods on behalf of the client. The CalendarService class is responsible for cocoordinating services such as device authentication, sending emails and creating, viewing and
updating appointments in the database.
The decision to use SOAP messages has been implemented for reasons of interoperability and
seamless development between client and server in the .NET environment. Including the
extensive research performed to use SOAP for security reasons which later realised is not
viable. It is felt that it is too late to change the implementation technology due to the limited
time to develop the MODUS system.
The Web Service is developed in C# and operates with ASP .NET web services. The WSDL
description files are generated automatically by Visual Studio 2005. The MODUS system has
been split into two. The components are allocated into separate services: Calendar service and
Messaging service.
The implementation of the web service is mainly automated. The operation of communication
is as follows:
WSDL (XML schema) is created by VS2005 based on the method names created in the
web service class.
The client creates a proxy class based on the WSDL file and makes RPC calls to the web
service, parameters are automatically marshalled to SOAP requests and the Response is
sent back to the client.
Each service method is implemented in a manner that every call to the web service is
independent of the other and therefore an error in one connection will not affect another.
6.4.1
Class Implementation
The web service contains a main CalendarService.asmx file that is used to create the WSDL
file. This is the interface that the client sees. When a method is called by the client, the .asmx
file is referenced and the contents of the method are executed.
Figure 13: CalendarService Class
31
Figure 14 is an example SOAP message returned when the server provides the free appointment
slots to the client. The .NET framework sends array s as no specific type and requires the Client
side to cast any array type into the specified type.
<?xml version="1.0" encoding="utf-8" ?>
<ArrayOfAnyType
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://MODUSCalendar.org/">
<anyType xsi:type="xsd:string"><?xml version="1.0" encoding="utf-16"?>
<CalendarItem xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Id>106</Id>
<StartDate>2006-11-04T00:00:00</StartDate>
<EndDate>2006-11-04T00:00:00</EndDate>
<StudentNumber />
<Status>true</Status>
<Privledge>public</Privledge>
<Attachment>na</Attachment>
<PublishedDate>2006-10-23T09:27:34.73</PublishedDate>
<Owner>gmarsden</Owner>
</CalendarItem>
</anyType>
</ArrayOfAnyType>
Figure 14: SOAP Response
6.4.2
Database
All information is stored in a SQL server database. The integration with the .NET environment
with SQL server made this the right decision as the environment offers better performance over
other 3rd party database servers. ADO .NET connections are used to manage the database, this
offers pooling and more efficient interaction with the database.
32
Figure 15: Calendar Database Table
6.5 MODUS Web Administration
Each office occupant is able to control their MODUS PDA using a Web Administrator. This is
web based and decided upon as it will allow for anywhere/anytime access for each occupant.
Remaining with the environment and language used to create the client and server application,
the Web Administrator has been developed in ASP .NET. ASP .NET allows for creating
dynamic websites.
The administration site is split into three sections, messaging, calendar, and administration.
The owner is able to delete, view, modify and create appointment slots. To create appointment
slots, two options are implemented:
Single slot
o A single slot allows the owner to create a single open appointment slot using a
start date with the start and ending times for each.
Repeated slot
o A repeated slot is viewed as a requirement as many office occupants set specific
times every week where they make themselves available for a meeting. The times
are usually the same and impractical to make the owner work through creating a
single entry for each day of every month. The owner is able to specify a date
range, days of week and the time span for each meeting. This allows for flexible
control over which days are allocated.
For every appointment made, it is vital to ensure that no time slot overlaps or conflict. Creating
repeated slots become complicated and require a way to ensure no duplicates are made. To
ensure this, each slot is matched against all the current existing appointments. The overlaps that
seemed most obvious to occur and accounted for include the current scenarios:
33
Figure 16: Overlapping Time Slots
The web administration website contains RSS feeds of all the latest messages and appointments
created. The RSS feed has been implemented based on the RSS 2.0 standards and displays the
latest 10 messages and appointments that have created using the MODUS Client.
6.6 Security
6.6.1
Encryption
Due to the limitations of the compact framework, SSL is implemented to provide secure server
authentication, encryption and integrity. SSL provides Encryption and Integrity for the
underlying connection used for communication between client and server.
The implementation of SSL is provided by the web server. IIS provides a standard
implementation of SSL that uses certificates to negotiate the secure connection. IIS removes
most of the responsibility for encryption. All key seeds are ensured to be correct. SSL also
provides server authentication that is discussed below.
34
6.6.2
Server Authentication
To ensure clients are able to authenticate the MODUS server and eliminate any rogue servers
masquerading as the MODUS server, certificates have been used. IIS controls this
authentication using SSL.
In a real world environment, certificates are authenticated using a Certificate Authority.
However, certificates are expensive. A proof of concept approach has been taken to implement
authentication. To do this, an application OpenSSL is used to create a self signed certificate.
The steps are as follows:
Create a Certificate Authority Private/Public key pair.
Create Server Certificate Private/Public key pair signed by the Certificate
Authority private key.
Figure 17 illustrates the protocol used to authenticate and setup the initial SSL connection. The
client requests a secure connection; the server sends its certificate to the client whom checks to
see if the Certificate Authority that signed the certificate is trusted. If the certificate authority is
trusted the client accepts the certificate and agrees to create the secure connection.
Figure 17: SSL Authentication
OpenSSL is used for test purposes. It provides the functionality needed to prove that the
implementation will work using more secure Certificate Authorities. For commercial
application the certificates must be based on a recognised Certificate Authority that can ensure
the security of their keys.
6.6.3
Device Authentication
Authenticating devices using certificates is not possible due to the limitations of the compact
framework and the open environment in a ubiquitous environment. MAC address filtering has
been implemented. At first firewalls were seen to be the best option. It was later realised that
both web service and remote administration site operate on the same port number. Performing
access control by MAC address would require all devices accessing both web service and
website to be authenticated by MAC address. This is not an option as owners can not be
restricted where they can control the office door.
35
Figure 18: Device Authentication
Figure 18 illustrates the implementation. It is based on a sequence of request/response s to
determine the connecting device s MAC address. The implementation is split into 2 classes.
1. DeviceAuthentication
Transmits a request to the device via IP address for device MAC address
2. dbDevice
Executes a database lookup, to find a matching MAC address and the owner
associated with the address.
If no match is found the connection is closed and the client is denied access. Due to the
independence of each web service call, each method executes a MAC request and a MAC
lookup.
Figure 19: Device Authentication Database Table
Device authentication has also been used to provide a multi user system. Each device can be
registered to an owner s door and every message or appointment made on a particular device
has the owner s name included in the data base table as shown in Figure 19.
6.7 Calendar Synchronisation
Implementing synchronization with GroupWise has been implemented as any success for the
MODUS system requires popularity and possible integration to the owners personal calendar.
The GroupWise system is platform independent and owners operating with UNIX, Mac and
Windows XP are able to use it.
A problem encountered when implementing synchronization is the conflict between the
MODUS calendar system and the GroupWise calendar System. MODUS rejects any time
overlap in appointments, GroupWise allows for a number of appointments scheduled at the
same time. To avoid this conflict, one-way synchronization has been implemented.
36
A separate Application has been developed for synchronization. The application however is
platform dependent. For security reasons the MODUS team are required to communicate with
the GroupWise Post Office via the GroupWise Windows client.
The GroupWise Object API creates a hidden instance of the GroupWise client and all
communication with the Post Office Agent is performed via the client. The synchronization
application retrieves all appointments that have not been synchronized and updates the owner s
personal calendar. When appointments have been deleted via the administration website, they
are stored and then deleted from the personal calendar.
Figure 20: GroupWise Synchronization
37
7 Testing and Results
Throughout the development of the MODUS system, a focus has been set on security. To fully
test this system for its use in a ubiquitous environment requires testing for both security and
usability.
The tests have been split into 2 categories
1. Functionality Testing
Security/Non-Security
2. User Testing
The main sections for testing have been focused on the security between PDA and Server and
usability for using the PDA in a real world environment.
7.1 Functional Testing
Each of the security services that have been implemented requires testing.
1.
2.
3.
4.
7.1.1
Encryption
Resource Availability / Load Testing
Encryption/Integrity
Encryption is provided by the session keys created when the server exchanges its certificate
with the client. This procedure is controlled by IIS and is assumed to be stable and well tested
by Microsoft.
To ensure all data is encrypted, a program called Ethereal has been used to monitor all packets
being sent to the web service. Figure 21 and Figure 22 show a response to a getFreeBlocks()
method call. Figure 21 shows a response containing no encryption/integrity and Figure 22
shows an encrypted/integrity response.
Figure 22 shows a lower section that can be interpreted in plain text. Dates, student number,
owner and other potentially confidential information can be accessed.
In these figures, 137.158.98.11 refers to the MODUS server and 137.158.96.67 refers to the
MODUS test client
38
Results
Figure 21: Clear Text Response
Figure 22: Encrypted Response
Figure 22 shows the SSL handshake taking place when the first method call is placed to the
web service. It illustrates the negotiating of the session key. Part of the payload in the response
can be seen on the bottom section. All data has been encrypted and the data can not be
interpreted by capturing packets between client and server.
Integrity is also illustrated in Figure 22. The headings labelled with checksum ensure that data
has not been modified during transmission.
39
7.1.2
Server authentication has been implemented to ensure that all MODUS clients are guaranteed
that they are communicating with the MODUS server. As mentioned in implementation this has
been based on certificate authentication.
A number of tests have been performed to ensure authentication is valid and each client does
not communicate with any rogue servers. 2 scenarios have been put in place to see how each
client reacts.
1. Client does not contain the Certificate Authority certificate as a trusted
Authority.
2. A Rogue server attempts to use a different certificate signed by the same
Certificate Authority
Results
1. When the server sends the certificate to the client. The client attempts to verify it using
the Certificate Authority that signed it. However, if the CA is not trusted by the client it
can not authenticate the certificate. The tests confirmed for clients that did not contain the
trusted Certificate Authority would not allow any communication between the services
when a method call was made. The client closes the connection to the server and waits
for user response.
2. A situation can occur where a rogue server is able to get a certificate signed by the
certificate authority that is used to authenticate the MODUS server. If this happens, the
MODUS clients are required to recognise that this certificate is not valid. The standard
approach of doing this is to allocate each certificate for a server with a common name.
This common name is based on the server host address. The client matches all certificates
with the server s host address. If this does not match the common name the client is
attempting to connect to, the client can recognise the rogue server is masquerading as the
MODUS server.
To confirm this, a separate certificate was created using a different common name
marvin.cs.uct.ac.za this represented the test rogue server. The server attempts to send
its certificate to the client that is connecting to the MODUS server. The test resulted in
the client application closing the connection and recognising it as an unauthenticated
server.
7.1.3
Client authentication guarantees the MODUS server that it is communicating with a legitimate
MODUS client and allows for distinguishing between which information belongs to which
device. As mentioned in the implementation chapter, this has been implemented using MAC
address filtering using a lookup table in the database for every device.
It has been noted in design that MAC address filtering is not the most secure method of
authentication and can be spoofed, but due to the limitations of the compact framework and the
open environment being developed for, this is a viable implementation.
The scenarios that will be tested for client authentication includes:
1. Client PDA attempts to access the web service but is not authenticated.
40
2. Client PDA attempts to access the web service as a registered device
3. Client is registered but attempts to access a different owner s information.
4. Two MODUS Clients attempt to retrieve information.
Results
1. The connection between the client PDA and MODUS Server is
terminated by the server when each method is called by a nonauthenticated user.
2. The Server executes all methods correctly and returns all information.
3. To manipulate each client to send different owner details, it has been
hard coded to set a new calendar item instance to match a different
owner. The server places the updated appointment under the device
lookup name and not the name associated with the calendar item instance
from the client.
4. Using multiple devices, each client retrieves the correct information, not
accessing any other owner s information.
7.1.4
Bluetooth Sensor
During the iterative process of testing all functional components, the Bluetooth sensor kept on
showing weakness. Other project teams dealing with Bluetooth devices also complained of
similar failures as mentioned below.
Results
After extended periods of use, the Bluetooth device stops communicating.
The Bluetooth discovery process is often disrupted due to outside interference
from WiFi signals and other Bluetooth interference.
The 3rd party API does not always close the Bluetooth connection cleanly on exit
and causes the Bluetooth to stop responding when re-launched.
7.1.5
GroupWise Synchronizer
As each component of the synchronizer was implemented, it went through a process of
intensive testing by the developers. The synchronizer was executed each time a user created an
appointment or the web administrator was used to create, edit or delete a time slot.
Results
The application to synchronize entries has been found to be stable. No faults have been found.
One problem for change was found. The attachment being sent to the GroupWise client was not
being resolved as a valid jpeg file. To fix this, the mime type was corrected and all attachments
were valid.
7.1.6
Client/Service Faults
In the real world environment the MODUS system is required to operate for variable lengths of
time and must always be available for use. Handling of faults is required to provide a reliable
41
service. To test possible faults due to attackers or possible overlooked faults during testing, the
MODUS client has been subjected to intensive unit testing and forcing the service to return
faulty information to the client and view how the client deals with the faults and determine if
the client is able to recover to continue to provide the required service.
Results
An example for this test involved sending back a String as a list of times available to the client
instead of the expected ArrayList containing CalendarItem objects. The client did not crash and
displayed the list interface (Firgure 5) with an empty list. The server was then changed to the
correct service while the client was connected and an attempt to list the available time slots was
attempted. The client was able to retrieve valid times and able to display them with no faults.
7.1.7
Web Administrator
The testing of the web administrator was provided iteratively for each component added to
ensure each component independently was correct. After integration a number of integration
tests were performed which consisted of allowing users to use the administrator as would be
performed in everyday use and view any faults that occurred.
Results:
Small faults were found when testing the web administrator during the various testing phases. It
was found that on editing an appointment slot, the algorithm that checks no overlapping was
preventing from updating the edited slot. This was minor and changed after the testing phase.
During integration testing it was found that certain methods used as a single component were
not configured correctly when integration was implemented. This was also minor and changed
to allow for an integrated version.
7.1.8
Web Service
To focus of the web services testing consisted of unit testing of the interfaces exposed by the web
service as well as load testing. The load testing was important as to establish if the MODUS
system can be viable in a real world environment with various users, the server must be capable
of handling the MODUS clients and the operations it must perform to provide a service.
The service load testing was a joint effort by the MODUS development team to see how the
server is able to handle the load.
To get an accurate measure and to establish to more expensive operations a few scenarios were
played out to get accurate readings.
Web Service Scenarios
1.
2.
3.
4.
View the application load time effect on the server
Use a single client to make an appointment with the server
Use a two clients to make an appointment with the server
Use two clients, 1 messaging and the other making appointments
42
Results
1. The initial application load consisted of a number of web service calls, including
retrieving owner details and Bluetooth status and to initialize SSL session keys. This
created a spike of approximately 20%. When testing this to ensure results were the same,
it was found that some major spikes occurred. This was later found to be due to the image
of the owner that is displayed on the client. This image is sent to the client every 30
seconds. At the time, the picture currently set was big in size and created a bottleneck
when transmitting to the client. As mentioned in the implementation section, each image
sent is sliced and sent over in pieces. This occupies resources for longer and therefore
keeping the server busy for longer. Figure 24 shows the graph that displayed the display
of the image over 30 seconds.
Figure 23: Initial Load Graph
43
Figure 24: Image Update Load Graph
44
2. During the testing with a single client there was a spike due to the updating of the image.
Besides for this, the graph seems rather scattered and tends to jump from 0% to 20%. The
recorded average between start and end of test was 9.610. In figure 26, it can be seen that
the percentage use of the server s CPU increases with an average of 7.245% of CPU
usage from start to end. While this seems to be a slight difference one must take into
account the spike in the first graph that may have increased the first average given.
Figure 25: Single Client Appointment Scheduling Load Graph
45
Figure 26: Two Clients, Appointment Scheduling Load Graph
3. Combining messaging with making appointment, the CPU usages did not differ from the
tests done with two clients testing dedicated to making appointments. The average CPU
usage was 7.245.
Figure 27: Two Clients, Messaging and Appointment Scheduling Load Graph
46
From the load testing it can be seen that the server does not scale well with the clients. It was
only possible to test the server with 2 PDA clients. For a more conclusive result it would be
more useful to use 3 or 4 clients.
Some possible reason for the difficulty with scalability is the server hardware. The server is
running minimum requirements using a 1.1GHz with 394MB or RAM. Servers such as SQL
Server and IIS are resource intensive and can often use up lots of resources when operating. The
use of SOAP messages created a large overhead even in a local area network environment and
often slowed responses due to the XML parsing.
7.2 User Testing
The user testing has been structured based on a naturalistic observation process. Users are given
specific scenarios and their behaviour is noted. After users have completed their scenario they
are questioned on their opinions on the system.
7.2.1
MODUS Client
The testing environment is based in a real world situation. The Mobile device is placed next to a
staff member s door to simulate the actual positioning a user will be when using the system.
7.2.1.1
Iteration 1
Client Scenarios
1. Make an appointment with Gary.
You are not a registered user. Make a single appointment for tomorrow.
2. Make an appointment with Gary
You are not a registered user. Make an appointment for next Monday and Tuesday for
an exam revision session.
3. Make an appointment with Gary
Your user code is (1-2-3-4); make an appointment to see Gary on November the 8th.
From the naturalistic observation it could be seen how making a ubiquitous system usable is
very complicated and difficult to get right. During testing many of the subjects were not
familiar with the new technology (PDAs). This made figuring out the controls extremely
problematic. The common .NET controls were not as common as first thought. The subjects
were not entirely confident how to use the, .NET calendar as they were not very familiar with it.
The beneficial comments that came from the test subjects was the need to more instructions as
using a new technology where one does not have a natural keyboard to type. The users were not
sure how to write a message on the screen.
After the user testing, some of their suggestions were implemented. This took the form of
renaming controls and labels to better understand the interfaces and including labels to the
interfaces to explain what the user must do to accomplish each scenario.
47
From the problems found in the user testing, it was decided to implement these changes and then
perform another iteration of user testing to so how the changes have affected user reactions.
Results
The problems most users had when completing the scenarios are as follows:
1. People assumed the listing of the free slots were actually a listing of current slots booked.
Instead of selecting a slot to book, they pressed create to book a free slot.
Figure 28: Calendar Interface
View Appointments has been changed to View Available Time Slots as users were not
always sure what View Appointment would trigger.
2. The users never seemed to be sure what to do next and often hesitated for a lengthy
period of time and often help was provided by the testers.
Figure 29: Open Slots Interface
The Create button has been changed to Book to indicate the user is booking a slot. And help
suggest that they must select a slot to begin. A label has also been added to indicate that the user
must select a slot.
48
3. On the interface where the message is written, users were able to write the message easily
but always forgot to type in their username. They came to realize this after pressing
POST and viewing the error message.
Figure 30: Book Appointment Interface
It was decided to add a larger label displaying that the user should enter in their student number
or name. The original text message was also made bold to focus the users attention.
4. The keypad was seen as a good tool and often users would mention how they preferred
typing on the keypad over the free hand drawing. A certain participant mentioned they try
not to write using a pen as often as possible. A problem noticed with the keypad was
exiting from it. Users were confused whether pressing Close would save the student
number.
Figure 31: Keypad
The keypad button that originally had a close option has been changed to ok .
7.2.1.2
Iteration 2
The 2nd round of user testing took the form of naturalistic observation as used in iteration 1. It
was decided to take two groups of people. The first group included users who had previously
tested the system and the 2nd group included new users who had not used the MODUS system
before.
49
Results
The users that tested the system before preferred the changes that were made to the system and
found it very usable.
The group with no experience showed more understanding when using the system. Two of the
test users did mention that they were uneasy using the system and were not entirely sure how to
proceed. When asked about this they felt unsure how the Calendar control worked and were not
sure how to proceed to the listings. When they accomplished the scenarios however they did feel
that the system was usable and believed that all they needed was a few minutes to familiarize
themselves with the interface.
The other test subjects felt that the system was usable and were satisfied of the overall usability
and functionality that they were presented with.
Persisting Problems
Student number / name was often left out by the users and only entered after a
POST to book the appointment was attempted and an error was displayed.
7.2.1.3
Conclusion
The general opinion by the test subjects after iteration 1 indicated a preference to the improved
layout of the interfaces and found the system more usable.
A suggestion proposed to ensure that users enter the student number / name. It was suggested
that the textbox to type the student number / name should be lowered under the message control.
While this is a workable idea, lowering the textbox would cause the keypad to overlap it and
therefore eliminating it from the users sight.
It has been decided to change the Text from StudentNumber / Name to Enter Student
Number / Name .
7.2.2
Web Administrator
User scenarios
1. Create a single slot for a student to make an appointment on the 6th of November
2. Create an time slot that will be repeated every Monday, Tuesday, Wednesday from the
10th November to the 30th November from 3pm 3:30pm
3. View the appointment made for the 1st December 2006 from 2pm 2:30pm, Change the
time to 8am-9am
4. Delete any free slot made on the 5th of November
Results
1. The test subjects found it to be a simple task to create a single appointment and some
subjects found the interface to be very familiar to their current calendar usage.
2. Some of the test subjects were not sure how to create a repeated time slot when looking
at the initial calendar interface. Suggestions included adding to the help section how to
create multiple slots.
50
3. The subjects found it easy to view messages and edit messages.
4. The subjects found the required task to delete appointments, a simple task and no
complaints.
General Usability issues with the web administrator included, interface colours where
sometimes weak on the eyes. The mixture of bright orange and blue made the links on the web
page difficult to read. The overall consensus was that the functionality was adequate and well
designed.
After user testing, all the suggestions were implemented to the web administrator to improve its
usability. This change includes:
Increase number of labels indicating the controls to press to achieve a specified
scenario
Change colours of the interface to allow for easy viewing
51
8 Conclusion
The main goal of the project is to create a multi-functional messaging system that will provide
communication between staff members and students in a secure, ubiquitous environment.
The initial requirements seen for the MODUS system consisted of:
Students can send messages to lecturer
Students can make appointment with lecturer
Lecturer can leave a temporary message displayed on the PDA
Lecturer can display free slots for students to make an appointment
Within the framework of making this functional system, all functionality was to be provided in
a secure environment. To ensure this the security aims consisted of:
Confidentiality
Integrity
Authentication
Access Control
Availability
The MODUS system has achieved both its functional and security requirements. It has been
found that the Bluetooth functionality is the most problematic feature of the system. It would be
best implemented using the original Broadcom stack over the 3rd party library.
Much research has taken place with regards to security in ubiquitous environments, and the
MODUS team has been able to implement most of the security requirements using standard
security concepts. While the compact framework is limited in security functionality, there were
always alternative approaches available. Due to difficulties in assessing the availability of the
server, the security requirement of availability has not been ensured. While load testing has
provided the evidence that two clients can be handled, there is evidence that beyond a small
number of clients the server is not capable of handling a large number of requests.
The overall project is a success as not only has a secure environment been created using
conventional and non-conventional techniques, the MODUS developers have created a fully
functional system that has been verified through user testing to be both usable and enjoyable.
52
9 Future Work
Creating a system for a ubiquitous environment requires a certain amount of maintenance,
while all functionality has been tested and has been proven stable. The adding of devices and
setting up of certificates for every device is required for every MODUS system that is
introduced into the real world environment.
9.1 Hardware
The current PDA being used is the HP IPAQ 4150. This PDA is an old model and operates on
PockerPC 2003. The new version of Windows Mobile 5.0 allows for better functionality and
more sophisticated functions. Windows Mobile 5.0 allows users to change Bluetooth stacks
from a Broadcom Stack to Windows Stack and allows for seamless integration using c# in the
.NET environment.
From testing it can be seen that there are scalability problems. To establish the reasons for this,
it would be better to migrate from the current server to a more powerful system with more
resources available to run the actual software that is providing the client with the service such
as SQL Server and IIS.
9.2 Calendar Design
During implementation, it was suggested by the project supervisor that it could possibly be
useful having each staff member display a full timetable and allow each student to create an
appointment on any free slots not already booked in the time table.
Future work can be based on implementing a different way to allow users to sign up for an
appointment.
9.3 Bluetooth Sensor
During the implementation of the MODUS system, the Broadcom API became open source.
This is the official API that should be used with Widcom Bluetooth devices.
Using the 3rd party library to communicate with the Bluetooth stack kept most of the
functionality away from the developers and forced with interruptions at load time due to the
evaluation pop-ups that interfered with the loading of the MODUS client application.
The Bluetooth sensor was erratic when used and possibly due to the 3rd party library being used.
Using the official Broadcom API would allow for better control over device discovery and
better handling of the Bluetooth stack.
9.4 GroupWise Synchronizer
The GroupWise synchroniser has been developed to allow for 1-way synchronization. While
this allows some convenience to staff members to integrate the MODUS system with their
personal calendars, it is more convenient to allow for 2-way synchronization. This would allow
53
staff members to create and delete appointments from their personal calendar using the
GroupWise client.
Due to security constraints, the developers have been denied direct access to the main POA
(GroupWise Post Office Agent) database. This will allow for direct access to the database and
eliminate the platform dependency required when synchronizing via the GroupWise Windows
client.
9.5 Security
Other security techniques can be implemented, possibly with new versions of the compact
framework WSE will be available and can provide a better solution.
Using IP addresses to allow for authentication can be useful. IP v6 eliminates the possibility of
spoofing an address. This implementation can be a more secure solution if implemented.
9.6 Communication
From load testing it was shown that the MODUS server was not scalable with the MODUS
clients. From previous research it was noted that using SOAP messages increases overhead.
SOAP messages was initially used for security reasons and later realised was not possible. It was
felt by the development team that it was too late to change the technology being used as the
development process was not allocated enough time to change technologies.
Changing the communication to using a REST architecture or possibly a direct socket connection
between client and server may provide a more scalable system and possible to be implemented in
the future.
54
10 References
[1]
[2]
Cheverst, K., Fitton, D. and Dix, A. Exploring the Evolution of Office Door Displays.
O'Hara, K., Perry, M., Churchill, E. & Russell, D. (Eds) Public and Situated Displays,
Kluwer Academic Publishers, Dordrecht, pp141--169.
Gong, J., Tarasewich P. Guidelines For Handheld Mobile Device Interface Design
[3]
Haque M, Ahamed S I, Security in Pervasive Computing: Current Status and Open
Issues in International Journal of Network Security, Vol. 3, No. 3, 2006, pp. 203-214.
[4]
McLean, P. G. A secure pervasive environment, in Proceedings of the Australasian
information security workshop conference on ACSW frontiers 2003, Volume 21 ACSW
Frontiers 03, Jan 2003.
[5]
Salo, T. Security in Pervasive Computing
[6]
Housley, R. Arbaugh W. Security Problems in 802.11-Based Networks
[7]
Zahur, Y. Yang, Andrew Wireless LAN Security and Laboratory Designs
[8]
Potlapally, Nachiketh R. Ravi S, Raghunathan A, Jha Niraj K. Analyzing the Energy
Consumption of Security Protocols
[9]
Hagar Creighton T.R. Midkiff Scott F. Park J. Bradley Martin T. Performance and
Energy Efficiency of Block Ciphers in Personal Digital Assistants
[10]
Dalton A, Bansal V. A Performance Analysis of Web Services on Wireless PDAs
[11]
http://www.ondotnet.com/pub/a/dotnet/2005/09/06/what-is-dotnet.html
[12]
http://www.soaprpc.com/glossary.html (C#)
55
[13]
http://msdn2.microsoft.com/en-us/library/ms228596.aspx
[14]
http://www.microsoft.com/com/default.mspx
[15]
Schneiderman, Ben. Designing the user interface .
56
This document was created with Win2PDF available at http://www.daneprairie.com.
The unregistered version of Win2PDF is for evaluation or non-commercial use only.

Computer Science CSC4000W - Shenzi

Transcription

Similar documents

Readers Choice Award

Sign into the The Aribter.Net Website. www.TheArbiter

Certificate of Registration Glasseal Products Inc.

Marlton Office – New Patient Forms

Emeryville Advanced Imaging Referral Form Back

Certificate of Registration Glasseal Products Inc.

Step 1. How to generate authorization code for your Supra EKEY

Grace Dental 12425 55th St N Lake Elmo, MN 55042 phone 651

parathom - Stillwaters Law Firm