Filling the gap between
Requirements Engineering and
Public Key/Trust Management
Infrastructures
Paolo Giorgini
Department of Information and Comm. Tech.
University of Trento (Italy)
Joint work with
Fabio Massacci, John Mylopoulos, and Nicola Zannone
Giorgini P., EuroPKI 2004
1
Summary
• Motivation
• Our approach
–
–
–
–
–
–
Secure aware-Tropos
Case study
Formalization
Axioms
Proprerties
Trust Management Implementation
• Conclusion and future work
Giorgini P., EuroPKI 2004
2
Trust Management and PKIs
• Trust Management and PKIs are hot topics in security
research:
– sophisticated policy languages, algorithms, and system for
managing security credentials
• Solutions based on public-key cryptography and
credential have been shown to be well suited in
satisfying the security requirements of distributed
systems
• However, there is big gap between solutions and the
requirements of the entire system
Giorgini P., EuroPKI 2004
3
Security and Requirements
• No methodologies for linking security policy to
the mainstream requirements analysis process
• The usual approach towards the inclusion of
security within a system is to identify security
requirements after system design
• Security mechanisms have to be fitted into a preexisting design
– may not be able to accommodate them
– security requirements can generate conflicts
functional requirements of the system
Giorgini P., EuroPKI 2004
4
Our goal
• There are proposals improving on secure engineering
or architectures for trust management, but nobody has
proposed a methodology that considers together both
these approaches
• We want to introduce a trust management system into
the requirements engineering framework
– avoid designing an entire system and then retrofitting a PKI on
its top, when it is already to late to make it fits snugly
Giorgini P., EuroPKI 2004
5
Our proposal
•
A process that integrates trust, security and
system engineering, using the same concepts
and notations used for requirements
specification
– Three steps approach:
1. Functional Requirements modeling
2. Trust Requirements modeling
3. PKI/trust management implementation
•
We use Tropos, an agent-oriented methodology,
for requirements modeling and analysis
Giorgini P., EuroPKI 2004
6
Tropos Methodology
• Tropos is an agent-oriented software development
methodology, tailored to describe both the organization
and the system itself
• Tropos uses concepts of
– Actor
Intentional entity: role, position, agent (human or software)
– Goal (softgoal)
Strategic interest of an actor
– Task
Particular course of action that can be executed in order to satisfy a goal
– Resource
Physical or informational entity (without intentionality)
– Social dependency (between two actors)
One actor depends on another to accomplish a goal, execute a task, or
deliver a resource
Giorgini P., EuroPKI 2004
7
Security-Aware Tropos
• Tropos has not been designed with security in mind
• We introduce four new relationships:
–
–
–
–
Trust ,among two agents and a service
Delegation, among two agents and a service
Ownership, between an agent and a service
Offer, between an agent and a service
• And we refine the methodology by
– Define functional dependencies of services among actors
– Design a trust model among actors
– Identify who owns services and who is able to fulfill them
Giorgini P., EuroPKI 2004
8
An illustrative Case Study
• A health care IS, in which
– Patient, that depends on the hospital for receiving appropriate
health care. Further, patients will refuse to share their data if they
do not trust the system or do not have sufficient control over the
use of their data;
– Hospital, that provides medical treatment and depends on the
patients for having their personal information.
– Clinician, physician of the hospital that provides medical health
advice and, whenever needed, provide accurate medical
treatment;
– Health Care Authority (HCA) that control and guarantee the fair
resources allocation and a good quality of the delivered services.
– Medical Information System (MIS), that, according the current
privacy legislation, can share the patients medical data if and only
if consent is obtained.
Giorgini P., EuroPKI 2004
9
The Functional Requirements Model
D: Dependency
A: Aim
S: Service
QuickTime™ and a
TIFF (LZW) decompressor
are needed to see this picture.
Giorgini P., EuroPKI 2004
10
The Trust Requirements Model
O: Ownership
T: Trust
QuickTime™ and a
TIFF (LZW) decompressor
are needed to see this picture.
Giorgini P., EuroPKI 2004
11
The Trust Management Implementation
2 forms of Delegation:
P: Permission (deleg. for use)
G: delegation for Grant
QuickTime™ and a
TIFF (LZW) decompressor
are needed to see this picture.
Giorgini P., EuroPKI 2004
12
Formalization (1)
Predicates for the functional requirements model
• offers(a,s)
• aims(a,s)
• has(a,s)
• depends(a,b,s1,s2)
Predicates for the trust requirements model
• owns(a,s)
• trust(a,b,s1,s2,n)
n: trust depth
Predicates for the trust management implementation
• fulfills(a,s)
• delGrant(idC,a,b,s1,s2,n)
idC: certificate identify
n: delegation depth
• permission(idC,a,b,s1,s2)
Giorgini P., EuroPKI 2004
13
Formalization (2)
A way to see depth is the number of re-delegation; depth 1
means that no re-delegation is allowed, depth N that N-1
further step are allowed

