Mobile Single Sign On System
Souheil Lazghab
The security protocol should secure:
First, the Bluetooth communication between the PICDEM FS USB Demo board and the mobile phone device.
Second, the access credentials stored in the RMS residing on the mobile phone.
Third, provide a secure authentication mechanism between the user and the sso MIDlet.

To achive these goals:
RC4
SHA-1
AES-128
Problems!
The limitation of the processing power and storage size of the PICDEM FS USB Demo board device.
The limitation of the development environment for both Java and embedded system.
Conclusion
100 % security does never exist in any system.
The security protocol offers a good security level to the SSO prototype.
The degree of security could be ameliorated if it will be included early in the design process.

Single Sign-On 101: Beyond the Hype
What SSO Can and Can’ t Do For Your Business
Introductions
Diana Kelley, Baroudi Group
diana@baroudi.com
Ian Poynter, Security Consultant
ianpoynter@yahoo.com
Outline
Definitions
Business Requirements
SSO Technologies
Authentication Methods
SSO Case Studies
Definition
Single Sign-On
Fantasy
One Password For Everything!
Reality
Most Systems And Applications Already Have Their Proprietary Login Functionality
Reduced Logins For Discreet Systems
Corporate Systems
Shared Intranet/Web Applications
Web Logon Aggregators
Business Requirements
Is There A Problem Here?
Mushrooming Passwords
Need For Re-use
Sticky Note Password Cache
Unencrypted Text Files On Laptops and PDAs
Business Requirements
Deceptively Intuitive
Reduce Costs
Increase Security
Increase Efficiency
Increase Convenience
My Boss Told Me I Have To
Business Requirements
Be Honest About the Cost / Benefit Analysis
Use Hard Numbers
What Does it Cost to Reset a Password?
How Much Time is Spent Logging into Multiple Systems Each Morning?
What is The Real Cost of Integration?
Will Additional Authentication Methods Need to be Purchased?
Business Requirements
Be Honest About the Cost / Benefit Analysis
Don’ t Forget the Ease of Use Factor
Consider Training for Administrators and All Users
QA and Versioning Can Increase TCO
Business Requirements
Think About the Inside and the Outside
Multiple User Populations Can Increase Costs
Tiered Authentication Levels
At a Minimum Need Secure Password Selection Training for Everyone
Business Risks
Single Point of Failure
Denial of Service/Lack of Availability
Stolen Credentials via Insecure Implementations
Overly Ambitious Projects
Physical and Network
Complicated Procedures
n-factor Authentication
Square Pegs in Round Holes
Business Risks
Failure to Consider the Legacy
OS/390, AS/400, Custom Client/Server Applications, RADIUS
Failure to Consider Regulatory Requirements
Financial Services and GLBA
Health Care and HIPAA
Content Providers and COPPA
International Businesses and EU DPD
Authentication Methods
Declaring and Proving Who or What You Are
Sure, Signing on Once, but What With?
Becomes an Even Larger Question with SSO Because More Systems are Involved
Authentication Methods
Have, Know, Are
Tokens, Passwords, Fingerprints
Single vs. Multi
Authentication Methods
Passwords
One Time Passwords
Tokens and SmartCards
PKI
Digital / Machine Fingerprints
Biometrics
Authentication Protocols and Technologies
Dial-In Users and Wireless (802.1x)
RADIUS
S/390 Mainframes
RACF, ACF2, CA Top-Secret
Unix
PAMs (Pluggable Authentication Modules)
Windows
GINA, Kerberos, NTLM
SSO Technologies
Traditional Single Sign-On
Password Synchronization
Authentication Platforms
Web Logon Aggregators

