filling the gap between requirements engineering and public key trust management infrastructures
Download
Skip this Video
Download Presentation
Filling the gap between Requirements Engineering and Public Key/Trust Management Infrastructures

Loading in 2 Seconds...

play fullscreen
1 / 24

Filling the gap between Requirements Engineering and Public Key/Trust Management Infrastructures - PowerPoint PPT Presentation


  • 122 Views
  • Uploaded on

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. Summary. Motivation Our approach

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Filling the gap between Requirements Engineering and Public Key/Trust Management Infrastructures' - jud


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
filling the gap between requirements engineering and public key trust management infrastructures

Filling the gap between Requirements Engineering andPublic 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

summary
Summary
  • Motivation
  • Our approach
    • Secure aware-Tropos
    • Case study
    • Formalization
    • Axioms
    • Proprerties
    • Trust Management Implementation
  • Conclusion and future work

Giorgini P., EuroPKI 2004

trust management and pkis
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

security and requirements
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 pre-existing design
    • may not be able to accommodate them
    • security requirements can generate conflicts functional requirements of the system

Giorgini P., EuroPKI 2004

our goal
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

our proposal
Our proposal
  • A process that integrates trust, security and system engineering, using the same concepts and notations used for requirements specification
    • Three steps approach:
      • Functional Requirements modeling
      • Trust Requirements modeling
      • PKI/trust management implementation
  • We use Tropos, an agent-oriented methodology, for requirements modeling and analysis

Giorgini P., EuroPKI 2004

tropos methodology
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

security aware tropos
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

an illustrative case study
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

the functional requirements model
The Functional Requirements Model

D: Dependency

A: Aim

S: Service

Giorgini P., EuroPKI 2004

the trust requirements model
The Trust Requirements Model

O: Ownership

T: Trust

Giorgini P., EuroPKI 2004

the trust management implementation
The Trust Management Implementation

2 forms of Delegation:

P: Permission (deleg. for use)

G: delegation for Grant

Giorgini P., EuroPKI 2004

formalization 1
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

formalization 2
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

Giorgini P., EuroPKI 2004

axioms
Axioms

using Datalog

Giorgini P., EuroPKI 2004

properties
Properties

We use the DLV system for automatic verification of security requirements

Giorgini P., EuroPKI 2004

negative authorization 1
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

negative authorization 2
Negative Authorization (2)

Axioms

Properties

Giorgini P., EuroPKI 2004

trust management implementation
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

roles in the rt framework
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

moving to the rt framework
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

example 1
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

example 2
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

conclusion and future work
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

ad