k s.t. a1...ak n1 ...n k1 i  1...k 1
delGChain (A,B,S1,S2)  
delGrant( id i ,ai ,ai1,S1,S2,n i ) (a1  A) (ak  B)
(permission (idC, A,C,S1,S2)) 

permissionChain (A,C,S1,S2)  (B delGChain (A,B,S1,S2)) 
 permission( idC,B,C,S1,S2))

Giorgini P., EuroPKI 2004
14
Axioms
using Datalog
QuickTime™ and a
TIFF (LZW) decompressor
are needed to see this picture.
Giorgini P., EuroPKI 2004
15
Properties
QuickTime™ and a
TIFF (LZW) decompressor
are needed to see this picture.
We use the DLV system for automatic verification of security requirements
Giorgini P., EuroPKI 2004
16
Negative Authorization (1)
• We use a closed world policy: the lack of an authorization is
interpreted as a negative authorization
• This approach has a major problem in the lack of a given
authorization for a given actor does not prevent this user from
receiving this authorization later on
• We propose an explicit negative authorization, namely an explicit
denial for an actor to access a service
• Negative authorizations are stronger than positive authorizations
• Two predicates:
– delDenial(idC,a,b,s,n)
– prohibition(idC,a,b,s)
and analougsly for positive authorization
– delDChain(A,B,S)
– prohibitionChain(A,C,S)
Giorgini P., EuroPKI 2004
17
Negative Authorization (2)
Axioms
QuickTime™ and a
TIFF (LZW) decompressor
are needed to see this picture.
Properties
QuickTime™ and a
TIFF (LZW) decompressor
are needed to see this picture.
Giorgini P., EuroPKI 2004
18
Trust Management Implementation
• We use the RT framework (by Li et al.), which provides
policy language, semantics, deduction engine, and
pragmatic features
• RT includes a declarative, logic-based semantic
foundation based on Datalog, support for vocabulary
agreement, strongly-typed credential and policies, and
flexible delegation structures
• In RT, an entity is a uniquely identified individual or
process
• An entity can issue credentials and make requests
• RT uses the notion of role to represent attributes
– Entity.Role
Giorgini P., EuroPKI 2004
19
Roles in the RT framework
• Only the entity A has the authority to A.R, and A does so
by issuing role-definition credentials
• An entity A can define A.R to contain A.R1, another role
defined by A
– A.RA.R1, means that A defines that R1 dominates R
• A credential A.RB.R is a delegation from A to B of
authority over R. This can be used to decentralize the
user-role assignment.
• A credential of the form A.RB.R1 can be used to
define role-mapping across multiple organizations
• The credential A.RA.R1.R2 states that: A.R contains
any B.R2 if A.R1 contains B.
Giorgini P., EuroPKI 2004
20
Moving to the RT framework
permission(ID,A,B,S1,S2)
– A.S1B.S2
delGrant(ID,A,B,S1,S2,N)
– A.S1B.r.S2
where B allows to use the service S1 to actors in
the role B.r
Giorgini P., EuroPKI 2004
21
Example 1
A patient allows his clinician to read his personal/medical
data to provide accurate medical treatment.
permission(id,Pat,Cli,Rec,MedTre):isClinicianOf(Pat,Cli)^owns(Pat,Rec)
In RT:
Pat.recordAc(read,?F:Pat.record)
Pat.clinician.provide(?E:medTre)
Given Pat.recordRec and Pat.clinicianCli, one
can conclude that
Pat.recordAc(read,Rec)Cli.provide(?E:medTre)
Giorgini P., EuroPKI 2004
22
Example 2
The Medical Information System allows the clinician to
write on his patient records to upgrade them.
permission(id,MIS,Cli,Rec,upgrade(Rec)):isClinicianOf(Pat,Cli)^owns(Pat,Rec)
In RT
MIS.recordAc(write,?F:Pat.record)
Pat.clinician.upgrade(?F:Pat.record)
Given Pat.recordRec and Pat.clinicianCli, one
can conclude that
MIS.recordAc(write,Rec)Cli.upgrade(Rec)
Giorgini P., EuroPKI 2004
23
Conclusion and future work
• We have introduced a process that integrates security
and requirements engineering
– A clear separation of trust and delegation relationship
• Our framework supports the automatic verification of
security requirements
• We have defined the trust management implementation
of our framework into the RT framework
• Future work
– incorporating explicitly roles adding time features
– integration with the Formal Tropos tool
Giorgini P., EuroPKI 2004
24