NB: Convergence Between Traditional SSO and Authentication Platforms
SSO Technologies
Traditional Single Sign-On
Allows a User to Login Once, Using a Single Authentication Method to Gain Access to Multiple Hosts and / or Applications
May Also Provide Access Control / Authorization Features
Authorization policies restrict which applications or systems a user has access
And what the user can and can’ t do on these applications and systems
SSO Technologies
Traditional Single Sign-On
Not an Entirely New Concept
Kerberos and Kerberized
RADIUS and Radiized
Traditional SSO: How It Works
Authenticate Once To Access Many
Login Credentials (ID And Authentication) Usually Stored Locally
Transparently Presented to the System or Application When Needed
Traditional SSO: How It Works
Single Credential for All Systems
Kerberos Model
Multiple Credentials
Required for Most Heterogeneous Environments
Traditional SSO: How It Works
APIs And DLLs
Write the SSO Authentication into Each Application or System (compare to: Radiized)
Or Use Replacement DLLs
Scripts
Pieces of Code on the Client That Manage the Login Procedure to Multiple Systems
Cookies
For Web Applications Only
Traditional SSO: Pros and Cons
Pros
Very Easy to Use
Reduces Support Costs
Reduces Logon Cycles
Cons
Integration of Legacy Can Be Expensive and Time Consuming
Single Point of Attack
Scripting Solutions Often Lead to Storage of Passwords And IDs on the Client
Traditional SSO: Business Fit
Good Business Fit for
Companies That Want to Simplify the User Experience
Companies That Need to Reduce the Login Cycle
Traditional SSO: Brand Examples
IBM/Tivoli Global Sign-On
Netegrity SiteMinder
RSA ClearTrust (formerly Securant)
SSO Technologies
Password Synchronization
Manage Passwords Across Platforms and Systems
Keeps Same Password So User Only Needs to Remember One
When User Changes Her Password, Synchronization Server Automatically Updates User Password on All Available Systems or in the Central Repository Server
Password Synchronization: How It Works
Distributed
Agents Automatically Reset Passwords on Applications and Systems
Centralized
All Authentication Requests Are Forwarded to a Central Server
Password Synchronization: Pros and Cons
Pros
User Has Only One Password to Remember
Usually Fairly Easy to Implement
Help Desk Can Reset Passwords to All Systems From Single Console
Cons
Does Not Reduce the Number of Logons
Only Supports Password Authentication
Password Synchronization: Business Fit
Good Business Fit for
Companies That Only Use Password Authentication
Companies That Don’ t Need to Reduce the Login Cycle
Password Synchronization: Brand Examples
PassGo, InSync (formerly Axent/Symantec)
Courion, Password Courier
SSO Technologies
Authentication Platforms
Provide a Central Point of Management for Multiple Authentication Schemes
Users Authenticate To A Gateway Using Any Combination of Authentication Methods
Smartcards, PKI, Biometrics etc.
Supports Multi-layer Authentication Policies
Authentication Platforms: How It Works
Abstracts the Authentication Layer to an Authentication Gateway
All Users Login to this Gateway
Gateway Determines Level / Type of Authentication that is Required
Authentication Platforms: Pros and Cons
Pros
Eases Integration With Abstracted Authentication Layer
Support for Most Authentication Factors
Cons
Does Not Reduce Number of Logins, Unless SSO is Embedded in the Authentication Platform
Single Point of Attack / Failure
Denial of Service
Authentication Platforms: Business Fit
Good Business Fit for
Enterprises with Hierarchical, Complex Authentication Requirements
Companies using N-factor Authentication Solutions
Organizations with Regulated Security / Privacy Requirements
Financial Institutions, HealthCare, Government Agencies
Authentication Platforms: Brand Examples
Bionetrix Authentication Server
Novell Modular Authentication Service (NMAS)
ActivCard (formerly Ankari)
Trinity Server with SSO Functionality
SSO Technologies
Web Logon Aggregators
One Login, Access Multiple Sites
User Logs into Aggregator Software or Site at Beginning of Session
All Subsequent Logins to Web Sites Visited Are Handled Transparently
Web Logon Aggregators: How It Works
Credentials Are Cached Either
Locally via Cookies
On Server via State Mechanism
Automatically Presented to Sites as Needed
Web Logon Aggregators: Pros and Cons
Pros
Ease of Use
Streamlines Web Experience
Cons
Web Only
Sites May Need to Opt In
Outsources Trust to 3rd Party
Loss of Control
Web Logon Aggregators: Business Fit
Good Business Fit for
Companies Providing Web Interfaces to Customers or Employees
Home Users Who Want to Streamline Their Web Experience
Web Logon Aggregators: Brand Examples
.NET / Passport
Liberty Alliance (in process)
Yodlee
Account Aggregator
Case Studies
Example Architectures From the Real World
Identifying Characteristics Have Been Changed Where Needed to Protect Client Confidentiality
Case Study 1
Large US Insurance Company
Project: Reduce òWake Up’ Time for Internal Personnel and External Agents by Integrating Login Function to Multiple Back and Front Ends
Case Study 1
Points for the RFP
State Business Requirements (cf. previous slide)
Provide Hard Numbers
Example: Time Goal for Reduced Wake-up Time
Time and Cost Estimates
Don’ t Forget QA Before Roll Out
Include Support and Training

