A Distributed LightWeight Authentication Model for Adhoc Networks

1
A Distributed Light-Weight Authentication Model
for Ad-hoc Networks

• Andre Weimerskirch and Gilles Thonet
• ICISC 2001
• Presented by Byungchun Chung
• 2002. 12. 16

2
Contents

• Introduction
• Ad-hoc Networks
• Previous Work
• Distributed Trust Model
• Password-based Key Agreement
• Resurrecting Duckling Security Policy
• Distributed Public-key Management
• Scope of Security Models
• Distributed Light-Weight Authentication Model
• Conclusion

3
1. Introduction

• The Security Issues for Ad-hoc Network
• Availability, Confidentiality, Integrity,
  Authentication, Non-repudiation
• Ad-hoc Network
• System constraints in mobile devices
  (availability)
• Low-power µ-processor, small memory and
  bandwidth, limited battery power
• Radio jamming, battery exhaustion attack
• Frequent topology changes in the network
• Secure routing

4
2. Ad-hoc Networks

• Basic Features
• Communication links are wireless to guarantee
  mobility
• Ad-hoc networks act independently from any
  provider
• Mobile hosts have to be somehow cooperative (no
  fixed infra.)
• Network topology may be dynamic
• Power management is an important design criterion
• Security is a critical issue (weak connectivity
  and limited physical protection of mobile hosts)

5

• Potential Application
• Military application
• Communication between soldiers, solders
  monitoring
• Sensor networks for target detection and
  identification
• Emergency situation
• Provision of wireless connectivity in locations
• Cellular networks present insufficient coverage
• More expensive
• Wanted to be by-passed
• Distributed networks for data collection and
  device monitoring
• Creation of instant and temporary networks for
  ad-hoc meeting, conferences or brainstorming

6
3. Previous Work

• Trust
• Human benevolent
• IT system robust against malicious human
  attackers
• Target of trust and its classification
• Target of trust the entity we trust
• Classification exactly what the entity is
  trusted for
• Value of trust
• Trust for distributed system
• Should be based on knowledge
• Hierarchy of trust relationship
• Explicit trust relationship direct trust path
• Implicit trust relationship indirect trust path

7

• Distributed Trust Model
• Assumption
• Trust relationships are unidirectional
• Trust relationships are taking place between two
  entities
• Use a recommendation protocol
• Requesting a trust value in a trust target with
  respect to a particular classification
• After getting an answer, an evaluation function
  used to obtain an overall trust value in the
  target
• Suitable for establishing trust relationship that
  are less formal, temporary, or targeting ad-hoc
  commercial transactions

8

• Password-based Key Agreement
• Small group of people who want to set up a secure
  session
• Step
• A weak password is sent to the group member
• Each member contribute to part of the key and
  signs this data by using the weak password
• Finally a secure session key to set up a secure
  channel is derived without any central trust
  authority

9

• Resurrecting Duckling Security Policy
• Fundamental authentication problem
• Secure transient association between two devices
  establishing master-slave relationship
• Secure master and slave share a common secret
• Transient association can be solved by the
  master only
• The mother duck gives the duckling credentials
  that allow them to authenticate themselves
• Whole security chain tree topology formed of
  hierarchical master-slave relationship
• This model can be applied to very large ad-hoc
  networks

10

• Distributed Public-key Management
• Distribute trust to a set of nodes by letting
  them share the key management service (sign
  certificates)
• Use (n, t1) threshold cryptography
• Self-organized public-key infrastructure
• Centralized CA ? Certificate chain

11
4. Scope of Security Model

• Distributed Trust Model
• How to establish trust relationship
• Password-based Key Agreement
• Suitable for small group
• Authentication is done outside the IT system
• (-) Not suffice anymore for complicated
  environments
• Groups of people who do not know each other
• Pairs of people who want to have confidential
  exchange

12

• Resurrecting Duckling
• Appropriate model for a well-defined hierarchy of
  trust relationships
• The same secret key to prevent it to be stolen by
  the enemy
• Physical attack ? recover the one key ?
  compromise all nodes
• Devices cannot hold a list of all valid
  credentials
• Further authentication method is needed
• Distributed Public-key Management
• Appropriate high-value transaction

13

• Different Scope for Different Approach
• A group meeting in a small conference room
• Password-based Key Exchange
• A network defined by a hierarchy of trust
  relationships
• Resurrecting Duckling Policy
• To guarantee secure transactions
• Public-Key System
• Question Low-value transaction ?
• Ex) Huge network of cell phones where free calls
  can be made without using a phone service
  provider (No-security approach!!)

14
5. Distributed Light-Weight Authentication Model

• Human behavior
• To check out another person, people usually ask
  friends about that person
• Also they will ask the target person for
  references
• To check the identity of another person, people
  will ask about common knowledge
• Secret password or details of previous
  transactions
• When no explicit common knowledge
• Trust relationship can be derived using a trust
  third party
• Public Key System CA
• Hierarchical trust relationship Mother duck
• Trust relationship trust chain

15
Model Description

• Scenario
• Alice wants to verify Bobs identity
• Alice starts asking Bob about common knowledge
• Secret key, knowledge about a recent transactions
• If there is common knowledge, Bob can prove his
  identity
• Otherwise
• Recommendation
• Alice starts requesting recommendations from
  nodes taken her list of trustworthy entities
• Let assume one of the devices Alice asks is Cathy
• Alice can check cathys identity by asking her
  about common knowledge

16

• Cathy then looks if Bob is one her list of
  trustworthy people and checks his identity or
  forward Alices request in the same manner
• Once Dan is found the knows Bob and can prove his
  identity, the information is sent back to
  Alice, including all entities in the
  recommendation chain from Alice to Dan
• Reference
• Alice can ask Bob to give his references
• Other devices he has done transactions with
  recently
• Alice can then ask these devices if they know Bob
• Alice can ask again her network of trustworthy
  entity if they know the reference

17

• Once a link between Alices trustworthy network
  and Bobs reference network is formed
• gt a direct relationship between Alice and Bob
  can be derived
• After Alice has received the results of her
  request, she has to evaluate the data
• Trust Evaluation
• After Alice has received the results of her
  request, she has to evaluate the data
• Allow Alice to decide if she believes in Bobs
  identity or not

18

• Evaluation function
• The idea of threshold cryptography
• If Alice receives n answers to her request, we
  want the result be not influenced by t or less
  malicious agents, where n gt 2t
• Secure Channel
• Once an entity is authenticated a secure channel
  can be initiated
• If no common knowledge
• Alice can send Bob a secret over the trustworthy
  path used to derive a relationship
• Bob then send back another secret using a random
  path
• (i) (ii) ? Shared secret key

19

• Cooperation
• Combination of incentive and punishment
• Feedback Information
• To make the system more robust and protect it
  from compromised nodes

20
6. Conclusion

• Focused on authentication since this is the core
  requirement to initiate a secure channel
• Described several existing models and analyzed
  their scope, possible scenarios
• Provide a new authentication model for low-value
  transaction
• Recommendation derive trust
  relationship
• Reference
• Cooperation introduce quality
  and responsibility
• Feedback