Jagdish Prasad Achara · Research Master of Computer Science (Specialty : Services, Security and...

Security Framework for Decentralized Shared Calendars

Jagdish Prasad Achara

Research Master of Computer Science (Specialty : Services, Security and Networks)

24 juin 2011

Université Henri Poincaré

Jagdish Prasad Achara (UHP – Nancy 1) Security Framework for DeSCal 24 juin 2011 1 / 25

Outline

1 Introduction

2 Security Requirements of DeSCal

3 State of the art

4 Proposed Security Framework

5 Implementation on iPhone OS

6 Possible Directions of Future Work


Outline

1 IntroductionDecentralized & third party independent shared calendarAbout DeSCalProblem Statement & MotivationsChallenges & Contributions


3 State of the art

4 Proposed Security FrameworkSecurity Framework Design RequirementsSecurity Framework DescriptionAn illustrating exampleSecuring the communication between usersDiscussion




Decentralized & third party independent shared calendar

I Shared Calendar ?

I Why decentralized & third party independent ?I Support for Ad-Hoc networks (802.11 networks).I No single point of failure.I Secrecy/confidentiality of shared calendar events.I Availability of data.

3rd party has all shared calendar information

Confidentiality?Availability?

User 1User 1

User 4

User 3

User 2


About DeSCal

I Considering the usefulness of such a decentralized shared calendar, DeSCal(abbreviation of Decentralized Shared Calendar) is proposed by us.

I What is DeSCal ?

I An administrator of an event and his role ?

I A user can take two types of operation in DeSCal :1 Cooperative operation : On shared calendar to ‘Insert’, ‘Delete’ & ‘Edit’

events.2 Administrative operation : On his access control policy to allow/deny other

users to ‘Read’, ‘Delete’ & ‘Edit’ his events.

I The design of DeSCal consists of four modules :1 Coordination module : needs cooperative log2 Access Control module : needs administrative log or admin log in short3 P2P/Ad-Hoc Network4 User Interface

I DeSCal replicates whole shared calendar state (Shared Calendar, Cooperativelog, Policies, Admin logs) for fault tolerance, availability and crash recovery.


Problem Statement & Motivations

User

DeSCal

PersistentStorage

(1)

(2)

(1) legal access

(2) illegal access

I MotivationsI Providing confidentiality to replicated shared calendar events.I Securing the communication between users.


Challenges & Contributions

I ChallengesI DeSCal’s characteristic features ?I Decentralized ‘Read’ access control ?I Dynamic group of users..

I ContributionsI Proposed a required security framework.I Its implementation on iPhone OS.


Outline



3 State of the art





Security Requirements of DeSCal

I Providing confidentiality to replicated shared calendar events.I In Shared calendar, cooperative log, policy and admin log ?

I Securing the communication between users.I Group communication ?


Outline



3 State of the art





State of the art

With the absence of central authority, security of 1) replicated data & 2)messages exchanged between peers, is a challenging task.

I OverviewI Other decentralized shared calendars and collaborative environments.I Securing replicated data.I Secrecy by splitting.


Outline



3 State of the art





Security Framework Design Requirements

I DeSCal’s characteristic features e.g., fault tolerance, availability, crashrecovery, dynamic access control must not be lost.

I On top of coordination and access control models already employed byDeSCal.

I Must preserve broadcast group communication of DeSCal.


Security Framework Description

It uses public key cryptography where authentication of public key is compulsory.

I Pathak & Iftode’s protocol



I Encryption Notations used :I Symmetric : EKe (e) and DKe (e)I Asymmetric : {m}Ku and {m}

K−1u

I Description based on all possible happenings :I User-generated happenings

1 Inserting a new event2 Deleting an existing event3 Editing an existing event4 Grant Read right5 Revoke Read right6 Grant/Revoke Delete/Edit right (Not Relevant)

I System-wide happenings1 A new user joins the shared calendar group.2 An existing user leaves the group.3 A user goes off-line and then, comes on-line again.

I How fault tolerance is achieved in DeSCal ?

I Surviving a crash.

