An Efficient Access Control Model for Mobile Adhoc Communities

1
An Efficient Access Control Model for Mobile
Ad-hoc Communities

• Sye Loong Keoh and Emil Lupu
• Department of Computing, Imperial College London,
  UK

The 2nd International Conference on Security in
Pervasive Computing, (SPC 2005), Boppard,
Germany, 6 8 April 2005
2
Presentation Outline

• Ad-hoc Networking ?Community Computing?
• Motivation and Background
• Management Protocols
• Access Control Model
• Results
• Conclusion

3
Ad-hoc Networking
Media File Sharing
Business Meeting
Military Coalition

• A community of autonomous devices
• Enables interconnection, interaction,
  collaborations and share services.
• Mobile ad-hoc communities cannot rely on any
  underlying infrastructure.

4
Scenario
On a train from London to Paris
Premium subscriber of iTunes Premium subscriber
of napster Passenger of EuroRail
Exchange music files with other passengers Play
games on the train Read news (e.g. Avantgo) on
the train
5
Security Issues and Membership Management
6
Security Challenges

• Typically, users do not have a priori knowledge
  about each other.
• No continuous connection to the Internet, thus,
  Certification Authorities (CAs) can not be
  reached.
• Users have to rely on their own knowledge and the
  information provided by other peers. Thus, a
  certain amount of trust is necessary.

7
The Security Requirements

• Authenticate External Entities
• Determine a users eligibility to join the ad-hoc
  community.
• Establish Certification Authorities (CAs).
• Using policies to define the admission criteria.
• Membership Management
• Know the current members.
• To revoke existing members privileges.
• Use membership certificates and revocation lists.
• Periodic broadcast of membership lists.

8
The Security Requirements

• Authenticate existing members
• For all interactions between members, they must
  authenticate each other.
• Verification of membership certificates
• Check the membership list (if every member
  possesses a copy).
• Access control to services
• Define authorisation policies to govern the
  access to services.
• For each service access, perform authentication.
• Check the eligibility to invoke the services.

9
A Community Specification, Doctrine
policies,
constraints,
trusted keys.

• Defines role types,

• Music Client

• Game Server

• News Server

10
A Community Specification, Doctrine

• Establish a priori knowledge among
  participants.
• Define policies to regulate the behaviour of
  participants in a community.
• Avoid the need for negotiation.

• Specified by some issuers, e.g. EuroRail,
  Napster, iTunes etc. Anybody can issue a
  doctrine.
• The condition is that the participants agree to
  use the doctrine.

11
Assumptions Deployment Model

• Every participant maintains its own
  public-keypair and attribute certificates.
• Devices of participants have heterogeneous
  capability.
• Constrained devices can delegate some
  computationally intensive tasks to devices with
  higher CPU capability.

• There is a coordinator for each community.

12
TESLA Authenticated Broadcast

• To provide authenticated broadcast for the
  delivery of data packets.
• Digital signature via time
• Delayed key disclosure.
• Requires loosely time synchronisation.

F Public one-way function
13
Bootstrapping a Community
ii. Checks preferences
4
i. Broadcasts ltREQUEST, doctrine, credentials,
rolegt
2
1
iv. Checks the URA policies. v. Checks the
community constraints. vi. If fulfilled,
broadcasts an initial membership list.
3

• The coordinator generates a set of TESLA
  parameters, ltK0, ?, Tint, ?gt.
• Signs and sends ltco, CID, TS, K0, ?, Tint, ?,
  membership listgt to all.

0
14
Joining the Community

• The coordinator sends the TESLA parameters, ltK0,
  ?, Tint, ?gt node 0.
• Signs the membership using TESLA and broadcasts
  to all participants.

4
2
1
3
iii. Checks the URA policies. iv. Checks the
community constraints. v. Sends a ltJOIN
REPLYgt. vi. Broadcasts the updated membership
list.
0
i. Periodically searches for communities in the
vicinity.
15
The Coordinator is Unavailable
1
i. Detects the unavailability of the
coordinator. ii. Broadcasts ltUNAVAILABILITY
NOTIFICATIONgt
4
3

• The new coordinator generates a new set of TESLA
  parameters.
• Signs and sends ltparameters, new membership
  listgt to all.

2
0
16
Service Access
2
0
4
ii. Authenticates node 2 iii. Checks the
membership list to determine node 2s role
assignment. iv. Checks the authorisation policies

• Eliminate the need to verify membership
  certificates for each service request.

17
Implementation Architecture
Applications
Credentials, doctrines, Preferences
Application Requests
Membership Info
Authorisation Obligation Policies
Credentials, doctrines, Preferences
Membership Management
Profile Management
Policy Enforcement
Membership Info
Protocol Requests
Membership Info
Protocol Management
Events
Events
Event Service
Messages
Lower Layers
18
Access Control Model

• Exploits the local copy of membership list to
  optimise the access control mechanism.

Membership Management
Authorisation policies
Doctrine
Membership list
Role Based Access Control
Service Request, signature
Policy Enforcement
Role
Actions
Resources
19
Experiments

• We measured the performance of the policy
  enforcement component in terms of transaction
  rate (tr) using a tool called Perf4J.
• tr average elapsed time to execute the demarked
  Java code-units.
• We compared 3 models
• Model A A chain of certificates
• Model B A role membership certificate
• Model C Periodic broadcast of membership lists

20
Results
Model C (Membership List)
21
Discussion

• Average transaction rate to verify a TESLA key is
  ? 66.06.
• Average transaction rate to authenticate the MAC
  of the membership list is ? 56.63.
• Alternative approach is to use digital
  signatures, the average transaction rate to
  verify digital signatures is ? 46.10.
• A consequence of the use of TESLA is that only
  weak consistency of membership list can be
  achieved.

22
Conclusion

• An efficient access control model that requires
  significantly less computations than other
  models.
• The doctrine is used to specify policies in order
  to build trust among the participants.
• Broadcast of membership lists is suitable for
  small and medium ad-hoc communities.
• The membership list can serve as both the
  membership certificate and revocation list.

23
Thank you

• Visit our websites at
• http//www-dse.doc.ic.ac.uk/Research/Policies
  http//www-dse.doc.ic.ac.uk/slk
• Contact
• slk_at_doc.ic.ac.uk
• Acknowledgements
• Dr. Naranker Dulay and Prof. Morris Sloman EPSRC
  AEDUS research grant GR/R95715/01 EU FP6
  TrustCOM Project No. 01945