Case Study 1
Points for the RFP
Technical Requirements
All Internal Logins Triggered by NT Login
External Users Credentials Stored in LDAP Directory
Login Support For
S/390 with RACF
Oracle Database
RADIUS for Remote Agents
Custom DOS-Based Money Transfers with SecurID
Custom Web Applications

Case Study 1
Proposal from Selected Vendor
Hybrid Technical Solution
Internal Users
Custom GINA
LDAP Support
Link to Traditional SSO for Web Application Logins
Trigger for Users That Needed to Access SecurID Protected Solutions
External Users
Traditional SSO for Web Application Logins

Case Study 2
International Consulting Firm
Project: Link Multiple Intranets, Distributed Around the World, for Secure Access to Internal-Only Information Sharing And Project Collaboration
Case Study 2
Points for the RFP
State Business Requirements
Provide Hard Numbers
Example: Define Secure Access
Type of Authentication
Encryption Requirements
Roaming User Needs
Time and Cost Estimates
Don’ t Forget QA Before Roll Out
Include Support and Training
Case Study 2
Points for the RFP
Technical Requirements
Internationally Distributed Web Servers Across Multiple Domains
Custom Web Applications
Netscape, ISS, Apache Web Servers
Mac And Windows Clients

Case Study 2
Proposal from Selected Vendor
Netegrity SiteMinder with Installation Services
Summary
Know the Business Requirements
Complete a Cost-Benefit Analysis
Set Reasonable Goals
Investigate the Available Technologies
Investigate the Vendors
Match Requirements to Technology
Plan: Create an RFP and Architecture
Prototype, Build, Test, Train, and Deploy
Throw Away Those Yellow Sticky Password Caches!

Notarized Federated Identity Management for Web Services
Michael T. Goodrich Roberto Tamassia Danfeng Yao

Outline
Introduction to federated identity management (FIM)
Notarized federated identity management model and protocol
STMS and its application in notarized FIM
Identity theft and proposed countermeasure

Motivation
Digital identity management (DIM)
To protect sensitive personal information in on-line transactions
Users tend to choose weak passwords
As the number of passwords to remember increases
Single sign-on (SSO) and federated identity management
A user logs in only once to a site, then is automatically authenticated
Cookie-based SSO approach (used by Microsoft Passport)
Does not support cross-domain single sign-on
Approach using cryptographic-enabled assertions
Secure Assertion Markup Language (SAML)
SSO and FIM
Provider model in SAML
Specially designed for general cross-domain single sign-on
Identity Provider (IdP)
IdP is the system that asserts information about a subject
Service Provider (SeP)
SeP is the system that relies on the information supplied to it by the identity provider
Relying party
Used in Liberty Alliance Federated Identity Management for single sign-on

Identity Federation
Websites of different admin domains need to trust each other’s access control verdicts
Circle of trust
Issues
How to securely maintain the identity federation when members may leave or join the circle of trust?
How to provide separation of IdP and SeP for the privacy protection of the user?
These questions have not been extensively studied
Existing SSO solutions assume pre-established trust relationship among providers
IdP and SeP communicate to each other during SSO process

Notarized Federated Identity Management
We introduce a trusted third-party, called notary server
The notary information of an assertion provides its trustworthiness
Distributed implementation of the notarized federated identity management framework using STMS
We also present a robust authentication protocol that is resilient against identity theft attacks, using identity-based encryption

