Agent Enhanced Mobile Privacy Framework

Agent Enhanced Mobile Privacy Framework

Loading
Loading Social Plug-ins...
Language: English
Save to myLibrary Download PDF
Go to Page # Page of 18

Description: Policy Driven Privacy Management System, Specifying Privacy Policies, Classification Model, Binding Personal Information, MAS-Based Privacy Framework, Policy Evaluation, System Evaluation, System Testing, Mobile Device Programming.

 
Author: Ibrahim Elgayar (Fellow) | Visits: 2008 | Page Views: 2011
Domain:  High Tech Category: Mobile Subcategory: Security 
Upload Date:
Short URL: http://www.wesrch.com/electronics/pdfEL1WSSGWTHPQX
Loading
Loading...



px *        px *

* Default width and height in pixels. Change it to your required dimensions.

 
Contents:
Agent Enhanced Privacy Framework To Support Mobile Users By Ibrahim Elgayar

Roadmap
Project Objectives Background Motivation Methods Survey Requirements & Challenges Method Evaluation & Testing Achievements Conclusions Supplementary Slides

1

Roadmap
Project Objectives Background Motivation Methods Survey Requirements & Challenges Method Evaluation & Testing Achievements Conclusions Supplementary Slides

Project Objectives
The overall aim is to develop a privacy management system for the the mobile users within location environment. The aim can be broken-down brokeninto:
� Assessing requirements for privacy protection for mobile users. � Assessing strengths and weaknesses of current privacy solutions for mobile users � Design and develop a user centered privacy system. � Evaluate proposed system and highlight possible future improvements in the improvements area of privacy.

2

Roadmap
Project Objectives Background Motivation Methods Survey Requirements & Challenges Method Evaluation & Testing Achievements Conclusions Supplementary Slides

Background Motivation
Recent tendencies in computing Devices are getting smaller and more powerful Users are becoming mobile Challenges of nomadic computing Risk of information overflow There is a need for content adaptation Increase in personalization can lead to the invasion of the individual's individual' privacy.

A user centred privacy framework is needed

3

Roadmap
Project Objectives Background Motivation Methods Survey Requirements & Challenges Method Evaluation & Testing Achievements Conclusions Supplementary Slides

Access control and authority delegation control
secure but has no privacy because of signatures

Basic Privacy Approaches & Their Limitations

Privacy Enhanced Technologies (PET)
not suitable for all situations

Provider Self-regulation of privacy policies (P3P)
Trust the provider's policy and self-regulation provider' self-

Legislative provisions
bounding to a particular geographical region

4

My Approach: Policy Driven Privacy Management System
Mechanisms for specifying privacy policies, information requests, and credentials. Assists user with managing of his private information. Introduces information classification model suitable for nomadic environment. Puts control over information sharing into user's hands.

Roadmap
Project Objectives Background Motivation Methods Survey Requirements & Challenges Method Evaluation & Testing Achievements Conclusions Supplementary Slides

5

Requirements & Challenges
The requirements for protecting the shared personal information within nomadic environment includes:
Authorisation and access control Keeping the revealed personal information to a minimum Binding personal information to pseudonyms Protecting its confidentiality from eaves-droppers. eaves-

Roadmap
Project Objectives Background Motivation Methods Survey Requirements & Challenges Method Evaluation & Testing Achievements Conclusions Supplementary Slides

6

Why a MAS-Based Privacy Framework?
Agents are Autonomous, social and reactive. Rich communication (using protocols, dialogues, knowledge exchange) Broker agent can support pseudo-identities and anonymisation. Agents can integrate heterogeneous services such as GIS, personalisation, nomadic users and service providers Take the load of the processes running on mobile device.

PDPMS Components
Data Model
An extended version P3P Base Data Schema, to support spatial content handling. User-defined set of rules. Usersupports both role based and lattice based access models. information required to authenticate service. private information request based on the data model.

Preference Policy Access Model Token

Request

7

Agent Interaction
Client Broker Info Request Token Request Token Inform Service

Policy Request Policy Inform Notification Request Notification Inform Assets Request Assets Inform

Evaluation Reject

Result Inform

PDPMS Architecture

8

Policy Evaluation
Policy evaluation is done by evaluating Request, token and preference policy. preference There three possible outcomes of the evaluation: reject, reveal and notify.
1. 2. 3.

reject(x)=> ~match(x, Assets) v ~match(x,Token) notify(x)=> match(x, Assets) ^ notifyme(Client, Assets) reveal(x)=> match(x, Assets) ^ match(x,Token)

