Testing Implementations of Access Control and Authentication

1
Testing Implementations of Access Control and
Authentication
School of Electrical and Computer
Engineering Department of Computer Science Purdue
University
Cyber Security Information Infrastructure
Workshop
Graduate Students Ammar Masood, K. Jayaram
Faculty Arif Ghafoor (ECE), Aditya Mathur (CS)
May 10, 2006 Oak Ridge National Lab, Oak Ridge, TN
2
Research Objective

• To develop and experiment with novel techniques
  for the generation of tests to test
  implementations of access control policies and
  authentication protocols.

3
Target security mechanisms

• Role based access control (RBAC) with or without
  temporal constraints.
• Authentication protocols (e.g. TLS)

4
Proposed Test Infrastructure (Access control)
Access Control policy
5
Challenges

• Modeling
• Naïve FSM or timed automata models are
  prohibitively large even for policies with 10
  users and 5 roles (and 3 clocks).
• How to reduce model size and the tests generated?
  
• Test generation
• How to generate tests to detect (ideally) all
  policy violation faults that might lead to
  violation of the policy?
• Test execution
• Distributed policy enforcement?

6
Proposed Approach

• Express behavior implied by a policy as an FSM.
• Apply heuristics to scale down the model.
• Use the W- method, or its variant, to generate
  tests from the scaled down model.
• Generate additional tests using a combination of
  stress and random testing aimed at faults that
  might go undetected due to scaling.

7
Sample model
Two users, one role. Only one user can activate
the role. Number of states32.
8
Heuristics
H1 Separate assignment and activation
H2 Use FSM for activation and single test
sequence for assignment
H3 Use single test sequence for assignment and
activation
H4 Use a separate FSM for each user
H5 Use a separate FSM for each role
H6 Create user groups for FSM modeling.
9
Fault model
10
Tests generated
11
Concurrency and Cryptographic protocols

• Cryptographic protocols are highly concurrent
  because they involve multiple principals (they
  may be synchronous or asynchronous)
• Man-in-themiddle attacks exploit
  concurrency-related aspects. Attackers can
  read/delete/modify messages between concurrent
  principals
• Concurrency is an in-alienable part of every
  protocol. A test case for testing a cryptographic
  protocol involves concurrent principals
• Formal models used to derive tests should
  therefore support concurrency! --gt Statecharts
  is our choice.

12
Other aspects of concurrency

• A server for example, has several sessions of a
  protocol running concurrently.
• The protocol implementation should be thread
  safe.
• Principals in one concurrent session should not
  be able to access parameters of a parallel
  session
• Protocol implementations may be required to
  satisfy performance requirements in a
  multi-session scenario this is important for
  performance/stress testing

13
What is next

• Modeling
• Handling timing constraints? (timed automata,
  fault model, heuristics)
• Handling authentication protocols? (Statecharts,
  insecure paths, test generation)
• Dealing with concurrency?
• Experimentation
• With large/realistic policies and commercial
  authentication protocols to assess the efficiency
  and effectiveness of the test generation methods.
  
• Prototype tool development (Money???)