I How availability of data is ensured ?



I Inserting a new event

e′ = EKe (e), {Ke}KOwner, {Ke}KAuthUser1

, {Ke}KAuthUser2, ....

e′ = EKe (e), {Ke}KOwner

I Granting ‘Read’ right

i = {Ke}Ku1, {Ke}Ku2



I Concurrency IssuesI ‘Read’ right revocation and ‘Edit’ concurrent operations

u1 u3u2

Owner of event 'e'

Revoke read right to u

2 for event 'e'

Initially, authorized to read and edit event 'e'

Edits event 'e' to 'f'

Initially, authorized to read event 'e'

EKf

(f), {kf}

Ku3,{k

f}

Ku1,{k

f}

Ku2

???

Concurrent Operations



I Concurrency IssuesI ‘Read’ right grant and ‘Edit’ concurrent operations

u1 u3u2 u4

Owner of event 'e'

Revoke read right to u2 for event 'e'

Initially, authorized to read and edit event 'e'

Edits event 'e' to 'f' (New key (kf)

generation because of immediate revocation)

Initially, authorized to read event 'e'

Initially, not authorized to read event 'e'

Right attribution for event 'e' to u3

{ke}

Ku3EKf(f), {kf}Ku4,{kf}Ku1

Will not be possible to decrypt as the symmetric key is changed in previousedition of this event by u

1

???

Concurrent Operations


An illustrating example

I An illustrating example

e1(u1)

u1

Group G

EKe1(e1),{Ke1}Ku1,{Ke1}Ku2






e1(u1)

e2(u3)

e3(u2)

e4(u3)

e5(u1)

e6(u2)

u3

e1(u1)

e2(u3)

e3(u2)

e4(u3)

e5(u1)

e6(u2)

u2

e1(u1)

e2(u3)

e3(u2)

e4(u3)

e5(u1)

e6(u2)

u1

e1(u1)

e2(u3)

e3(u2)

e4(u3)

e5(u1)

e6(u2)

u4

e1(u1)

e2(u3)

e3(u2)

e4(u3)

e5(u1)

e6(u2)

Inside the group G

New user u4 arrives andjoins the group G. u4

contacts nearby user u2.u2 sends him the whole

encrypted copy of shared calendar stored in

persistent storage

RR

R

R

R

R

R

R

R

R

R

R

R

e1(u1)EKe1(e1),{Ke1}Ku1,{Ke1}Ku2
























R

R

R

R

( Ku1 , K-1u1 )

( Ku2 , K-1u2 )

( Ku4 , K-1u4 )

( Ku3 , K-1u3 )

Ke1

Ke5

Ke3

Ke2

Ke6

Ke4

Ke3

Ke1

Ke1

Ke5

Ke3

Ke2

Ke6

Ke5

Ke4

Ke2

U1 crashes

U1 joins the group G again andcontacts u3. u3 gives him the

whole shared calendar state in persistent storage. u1

retrieves all his shared calenarevents back using his private key( Ku1 , K-1

u1 )


Securing the communication between users and Discussion

I Securing the communication

m′ = {m, counter}

m′′ = {m′, sig} where sig = {hash(m′)}K−1ui

I Discussion


Outline



3 State of the art





Implementation on iPhone OS

I RSA algorithm for asymmetric encryption and public/private key pair of size1024 bits.

I For symmetric encryption, AES-128.

Figure: Calendar, Event Detail, Policy and Available Peers view


Implementation on iPhone OS

Figure: Selection of various attributes to insert a new rule in policy


Outline



3 State of the art





Possible Directions of Future Work

I Possible Directions of Future WorkI Verification and Analysis of security framework.I Standardize the communication protocol.I Policy for users to join the shared calendar group.I Some works (CP–ABE, Broadcast Encryption) to be explored if they can be

used to satisfy security requirements of DeSCal while preserving itscharacteristic features.


Jagdish Prasad Achara · Research Master of Computer Science (Specialty : Services, Security and...

Documents

Transcript of Jagdish Prasad Achara · Research Master of Computer Science (Specialty : Services, Security and...