Notarization
Notary server
Third party trusted by identity providers and service providers
Notarizes assertions submitted by identity providers
Answers queries on notarized assertions asked by the service providers
Prevents direct communication between the identity provider and the service provider
Notarized assertion
Generated by identity provider
Authenticated by notary server
Trusted by service provider
Security Requirements
Security
A polynomial-time adversary cannot forge a valid notarized assertion
Secrecy
Notarized assertion should not leak sensitive information of a user to unauthorized parties, including the notary server
Accountability
Identity providers should be held accountable for the assertions that they generate; and for any unauthorized information disclosure about the user
Overview of Notarized FIM
Protocol Design Challenges
How to protect the identity of the user from the service provider?
How to blind the content of an assertion from the notary server?
How to unblind by the service provider?
How to hold the identity provider accountable for unauthorized disclosure?
Our solution uses lightweight crypto primitives
hash function
XOR
symmetric encryption
digital signature
Implementation of Notarized FIM Protocol
Two public parameters P1, P2
The user and SeP compute a session_ID N
XOR each party’ s random string
The user requests IdP to generate assertions
Signed request to IdP for accountability
IdP blinds an assertion
Computes the hashed_ID h = Hash(N, P1)
Generates an assertion S using h for index
Computes the blinding factor K = Hash(N, P2)
Encrypts S with K using a symmetric encryption scheme
Blinded assertion is called S’
IdP submits an assertion to the notary server
Sign S’ with its private key
Notary server stores S’ , and stores the signature for accountability

Implementation of the notarized FIM protocol (Cont’ d)
The user queries for an assertion of a hashed_ID
Computes the hashed_ID h = Hash(N, P1)
Queries the notary server for assertions of h
Notary server notarizes an assertion
Retrieves the blinded assertion S’
Signature approach: Signs S’ with its private key
STMS approach: computes the proof for S’
The user unblinds and verifies an assertion
The user verifies the notary information
Computes the blinding factor K = Hash(N, P2)
Decrypts S’ with K and obtains S
Detect unauthorized information disclosure
The service provider unblinds and verifies the assertion
Privacy and Accountability
Notary server realization: STMS
The Secure Transaction Management System [Goodrich, Tamassia et al.] implements an authenticated dictionary
STMS in Notarized FIM
Outline of the talk
Introduction to federated ID
Provider model in SAML
Notarized federated identity management model and protocol
Identity theft and countermeasure

An authentication protocol robust against identity theft
Identity theft causes
Private information insecurely stored and entered
On credit card company’ s computers, in DMV’ s cabinets, in your bank, in your trash can
How to proactively control the release of your private information?
Secure storage
Prevent dumpster diving
Safe disclosure
Prevent shoulder surfing
With minimal changes to current financial and administrative infrastructure
Existing approaches
Centralized processing
Heavy-weight Zero-knowledge proofs
Our approach
To design a lightweight authentication protocol using identity-based encryption

Related work
Anonymous credentials [Camenisch Lysyanskaya 01] [Camenisch Herreweghen 02]
Federated ID management models [Camenisch et al 05] [Bhargav-Spantzel Squicciarini Bertino 05] [Pfitzmann Waidner 03]
Web service framework [Bonatti Samarati 02]
Identity theft detection [van Oorschot Stubblebine 05]
Identity-based encryption [Boneh Franklin 01]
SAML [OASIS], WS-Federation [IBM et al]
Conclusions
Notarized federated identity management is a solution for establishing trust in web services
Notary server provides an anchor of trust
Notarized FIM protocol provides accountability, privacy, and secrecy for participants
IBE-based credentials and exchanges hold promises for identity theft solutions
Acknowledgements
David Croston at IAM Technology, Inc

Generations of the model

Instructions for First Time Single Sign On Users

Go to HYPERLINK “https://sso.tamu.edu” sso.tamu.edu . The screen will look like this:

