Towards A User-CentricIdentity-Usage Monitoring System

- ICIMP 2008 -

Daisuke Mashima and Mustaque AhamadCollege of Computing

Georgia Institute of TechnologyGeorgia, USA

Partly Supported by I3P

Outline

• Background and motivation• Limitations of existing approaches• Design goals for user-centric monitoring• Proof of concept in OpenID setting• Conclusion

Background and Motivation

• Increasing threat of online identity theft and misuse– Ranked in the first place for the 7th year in a row in FTC

report

• Prevention is not perfect– Insufficient attention to Site Authentication Image or SSL

icon– Physical theft of a device and removable storage– Malwares– Social engineering– And more…

• Monitoring and detection mechanisms are also required.

Existing Schemes: Fraud Detection Systems

Database

User

Service Provider

Monitoring System

ApplicationServer

No accessNo control

System-specific information is capturedout of user control

• Aim to detect fraudulent activities– Misuse of stolen credit card information– Cellular cloning, theft of calling card or

cellular phone

Limitations of Existing Schemes

• Limited or no user control– Users do not have option to enable or disable

monitoring

• Privacy concern– Users have no choice about what kind of

information is captured and stored on SP

• Lack of generality– System is designed in service-specific way– A dedicated system is required for each site

Design Goals• Users must be able to trust the

monitoring system– Users should be able to choose an entity that they can

trust• Preferably resides on a networked trusted party

– Identity usage must be reliably captured and made available to monitoring system

• Users should have flexible control over the monitoring system– Legitimate users should be able to turn on/off the

monitoring system– Users should have choice about what information is

captured and used for monitoring purpose

Design Goals Contd.

• Monitoring system must offer generality without lowering effectiveness– By using context information, the monitoring

system can handle identity credentials used for accessing general services

– Engaging users closely in the anomaly detection process is important.

• Make users attentive– Push alert or periodic reports

• Provide interface to obtain feedback from user

Overview of Proposed Architecture

Database

User

Service Provider 1

Monitoring System

Service Provider 2

Report Identity Usage

Control viasecure channel

Trusted Third Party

Context Information for Monitoring• Who?

– What platform a user commonly uses to access online services

• OS fingerprinting (nmap, p0f, etc.)• User-Agent in web setting

• To whom?– Identifier of a service provider that a user is talking to

• Where?– IP Geolocation (MaxMind, Delay-based schemes, etc.)– Whois record

• When?– Timestamp of usage– Day of week, week of month, hour of day etc.

Context-based Anomaly Detection

• Time– Significant change in frequency of access– Anomalous access pattern

• Location– Deviation of geographic location in normal

usage pattern– Light-speed contradiction

• Device Fingerprint– Unseen device type in the past

Basic OpenID Architecture

(1) Send ID

(2)Redirect to OpenID Provider

(4)Redirect to consumer with credential

(3)ID Verification

(5)Authentication result

User Service Provider

OpenID Provider

• Authentication credential for OpenID provider could be stolen by phishing

• An adversary could imitate service provider site to retrieve identity credential from legitimate OpenID provider

Proof of Concept in OpenID

(1) Send ID

(2)Redirect to OpenID Provider (checkid_setup mode)

(4)Redirect to consumer with credential

(3)ID Verification and monitoring

(5)Authentication result

[User]- PentiumM 750- 1GB RAM- Windows XP

[OpenID Provider]- Inel Core 2 Duo E6600- 3GB RAM- OpenSUSE10.2- Apache Tomcat 5.5 (Port: 8080)

[Dummy Consumer (SP)]- Inel Core 2 Duo E6600- 3GB RAM- OpenSUSE10.2- Apache 2.2 + CGI (Port: 80)

Open IDProvider

(OpenID4Java)

Config GUI forOpenID Monitor(Java Servlet)

OpenIDMonitor

MonitoringModule

AnalysisModule

InteractionModule

Profile DB

Evaluation: Generality

• Can support any kind of services that rely on OpenID

• No change is required at user side• Can be modified and applied to other

types of systems

Evaluation: Performance• Increase of response time is acceptable

even when multi-user setting.

Network Threads Monitoring Req. / Sec Time / Req.

LAN 1 YES 2.254 0.443

NO 1.782 0.566

CATV 1 YES 1.614 0.612

NO 1.404 0.712

5 YES 4.508 -

NO 3.708 -

Evaluation: Security

• Context-based monitoring makes identity misuse more difficult

• Risk of phishing attack can be mitigated• Periodic reports help shorten the window

of vulnerability• Authentication to control monitoring

system must be isolated from OpenID authentication

Evaluation: Usability

• Pushing usage summary periodically reduces users’ burden

• Context information makes reports or alerts easy to understand

Conclusion• Proposed requirements for user-centric

monitoring and identified design goals• Showed a proof of concept in OpenID

setting and evaluated it• Future work

– Implementation in other types of architecture• Other identity management systems

– GUIDE-ME

• Email-based system

– Explore more sophisticated mechanism for context-based anomalous usage detection

18

Thank you very much.

(mashima@cc.gatech.edu)