Title: Testing Implementations of Access Control and Authentication
1Testing 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
2Research Objective
- To develop and experiment with novel techniques
for the generation of tests to test
implementations of access control policies and
authentication protocols.
3Target security mechanisms
- Role based access control (RBAC) with or without
temporal constraints. - Authentication protocols (e.g. TLS)
4Proposed Test Infrastructure (Access control)
Access Control policy
5Challenges
- 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?
6Proposed 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.
7Sample model
Two users, one role. Only one user can activate
the role. Number of states32.
8Heuristics
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.
9Fault model
10Tests generated
11Concurrency 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.
12Other 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
13What 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???)