Rules are executed based on priority of the effect type such that that Reject is first priority Notify has second priority Reveal has third priority

User Interface
The client interface was implemented with Java 1.18 AWT. This has a limited graphical library with only simple colors

9

Roadmap
Project Objectives Background Motivation Methods Survey Requirements & Challenges Method Evaluation & Testing Achievements Conclusions Supplementary Slides

PDPMS solution to reduce the P3P vulnerability HCI problems

System Evaluation: Analysis of P3P against PDPMS
The interface allows the user to set the preference policy using simple actions.

Lack of security
Requires authentication of the service. The user sets what data each service can have access too.

Suitability for location information
supports location based information. The user can set the preference rules giving different precision to different services.

10

System Evaluation
Questionnaires given to 32 people to find evaluation target group
male, aged 20-39, have tried a PDA, surf the internet and 20buy items online. Concerned about their privacy, find it difficult to set privacy settings, do not read service policies. Interested in mobile services and would least likely to give out their credit card details. Would be interested in a user centered privacy system.

System Evaluation
20 people selected. One person at a time in quiet room without distractions. I took the role of the service provider the user was the client on the PDA. Different scenarios were acted out allowing the user to use the system. Usability test Questionnaire was then given. Each question hade score of 1-5, 5 being the highest. 1-

The results show that overall the system did well. Easy to understand and use. Modifications were made in the areas the system didn't do well in.

11

System Testing
Aim: To find the time taken for PDPMS system to run. Most importantly the time taken to evaluate the service request. Constant variables Laptop specifications & PDA specifications Wireless network: 11Mbps excellent connection. Laptop and PDA process: all non essential process closed. Both connected to power supply. Distance PDA from laptop kept constant. Assets & Requested data stayed the same. Variable being changed The amount of rules that get executed for the service request. The different types of rules.

System Testing
It can be seen that the system process are instantaneous. Interacting with the client agent has a time delay. Especially notification
PDPMS Execution Time breakdown using 2 Rule with notify

Time Taken (Ms)

10 0

Request token Rule evaluation Receive Client assets

10

10

50

40

Receive token Request notification Send service assets

30

100

10

Request policy Receive notification

50 150

10

Receive policy Request Client assets

40 200

10 250

12

System Testing
As the amount of rules being processed increases the evaluation time increases slightly. Would have liked to compare with P3P.
Evaluation Time With Diffrent Amount Of Rules

5

4 Rules Evaluation Reject 3 Evaluation Notify Evaluation Reveal 2

1

0

5

10

15

20

25

30

35

40

45

Time(Ms)

Roadmap
Project Objectives Background Motivation Methods Survey Requirements & Challenges Method Evaluation & Testing Achievements Conclusions Supplementary Slides

13

Achievements
P3P vocabulary and data model. Access models Designing and implement a complex evaluation engine using priority priority levels and logic. Mobile device programming, interface design and overcoming hardware hardware limitations. Dealing with location data (coordinates, precision and time). The use of different development tools: Jade, IBM Policy Editor, Borland personal Java Editor , Prot�g� 2000, XML Spy and UML plug-in. Prot� plugGained a great awareness of the privacy risks associated with web and web mobile services currently being faced.

Roadmap
Project Objectives Background Motivation Methods Survey Requirements & Challenges Method Evaluation & Testing Achievements Conclusions Supplementary Slides

14

Conclusions
Agents proven to be an effective solution to support mobile users within nomadic environment While usage on pseudonyms protects user's identity, in some cases sharing is necessary. PDPMS was introduced to overcome this issue.

Future Work
The main improvements of the system are generally concerned with adding extra functionality to it. � Implement mechanism for mutual Client/Broker Authentication. � Design and implement interoperability mechanisms enabling dealing with multiple credentials types. � Improve scalability of the system.

15

Acknowledgements
I would like to thank Dr Stefan Poslad whom has supervised this project and has provided me with guidance and support. I would like to gratefully acknowledge the enthusiastic supervision of supervision Leonid Titkov during this work. His guidance and support has been been invaluable to the success of this project. Also the kind help of Faheem Undre for helping me configure the software.

Roadmap
Project Objectives Background Motivation Methods Survey Requirements & Challenges Method Evaluation & Testing Achievements Conclusions Supplementary Slides

16

