Secure Ubiquitous Computing based on Entity Recognition

1
Secure Ubiquitous Computing based on Entity
Recognition

• Jean-Marc Seigneur, seigneuj_at_tcd.ie
• (Co-authors Stephen Farrell, Christian Damsgaard
  Jensen)

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

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.

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

5
Authentication subset of recognition
location
Kerberos
patterns
PKI
Windows login
IP address
duckling
6
Authentication/Recognition comparison
7
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

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.

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.

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?