Project Topics
Get Complete Project Material File(s) Now! »
The shared calendar must not depend on a third party.
Shared calendars based on a third party central server, for instance, Google Calendar [GCa], prevents users to create a dynamic Ad-Hoc group as users always have to communicate through this central server. Moreover, there is no direct communication between users and they need to have a constant connection to this third party central servers (e.g. an Internet connection to connect to Google Servers to use Google Calendar). Also, using third-party central server to store the shared calendar information, reduces availability of the data as the data has to be fetched from or stored at remote central server when modified by users. Above all, using a third party for sharing calendar events may also lead to sacrificing the confidentiality of these users’ calendar events which is possibly an important concern for a user. See Figure 2.1 to better understand the disadvantages behind using a third party to store the shared calendar information.
An access control mechanism is needed on shared calendar events.
It may not always be appropriate for a user to share all his calendar events with other users in the group. A user may have some secret events which he would like to share only with some selected user(s) in the group, not with everyone. To deal with this aspect of shared calendar, there must be some access control mechanism on shared calendar events. Moreover, access control on shared calendar events must be dynamic, i.e. users should be able to change the access rights on their shared calendar events at any point of time after the creation of an event (unlike the case where a user specifies access control for an event only at the time of creation or insertion of an event).
A Deployment Scenario of DeSCal
A research team in a research organization usually consists of a scientific and administrative leader, other members of the team and an administrative assistant. All members of the team can run an instance of DeSCal to keep track of their personal events and also, to share some group events with others. They can hide their personal events by not sharing these events with others. For group events involving two or more persons, one can create the event and share it with other members who are concerned by it. If few members of the team are in a group meeting, others can know this by just having a look on DeSCal. In addition, it is more intuitive for a team leader to share some administrative events with delete and/or edit right with the administrative assistant of the team so that extra hassle of communication can be avoided to deal with administrative tasks.
At the same time, we agree with the fact that this can also be easily done using a centralized shared calendar like Google Calendar but members of this research team can find DeSCal more appropriate if any one or all of the following possible scenarios are true:
• The central entity in the centralized shared calendar is not owned by the organization itself and also, this organization has no connectivity with the outside network of a third party on which centralized shared calendar depends. For example, this research team can’t use Google Calendar if they don’t have Internet connection as it is managed by a third party.
• Members of the team want to keep their calendar events confidential i.e. they don’t want to disclose their calendar events with this third party (for instance, Google in case they use Google Calendar) who provides shared calendar service.
• A team member meets someone while going for lunch or for a coffee and he wants to share some events with this person. This can be done instantly without any overhead like registering for shared calendar service of a third party; just by allowing other person to join the group and sharing only some specific events which this team member wants to share.
DeSCal Workflow
Below, we present the sequence of major steps taken by DeSCal to better understand it while hiding the complexity behind these steps:
1. When a user manipulates an event in the local copy of the shared calendar by generating a cooperative operation, this operation will be granted or denied by only checking the local copy of the policy of the administrator of that particular event.
2. Once granted and executed, the local cooperative operation is then broad-casted to other users. On reception of this operation at remote user sites, a user has to check whether the remote operation is authorized with respect to his locally stored admin log4 of the event’s administrator before executing them on his local copy of the shared calendar.
3. When a user modifies his local policy by adding or removing authorizations, he sends these modifications, i.e. administrative operations, to other users in order to update their local copies of the policy.
Providing confidentiality to replicated shared calendar events
The whole copy of the shared calendar is replicated at each user site in DeSCal but a user should be able to read, delete or edit only the events for which he is authorized. For shared calendar events not to be deleted/edited by unauthorized users, DeSCal [AIR11] already employs an access control module, which essentially ensures the integrity of the replicated shared calendar events. However, this access control model can’t prevent users to read the shared calendar events for which they are not authorized. It is of no use to provide confidentiality to shared calendar events as in DeSCal, the whole shared calendar is replicated at each user site in plain-text. As a matter of fact, a user can read this locally stored shared calendar state directly without using the application (or outside the scope of the application) even if DeSCal generates a view of ‘Read’ access authorized calendar events for the user to hide the unauthorized shared calendar events for ‘Read’ access. This leads to loosing the confidentiality of shared calendar events. So, here, our primary goal is to provide confidentiality to shared calendar events i.e., only authorized users can read the shared calendar events. We highlight here that we don’t deal with the integrity of shared calendar events as it has been already dealt by access control module employed in DeSCal.
Below, we discuss informally what additional data needs to be secured apart from the repli-cated shared calendar and why this data needs to be secured. As it is clearly evident from the fact that DeSCal is pure P2P, we need to store the copy of the shared calendar at each user site. In addition to storing the shared calendar, as described in Chapter 2, a user in DeSCal also needs to store following four entities at each user site:
• Shared Calendar.
• Policies of each user.
• Admin logs of each user and.
• Cooperative log.
Storing local copy of all these data leads to high availability of data, thereby, also increasing the responsiveness and performance of the DeSCal. While providing confidentiality to shared calendar events, care must be taken as a cooperative log stores all local and remote cooperative requests. It requires us to provide confidentiality to shared calendar events stored as cooperative operations in cooperative requests. Policies and admin logs of all other users stored at each user site don’t need to be secured in DeSCal as they (policies and admin logs) contain the access control information on shared calendar events. Reading these copies of the policies and admin logs can’t help a user to get any significant information about shared calendar events except the unique event ids of events. Even if a user changes these locally stored copies of admin logs and policies of other users, he will end up having his own shared calendar copy diverged from other shared calendar copies stored at various other user sites. Other users won’t be affected by it because they will simply ignore his unauthorized actions on shared calendar events once they will be received at their corresponding local sites. On reception of his unauthorized actions at remote user sites, these actions can be checked against remote users’ local copies of the polices and admin logs; and can be rejected if not allowed according to their locally stored policies or admin logs.
Securing the communication between users
Besides confidentiality to replicated shared calendar events, DeSCal [AIR11] doesn’t provide any security measures to secure the messages exchanged among users. The network communication between users must be secured with respect to all basic security properties like confidentiality, integrity, non-repudiation, replay attack. It is an important fact to point out that in DeSCal, a number of users form a group to participate in the shared calendar but the group communication security mechanisms are not suitable for DeSCal. At first glance, it might seem a little bit awkward but in DeSCal, the messages broadcast are not intended to be read by everyone in the group; as opposed to DeSCal, it is actually the case in group communication. It is due to the fact that, unlike in group communication where all users are equally privileged, users in DeSCal have different rights. In DeSCal, for each event, only a subset of users in the group are authorized to read. A message broadcast to all users in DeSCal should not be read by the users who are not authorized to read it while it is in network transmission. For example, if a user u1 wants only user u2 to read his event, then, user u3 (also, part of the group) should not be able to read this event. Therefore, when this network message is broadcast to all the users in the group through a communication channel, it needs to be secured in such a way that user u3 (who belongs to this group) should also not be able to access it. Here, in DeSCal, a broadcast network message has to be secured from unauthorized users in shared calendar group of DeSCal as well as outsiders while it is in transit.
Table of contents :
Chapter 1 Introduction
Chapter 2 Background
2.1 Desired Features of Shared Calendars
2.2 DeSCal .
2.2.1 Is DeSCal the first one of its kind?
2.2.2 A Deployment Scenario of DeSCal
2.2.3 Ingredients of DeSCal
2.2.4 DeSCal modules
2.2.5 DeSCal Workflow
2.2.6 What does a DeSCal user site need to store?
Chapter 3 Security Requirements of DeSCal
3.1 Providing confidentiality to replicated shared calendar events
3.2 Securing the communication between users
Chapter 4 State of the art
4.1 Security mechanisms adopted in other shared calendars and decentralized collaborative environments. .
4.2 Securing replicated data.
4.3 Secrecy by splitting.
Chapter 5 Proposed Security Framework
5.1 Our proposed security framework
5.1.1 Description .
5.1.2 Concurrency Issues
5.2 An illustrating example
5.3 Securing the communication between users
5.4 Discussion .
Chapter 6 Implementation on iPhone OS
Conclusions and Possible Directions of Future Work
1 Conclusions .
2 Possible Directions of Future Work
Bibliography
