Sousa SAM Presentation

326 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
326
On SlideShare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Sousa SAM Presentation

  1. 1. Challenges and Architectural Approaches for Authenticating Mobile Users João Pedro Sousa George Mason University Fairfax, VA Workshop on Software Architectures and Mobility
  2. 2. authentication of mobile users what is the problem? what are solutions? <ul><li>requirements </li></ul><ul><li>media library: verify that the user has access </li></ul><ul><li>smart space: verify that the user has access </li></ul><ul><li>display: verify that PDA is intended remote control </li></ul><ul><li>media library: verify that display is intended output </li></ul><ul><li>... establish secure channels </li></ul><ul><li>example: user wants to </li></ul><ul><li>access media library for which has membership </li></ul><ul><li>stream media to wall in lounge </li></ul><ul><li>use PDA as remote control </li></ul>media library
  3. 3. verification vs. selection two related but distinct problems <ul><li>verify properties </li></ul><ul><li>identity </li></ul><ul><li>membership </li></ul><ul><li>trustworthiness uncompromised platform </li></ul><ul><li>demographics customer segments </li></ul><ul><li>mechanism: authentication </li></ul><ul><li>answer: yes/no </li></ul><ul><li>predict QoS properties </li></ul><ul><li>success/failure </li></ul><ul><li>latency </li></ul><ul><li>integrity </li></ul><ul><li>confidentiality... </li></ul><ul><li>mechanism: trust management recommender systems </li></ul><ul><li>answer: quantitative assessment </li></ul>
  4. 4. outline <ul><li>classes of the verification problem </li></ul><ul><ul><li>U ser A ccess to S ervices </li></ul></ul><ul><ul><li>G roup A ccess to S ervices </li></ul></ul><ul><ul><li>L ink P eers </li></ul></ul><ul><li>architectural patterns </li></ul><ul><ul><li>challenges </li></ul></ul>remote personalized service group/public services
  5. 5. UAS U ser A ccess to S ervices <ul><li>server URL </li></ul><ul><li>user credentials </li></ul><ul><li>telnet </li></ul><ul><li>PC anywhere </li></ul><ul><li>e-banking </li></ul><ul><li>e-payments </li></ul><ul><li>... </li></ul>remote personalized service personal/local device + connectivity <ul><li>verify </li></ul><ul><li>identity </li></ul>
  6. 6. GAS G roup A ccess to S ervices <ul><li>proof of membership/trustworthiness </li></ul><ul><li>demographics/interests info </li></ul>group/public services <ul><li>(personal +) local devices: </li></ul><ul><li>membership services (library...) </li></ul><ul><li>e-voting </li></ul><ul><li>services in smart spaces </li></ul><ul><li>e-commerce </li></ul><ul><li>... </li></ul><ul><li>verify </li></ul><ul><li>membership </li></ul><ul><li>trustworthiness uncompromised platform </li></ul><ul><li>demographics </li></ul>k-anonymity
  7. 7. LP L ink P eers <ul><li>personal devices: </li></ul><ul><li>social exchange/chatting </li></ul><ul><li>file sharing </li></ul><ul><li>media streaming </li></ul><ul><li>remote control </li></ul><ul><li>... </li></ul><ul><li>verify </li></ul><ul><li>demographics /interests </li></ul><ul><li>membership /identity </li></ul><ul><li>co-ownership </li></ul>
  8. 8. credentials play key role many types with pros and cons <ul><li>UAS: prove identity </li></ul><ul><li>GAS: prove right to access </li></ul><ul><li>LP: prove co-ownership </li></ul><ul><li>what you know </li></ul><ul><li>passwords </li></ul><ul><ul><li>easy to change /keep private </li></ul></ul><ul><ul><li>hard to keep track of </li></ul></ul><ul><ul><li>disruptive to provide </li></ul></ul><ul><li>zero-knowledge proofs </li></ul><ul><ul><li>doesn’t reveal what you know </li></ul></ul><ul><ul><li>very complex to provide </li></ul></ul><ul><li>who you are </li></ul><ul><li>fingerprints, face, voice, gait recognition </li></ul><ul><ul><li>very easy to provide </li></ul></ul><ul><ul><li>false positives/negatives </li></ul></ul><ul><ul><li>hard to change /keep private </li></ul></ul><ul><li>what’s in your vicinity </li></ul><ul><li>where you are: secure spaces </li></ul><ul><li>what you carry: smart cards, one-time pwd </li></ul><ul><ul><li>may preserve anonymity </li></ul></ul><ul><ul><li>feasible to change /keep private </li></ul></ul><ul><ul><li>may be hard to keep track of </li></ul></ul>
  9. 9. outline <ul><li>classes of the verification problem </li></ul><ul><ul><li>User Access to Services </li></ul></ul><ul><ul><li>Group Access to Services </li></ul></ul><ul><ul><li>Link Peers </li></ul></ul><ul><li>architectural patterns </li></ul><ul><ul><li>challenges </li></ul></ul>
  10. 10. traditional authentication addresses UAS WS server uid ->ACL issuers tickets issuer uid ->pwd Needham-Schroeder protocol tickets protocol access protocol <x> encrypted text uid, URL <tix, uid> <tix, uid> <ul><li>server URL </li></ul><ul><li>user credentials </li></ul>
  11. 11. traditional authentication conceived to protect servers <ul><li>reveals credentials & intention to communicate with specific server before issuer is authenticated </li></ul><ul><li>may have to trust shared WS </li></ul><ul><li>implicitly trusts server </li></ul>WS server uid ->ACL issuers tickets issuer uid ->pwd <ul><li>server URL </li></ul><ul><li>user credentials </li></ul>
  12. 12. LP is increasingly popular for mobile devices <ul><ul><li>short range radio: Bluetooth... </li></ul></ul><ul><ul><li>line of sight: infra-red </li></ul></ul><ul><ul><li>co-location: shake </li></ul></ul>local connector wide-area connector ownership <ul><li>applications </li></ul><ul><li>media sharing/streaming </li></ul><ul><li>remote control </li></ul>dev dev dev peers dev peers
  13. 13. LP is used in P2P systems to establish a secure link local connector wide-area connector ownership <ul><li>local area networks (with free connectivity) </li></ul><ul><li>peers may establish secure link while hiding identity from others </li></ul><ul><li>no need for central authority </li></ul><ul><li>peers need to know each other beforehand (off band) </li></ul><ul><li>authentication of users implied by ownership ( what you carry ) </li></ul>dev peers dev peers selection (trust management) is arguably just as relevant as authentication in P2P systems
  14. 14. LP combined with UAS/GAS for wide-area/paid connectivity <ul><li>peers (service consumers/providers) and carriers may each have their own security policies </li></ul><ul><ul><li>multilateral security (telecom) </li></ul></ul><ul><li>for billing, prior to LP users authenticate with carriers </li></ul><ul><ul><li>UAS for personalized billing </li></ul></ul><ul><ul><li>GAS for using certified e-currency (UAS with broker entity) </li></ul></ul>dev peers dev peers
  15. 15. <ul><li>in membership-based spaces, users’ PDA: </li></ul><ul><ul><li>starts secure UAS to certificates issuer </li></ul></ul><ul><ul><li>obtains anonymous one-time certificates </li></ul></ul><ul><ul><li>reveals membership to ambient (k-anonymity) </li></ul></ul><ul><li>ambient cannot track identity or usage patterns </li></ul><ul><ul><li>may request identity of malicious users to cert. issuer </li></ul></ul><ul><li>certificates issuer may track identity and usage </li></ul><ul><ul><li>hence backlash against MS Passport </li></ul></ul><ul><li>zero-knowledge proofs </li></ul><ul><ul><li>do not require third party (cert. issuer) </li></ul></ul><ul><ul><li>limited use due to complexity </li></ul></ul>GAS in shared spaces: users remain k-anonymous ambient services gid ->ACL certificates issuer PDA issuers profiles certificates protocol ambient access identification protocol
  16. 16. <ul><li>in public/commercial spaces, ambient seeks to obtain demographics/interests for targeting info & services </li></ul><ul><li>PDA may release a diff pseudonym at each location (requires autonomous location awareness) </li></ul><ul><ul><li>ambient remembers habits/prefs of regular users </li></ul></ul><ul><ul><li>can’t transfer knowledge across similar spaces </li></ul></ul><ul><li>PDA may release one-time pseudonyms </li></ul><ul><ul><li>PDA remembers habits/prefs of user and releases the ones associated to each type of space/requested service </li></ul></ul>GAS in shared spaces: users remain k-anonymous ambient services gid ->ACL PDA issuers profiles ambient access
  17. 17. UAS in shared spaces appealing and risky <ul><li>users will access personalized services </li></ul><ul><ul><li>may not have the skill or the will to protect PDA from cyber attacks at malicious/unsecure spaces </li></ul></ul><ul><ul><li>compromised PDAs can act as stepping stones to attack personalized services (stored URLs & pwds) </li></ul></ul><ul><li>servers may adjust ACL based on user’s location </li></ul><ul><ul><li>PDA compromised at high-risk location may manifest at location deemed low-risk (and open access) </li></ul></ul>ambient services gid ->ACL PDA issuers profiles server uid ->ACL certificates issuer certificates protocol ambient access identification protocol
  18. 18. UAS in shared spaces PDA may get in the way <ul><li>give users a false sense of security in high-risk spaces </li></ul><ul><li>limiting: users may want to engage local capabilities for accessing remote services </li></ul><ul><li>overhead: remember to carry PDA and charge battery </li></ul><ul><li>may not be justified in trusted spaces </li></ul><ul><ul><li>medical staff moving within a hospital </li></ul></ul><ul><ul><li>corporate campuses… </li></ul></ul>ambient services gid ->ACL PDA issuers profiles server uid ->ACL certificates issuer certificates protocol ambient access identification protocol access protocol
  19. 19. UAS in shared spaces possible without PDA <ul><li>as in traditional authentication malicious space may capture credentials </li></ul><ul><ul><ul><li>replay and piggyback attacks </li></ul></ul></ul><ul><ul><ul><li>space may obtain undue access to personal services </li></ul></ul></ul><ul><li>new risks associated with ubiquitous access </li></ul><ul><ul><li>space may reveal user presence and activity </li></ul></ul><ul><ul><ul><li>threats to privacy and personal security </li></ul></ul></ul><ul><ul><li>if space is not secure enough it may unintentionally facilitate all of the above </li></ul></ul>ambient services uid ->ACL issuers server uid ->ACL certificates issuer certificates protocol <ul><li>server URL </li></ul><ul><li>user credentials </li></ul>access protocol
  20. 20. UAS in shared spaces broaden perspective on protection <ul><li>(as) before </li></ul><ul><ul><li>ACL protects server’s resources against malicious users </li></ul></ul><ul><li>now, also </li></ul><ul><ul><li>protect user’s assets/privacy against malicious spaces/others </li></ul></ul>ambient services uid ->ACL issuers server X ->ACL certificates issuer certificates protocol <ul><li>server URL </li></ul><ul><li>user credentials </li></ul>access protocol
  21. 21. UAS in shared spaces tradeoff access and protection <ul><li>protection: some spaces have trusted admin some don’t </li></ul><ul><li>access: users may be ok with accessing a subset of personalized services at different spaces </li></ul><ul><li>authentication and granting access becomes a multilateral problem </li></ul><ul><li>logging and accountability complements upfront access control </li></ul>server X ->ACL certificates issuer ambient services uid ->ACL issuers ambient services uid ->ACL issuers ambient services uid ->ACL issuers ambient services uid ->ACL issuers
  22. 22. authentication gets complex even in simple scenarios <ul><li>challenge: framework </li></ul><ul><li>help users manage the release of credentials and be aware of access/protection tradeoffs </li></ul><ul><li>works in degraded modes when parts are missing </li></ul><ul><ul><li>role of infrastructure/trusted third parties? </li></ul></ul><ul><ul><li>role of personal devices? </li></ul></ul><ul><li>example: user wants to </li></ul><ul><li>access media library for which has membership </li></ul><ul><li>stream media to wall in lounge </li></ul><ul><li>use PDA as remote control </li></ul>media library GAS local LP remote LP
  23. 23. discussion <ul><li>classes of the verification problem </li></ul><ul><ul><li>User Access to Services </li></ul></ul><ul><ul><li>Group Access to Services </li></ul></ul><ul><ul><li>Link Peers </li></ul></ul><ul><li>architectural patterns </li></ul><ul><ul><li>challenges </li></ul></ul>remote personalized service group/public services
  24. 24. UAS in shared spaces multilateral authentication & trust <ul><li>ambient services facilitate UAS </li></ul><ul><li>each party needs to authenticate and grant access to others </li></ul><ul><li>each party may establish access control policies for others </li></ul><ul><ul><li>personalized server may grant less to user at risky ambient </li></ul></ul><ul><ul><li>a user may trust a space for certain things, but not others </li></ul></ul><ul><li>logging and accountability complements upfront access control </li></ul>ambient services uid ->ACL issuers server X ->ACL certificates issuer <ul><li>server URL </li></ul><ul><li>user credentials </li></ul>ambient services gid ->ACL PDA issuers profiles server X ->ACL certificates issuer dev peers dev peers

×