1 / 10

Secure Ubiquitous Computing based on Entity Recognition

This workshop delves into authentication and recognition in Ubiquitous Computing, exploring new schemes, requirements, and design considerations to enhance security and privacy in dynamic digital environments. Developed by the Distributed Systems Group of Trinity College Dublin as part of the IST-2001-32486 SECURE project.

raymondn
Download Presentation

Secure Ubiquitous Computing based on Entity Recognition

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Secure Ubiquitous Computing based on Entity Recognition Jean-Marc Seigneur, seigneuj@tcd.ie (Co-authors Stephen Farrell, Christian Damsgaard Jensen) Ubicomp2002 Security Workshop

  2. Table of Contents • Background • Authentication and ubicomp • Authentication subset of recognition • Authentication/Recognition comparison • Ubicomp issues • Requirements for recognition in ubicomp • Design for recognition Ubicomp2002 Security Workshop

  3. Background • Work carried out as part of the IST-2001-32486 SECURE project. • By members of the Distributed Systems Group of Trinity College Dublin. Ubicomp2002 Security Workshop

  4. Authentication and ubicomp • Ambient intelligent environments : roaming digital entities, most likely presence of strangers • Collaboration with most likely unknown entities: enrolment needed for authentication is missing • Identity in absolute terms is less meaningful than recognition of previous interaction to choose whether to collaborate or not • New requirements lead to new schemes, e.g. the Resurrecting Duckling security model [StajanoAnderson1999] • Any identifier can work as long as it allows for referencing the entity involved Ubicomp2002 Security Workshop

  5. recognition authentication Authentication subset of recognition location Kerberos patterns PKI Windows login IP address duckling Ubicomp2002 Security Workshop

  6. Authentication/Recognition comparison Ubicomp2002 Security Workshop

  7. Ubicomp issues • Billions of potential subjects • Continual changein network configuration • Frequent disconnection • An absence of known online servers in many environments • Most likely absence (or unavailability) of administrators • Limited capabilities and power of small smart appliances • Privacy concerns, i.e. “big brother” or ubiquitous surveillance • Physical tamper resistance of smart devices themselves • … Ubicomp2002 Security Workshop

  8. Requirements for recognition in ubicomp • There MUST be no need for on-line contact with a central host in order to recognise an entity, either when first meeting or subsequently. • There MAY be a need for off-line contact with a central host in order to create a recognisable entity. • Recognition schemes MUST take into account that entities have various capabilities and MAY adapt to the capability level of the entity. • A scheme MAY rely on third-parties to assist with scalability. • It MUST be possible to detect return visits, and very hard to fake them (when the same verifier is involved). • In order to mitigate against potential denial of service, entities MUST NOT be forced to carry out many, possibly spurious, calculations or resource allocations in order to recognise another, i.e. schemes MUST NOT help denial of service attempts. • Schemes MUST allow for initial collaboration with unknown entities (in order to establish a base for recognition). • Schemes MUST allow for secure, and privacy-respecting, discovery of to-be-recognised entities. • Disconnections or lower layer outages MUST NOT end with inconsistencies but MAY interrupt current work. All interested parties SHOULD be aware of aborted work. • Schemes MUST be suitable for many different life-spans of state information, possibly determined by meta-data. Ubicomp2002 Security Workshop

  9. Requirements for recognition in ubicomp (2) • Schemes MAY be vulnerable to traffic analysis attacks. Although allowing this is in conflict with privacy considerations, preventing traffic analysis seems too hard. • Schemes MUST not be trivially breakable, in the sense that 40-bit encryption is trivial. • Schemes with an abstraction for which security proofs exist SHOULD be preferred. • Schemes MAY allow for secure transient association [StajanoAnderson1999]. • Auto-configuration MUST be supported. • Schemes MUST fit into a framework that supports pluggability, i.e. there is not “one true scheme.” • Revocation (where relevant) MUST be possible and SHOULD be as fast as possible. • It SHOULD be possible to create new identities at will. • Different entities SHOULD be able to use different schemes in different circumstances. • Any negotiation for choosing which recognition scheme to use MUST be balanced between the entities, in terms of privacy and security. • It MUST be possible to support legacy authentication solutions. • Where multiple schemes are supported it MUST be possible for higher level systems to make judgements as to, e.g. the “strength” of the scheme actually used. • It SHOULD possible to get tamper evidence detection. Ubicomp2002 Security Workshop

  10. Design for recognition • Pluggable Recognition Module (PRM) • Compatible with legacy authentication schemes : subset of recognition schemes • New recognition scheme for MANETs and Ubicomp: auto-configuration is key, privacy is important • What triggers recognition? Ubicomp2002 Security Workshop

More Related