First time SSO users select the “New Employees – Set up your password” link
Enter your UIN and SSN and click “Next”. (If you do not know your UIN, please contact HR at 254-968-9128)
Enter your Date of Birth and click “Next.”
Enter your ADLOC and click “Next.” (If you do not know your ADLOC, please contact HR at 254-968-9128)
Enter your email address and click next. (This is for notification purposes and does NOT have to be a Tarleton email account)
Select a “Secret Question” and enter your “Secret Answer.” Be sure you can remember this answer exactly later. It is case sensitive. Then click “Next.”
Create your password by entering and re-entering the password you choose. This password is also case sensitive.
Click ”Next.”
Read the User Agreement. Type in your UIN and click “Agree.”
From the SSO Menu, you may choose HRConnect, LeaveTraq, TrainTraq, iBenefits or TimeTraq.

Using Technology to Bridge the Chasm of Quality in Healthcare
Facts Driving SDCMS Foundation Concerns
Medical bills = #1 cause of personal bankruptcy in the U.S
U.S. has 45 million uninsured and 40 million underinsured
U.S. spends 1.5-3X more per capita as countries with universal healthcare and yet the outcomes are no better
Healthplans collectively profited $4 billion last year
Patient are shouldering more of the costs of healthcare with deductibles and copays increasing & benefits decreasing
Plans are dropping out of non-profitable markets.
Corporate corruption / Obscene executive salaries
Medical errors have not decreased despite cost increase
VA-like bidding would yield Medicare savings of $1 billion/yr
On average, 30% of premiums are not spent on patient care
SUMMARY OF FOUNDATION PRIORITIES

Improve access to quality medical care
Increase the quality of health care
Improve the health of San Diego County residents
Improve patient safety and reduce medical errors
Improve the coordination and timeliness of care
Improve access to all information necessary to make the best decisions for patients at the point of care
Improve health literacy
Help ALL physicians in the county achieve these goals
Physician Goals for Technology

Improve quality, service, and safety of medical care
Increase the efficiency of workflow
Secure single sign on tool to import ALL data to the point of care in an easy to read integrated format
Clinical guidelines and decision support
Continuing education
Patient risk assessment
Community continuity of care records & registries
Automated patient reminders
Eligibility/Benefits/Claims verification
e-Rx: eliminate handwriting error & adverse reactions
Maintain privacy and confidentiality

Barriers to MD Adoption of Technology
Cost: Most of the Savings Accrue to the Healthplans
History of false starts
Time: Physicians are swamped with regulations (HIPAA)
Lack of standards and interoperability (HL-7)
Privacy and Security: Fear of profiling
Stakeholder commitment: Silo mentality & Competition
Healthcare industry in general is slow to change

Physicians are technophiles and recognize the value of Technology in Patient Safety and Quality Improvement

HIPAA Health Insurance Portability and Accountability Act
Administrative Simplification
Common interchange structure
Standard employer/provider identifier
Electronic signature with specific transactions
Data transmission for benefits/claims

Information Privacy
Rights of individuals to records
Authorized uses and disclosures of information
Requires identity authentication of requestor/provider of health records

SureScripts = single portal to all SD Pharmacies Increases the efficiency, quality and safety of prescribing
Based in Alexandria,VA
Formed in August 2001
Formed by:
NACDS
NCPA
Strategic industry alliance to:
Promote true electronic connectivity between physicians and pharmacies
Enable widespread prescribing connectivity (local and national)
Reduce medical errors
Current System Plagued by Serious Quality and Patient Safety Problems
Patient safety
*1.5% to 4.0% of Rx’ s have errors with potential for serious patient risk
Quality of care
*1.1 billion scripts never filled
* Patient satisfaction issues
Potential Savings: $ 2 billion / yr
Impact on productivity
*Physician time:1 hour per day
*Pharmacy: 4 hours per day

Illegible handwriting
Phone tag and fax tag
Patient waiting in the pharmacy

Predictors of Health
Racial +/- Ethnic Group
Income
Education Level
Literacy
Income
Employment status
Age
Geographic Location of Home

Consequences of Poor Health Literacy
Lack of compliance with medical regimen including missed appointments
Medication errors and medication noncompliance
Late diagnosis
Limited preventive care
Malpractice suits

Physicians agree that one of their most important tasks is PATIENT EDUCATION
HOWEVER
more than half of our patients are unable to understand
PHYSICIAN COMMUNICATION