Access Level
A privacy access control model was created which supported both role based and lattice based access model. This allowed both entity groups and single entities to be given an access level. GenericGIS GenericGIS R1 R2 R3 R4 R5 Educational Personal R1 R2 R3 R4 R5 Commercial 1 2 3 4 5

The columns represent user groups the rows represent the level of access. Each cell contains rules. Rules of contain three main components: asset, effect and condition. In our case the action is always going to be `permit or deny'. The assets access levels and rules will be different depending on the user group. deny' For example: If the service has been assigned to a level 3 of the GIS group, levels 3,4,5,6 will be accessible unconditionally (Condition of all rules == null). Levels above will only be accessible if a particular condition is true. In accessible user group is unknown then the entity (service) will be assigned to Generic.

Evaluation Process
Evaluation process: �Validates the requester(service) Token Checks the validity period if it has expired expiryDate(X,T) > currentDate Checks the request ID matches the Token ID match(T.ID,X.ID) �Collects list of privileged information available for service gets service entity type(commercial, GIS, education or personnel) entityType(X) gets clearance level from clearance database clearanceLevel(X) checks clearance level with service clearance level clearanceLevel (X) == clearanceLevel(rule) gets generic privileged assets based on service assets(entityType) for every rule get effect type (notify, reveal or reject) effectType(rule) adds or removes privileged assets based on rule privilegedAssetListAdd(asset) privilegedAssetListRemove(asset) � Rules are executed based on priority of the effect type such that Reject is first priority Notify has second priority Reveal has third priority �Validate requested data with compiled list of privileged data get service request dataRequest(X) check service request with privileged assets based on priority if a request is not included in a privileged assets list then reject reject request (Ax) reject(x)=> ~match(x,Rule-Assets) v ~match(x,Token) ~match(x,Ruleif a request includes data in the notify assets list then notify user (Ax) notify(x)=> match(x,Rule-Assets) ^ notifyme(Client,Rulematch(x,Rulenotifyme(Client,RuleAssets) if a request includes data in the privileged assets list then reveal reveal assets (Ax) reveal(x)=> match(x,Rule-Assets) ^ match(x,Token) match(x,Rule-

17

Challenges in designing mobile services
1. 2. 3. 4. Loss of network availability: Mobile devices do not have coverage everywhere at all times. There are coverage plenty of places - including remote locations, inside buildings and under bridges - where coverage drops off. Limited Screen Size: Small screen size will limit the amount of information a user can view on the device, introducing the risk of information overflow. Small multifunction key pads: entering data on device is difficult and slow. difficult Limited Resources: Large documents may be unsuitable for processing on a mobile device. They may processing require more working memory to store than is available to the device or more processing power to parse device than is feasible to deal with them in real time. Latency: Wireless connections are slow, resulting in long delays between the time a user requests information and the time it takes to actually receive it. The typical bandwidth of current and emerging typical WAN services, even 2.5-generation networks, is measured in tens of kilobits per second, sometimes 2.5peaking above 100 Kbps.

5.

Implementation Issues
While implanting the PDPMS I was faced with many problems due to the fact that I was implementing the system for mobile devices (PDA). Here are some of the problems faced and how they were overcome: � Using JADE with Java Server Pages (JSP) During the fist stages of getting to know the Jade environment and setting up the complete system. I had problems getting Jade and and JSP to work together due to the fact of the complex steps taken in setting up the system. There were many Class taken paths to set up and library packages to add. I overcome the problem by setting up the system one step at a time making problem sure the functions being added worked. It was found that I used the wrong class path for the JSP. � Building an suitable interface Many issues came up when implementing the interface. The main being that I had a lot of data to fit onto a small screen. This being was overcome by trial and improvement, by grouping data into different sets allowing the user to slide through the different different sets. � Running Java code on PDA The PDA did not support Java 1.4 it only supported Java 1.18. I had to make sure that I did not Import any classes not supported by Java 1.18 and the Client agent and interface compiled with Java 1.18. This led me into having to program the compiled interface using AWT which only supported very basic interface functions and lose out on using Java Swing. functions � Working in a wireless environment When running the system I had to be in a wireless network. The PDA had to be able to see the computer. Many times the PDA network fell cutting the connection. The IP address would change, so I would have to edit the start-up file with the new IP change, startaddress. I managed to overcome these problems by running the system while the PDA was synchronised with the system computer. � Interface and agents communication I had problems making the interface pass the agents the information needed at runtime. This was overcome by making the information interface write to text file and the agent read the text file when needed. when

18

Subscribe
x