Secure Ubiquitous Computing based on Entity Recognition JeanMarc

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

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

Background • Work carried out as part of the IST-200132486 SECURE project. • By members of the Distributed Systems Group of Trinity College Dublin. 9/9/2020 Ubicomp 2002 Security Workshop 3

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 [Stajano. Anderson 1999] • Any identifier can work as long as it allows for referencing the entity involved 9/9/2020 Ubicomp 2002 Security Workshop 4

Authentication subset of recognition location Kerberos recognition patterns PKI IP address Windows login duckling authentication 9/9/2020 Ubicomp 2002 Security Workshop 5

Authentication/Recognition comparison Authentication Process (AP) Entity Recognition (ER) A. 1. Enrolment: generally involves an administrator or human intervention A. 2. Triggering: e. g. , someone clicks on a Web link to a resource that requires authentication to be downloaded E. 1. Triggering (passive and active sense): mainly triggering (as in A. 2. ), with the idea that the recognizing entity can trigger itself A. 3. Detective work: the main task is to verify that the prinicpal’s claimed identity is the peer’s E. 2. Detective work: to recognize the entity to-be recognized using the negotiated and available recognition scheme(s) E. 3. Retention (optional): “preservation of the after effects of experience and learning that makes recall or recognition possible” [Merriam. Webster] A. 4. Action: the identification is subsequently used in some ways. Actually, the claim of the identity may be done in steps 2 or 3 depending on the authentication solution (loop to A. 2. ) 9/9/2020 E. 4. Action (optional): the outcome of the recognition is subsequently used in some ways (loop to E. 1. ) Ubicomp 2002 Security Workshop 6

Ubicomp issues • • • Billions of potential subjects Continual change in 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 … 9/9/2020 Ubicomp 2002 Security Workshop 7

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-berecognised 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. 9/9/2020 Ubicomp 2002 Security Workshop 8

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 [Stajano. Anderson 1999]. 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. 9/9/2020 Ubicomp 2002 Security Workshop 9

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? 9/9/2020 Ubicomp 2002 Security Workshop 10