1

Trustworthy Distributed Computing:

An Overview of Ongoing Work

Fillia MakedonDartmouth Experimental Visualization

Laboratory (DEVLAB)

Dartmouth College

2

Contents

1. Focus: Secure group collaboration

2. OC: the Open Collaboration system

3. Related work in the DEVLAB– Automated Data Negotiation (SCENS)– Collaborative Automated Trust Negotiation– Trustworthy Recommendation Systems– Sensor Networks

4. Future Directions

3

• Goal

Any qualified entity can join a secure collaboration.

• The problems

1 How to allow a stranger to join a collaboration?

2 How to securely disseminate shared data without a centralized server while access is controlled by the data owner and his trusted collaborators?

4

Applications• Numerous examples of collaboration among entities that

do not know each other or are physically distributed• audio and video conferencing• remote education • virtual patient-research teams• Crime teams• ….

• What does a collaborative application need?• a communication infrastructure for efficient message

dissemination to multiple parties• synchronization mechanisms for coordination• security services

We focus on security services for group collaborations

5

Background

• Basic Problems– Trust among strangers– Dynamic collaborations– Changing environments

• Basic Tools– Peer-to-Peer (P2P): decentralized networks– Automated Trust Negotiation (ATN): a

standard method for bilateral credential exchange

6

P2P

• A typical distributed application is P2P– Every participating node can act both as a client and

server– Distributed resources are utilized to perform some function

in a decentralized manner• E.g. File sharing: eDonkey, Kazaa, etc.

• P2P systems allow mutually distrustful parties to join or leave freely– No centralized security domain– Anonymous

• Note: “peer”, “party”, and “node” are used interchangeably,and all refer to an entity in a P2P system.

7

Authentication Issues• Because P2P is open, anonymous and

decentralized, it is difficult to verify the validity of the resources offered by other peers.

• Free riders, which only want to use other peers’ resources without contributing anything, – greatly compromise the fairness of most P2P

systems – discourage contributing peers from continuing to

share resources.

8

Access Control• Traditional computer systems have closed and

centrally managed security domains• An entity has one or more identities associated with it• Access to a resource is enforced by access control policies,

– Example: one can access a remote Unix machine by providing valid userid/password

• Traditional identity-based approaches do not work for P2P

• Peers build trust by exchanging digital credentials

• A digital credential is proof of owning an attribute• Since credentials can have sensitive information, need to

prove the other side is trustworthy

9

Attribute based access control

• How do we control the way attributes are disclosed?– Through a credential disclosure policy which is

an access control policy

• How do we establish a credential disclosure sequence?– Through Automated Trust Negotiation (ATN)

– (ATN) helps two strangers build mutual trust through exchanging certificates. [Winsborough et al. 2000]

10

Automated Trust Negotiation (ATN)

• Peers build trust with each other through Automated Trust Negotiation– Orthogonal to reputation-based approach– Can combine both of methods

• Trust is established incrementally

– By using a disclosure policy to exchange credentials

• There is a policy associated with each credential to indicate conditions under which it can be disclosed

11

What is a Group Collaboration System?

Group collaboration application

Lecturer Program Coordinator

SecretaryAudience B

Audience A

A Group Collaboration System provides two types of services:

Group administration → Creation of a group→ Maintenance of a group→ Destroying a group

Data sharing→ Access to data→ Storage of data→ Transmission of data

OC allows strangers to join a collaboration through trust negotiation and by maintaining collaborations in a pure P2P fashion

12

What is an Open Environment ?

A Group Collaboration System runs in such an environment where entities are diverse and autonomous

Diverse : a stranger should be allowed to join a collaboration if he is qualified.

Autonomousan entity is self-motivated and self-governed.

Group collaboration application

Lecturer Program Coordinator

SecretaryAudience B

Audience AAlice

Dartmouth

BobUniv. of NH

Carlo Hanover High School

Othercollaboration applications

Trust management gives access to requestersaccording to their attributes, instead of their Identities. The data owner can decide yes/no on a requester you do not know.

Stranger may show up any time

Self governed: has own policies defined in his domain of knowledge

13

OC: A Framework for Secure Group Collaboration in an Open Environment

• Goals1. Allow qualified strangers to join a collaboration efficiently

2. Remove the need for a server and central administration

3. Give users privacy they can control and security they can understand

• Approach – Improve existing Automated Trust Negotiation to serve Goal 1– Use P2P solutions to serve Goal 2– Separate the profiles used by groups and individuals to serve Goal 3

• Requirements for secure collaboration– Administration of group membership– Data sharing with associated access policies– Secure communications among members of the group

14

Existing research• Focuses on scalable and fault tolerant group key

management protocols [Amir et al 2004, Rodeh et al, 2000, Wong et al 1998]

• Data confidentiality and integrity [Aggarwal et al 2001, Amit et al 2003, McDaniel 1999, Rodeh et al 2000]

• Large-scale and decentralized trust management for access control [Li et al, 2002, Li et al, 2003]

• Public key support for the key-name binding problem [Ellison et al, 2003, Dohrmann et al 2002]

• ……………………………….• No existing system for secure group collaboration

in open environments using negotiation and trust management among entities that are diverse, independent and autonomous.

15

Examples of Group Collaboration Systems and Limitations

Roles Policies Centralized Enrollment

Open-Xchange 2 (adm+user) fixed C adm

eGroup-Ware 2 (adm+user) fixed C adm

Groove 4: administrator, manager, participant, guest

fixed C & D adm & by invitation

NGC[Ellision and Dohrmann 03]

33 = administrator, invitied member, basic member

fixed D adm & by invitation

GCS[Nita-Rotaru and Li’s 04]

Many (3+n) dynamic C unknown

16

Example of Trust Negotiation in Real Life

1. Alice wants to buy beer with her credit card from a store2. Bob, the cashier, asks Alice to show her credit card and a

photo ID3. Alice then asks Bob to show his employee ID

1. Since Credit card and a photo ID (like driver license or passport) are sensitive

• Bob shows his employee ID (which is not sensitive and can be shown to anyone)

• Alice shows her credit card and driver license, and finishes the transaction

Note: Both Alice and Bob don’t care who the other is; they only care about some specific attributes the other has: photo ID, credit card, employee ID, etc.

How do we formalize this in the digital world?

17

System Model• Through trust negotiation we get a credential disclosure

sequence so that the access control policy for R is satisfied. • A credential disclosure policy for a resource R is defined as

[Yu, et al. 2000, CCS]

• A credential C is a special kind of resource

• A resource R (or credential C) is unprotected

Note: If R is false, cannot be accessed; If C is false, cannot be disclosed

18

Trust Negotiation Model

Alice Bob

19

Example with interactive steps using ATN• Alice is an AIDS patient with a credential to prove it.• DHMC : a hospital offering free on-line service to AIDS patients

who are US citizens. • DHMC is also a certified hospital which protects patients’

privacy very well (HIPAA).

ATN credential exchange:

20

Restricting Access

• Some collaboration projects should be open only to qualified people

• Some collaboration projects can be open to the public

• Other collaboration projects are open to both• => Different demands for different applications,

want to be flexible

21

ApproachUse ATN in collaboration systems so that projects can be

open to any qualified strangers—a capability not addressed so far

I am interested in joining this group… but I know nobody there.

Req to joinGroup collaboration application

Lecturer Program Coordinator

Secretary

Audience B

Audience AReq for Driver’s license (age>18)

Req for employee certificate

Employee certificate

Driver’s license

Limited pass

Verify the Certsuccessfully

Verify the Driver’s licenseand check the age

22

Group Profile------------------- Group name Mission description Current time Join requirements A list of members A list of files (and associated policies)

Private Profile-------------------- Memberships Personal certificates (and associated policies) Files (and associated policies) Local strategies

Separating Group and Private Information

• Our approach separates the profiles used by groups and individuals in order to let entities control their privacy

• The group profile, propagated in a P2P fashion, has two parts:– Publicly accessible part– Selectively accessible part

• The private profile, stored in local computer, is created, accessed, controlled, and managed only by the entity itself

23

• OC disseminates group profiles in a P2P fashion with two modes: passive and active– Passive mode

• Every on-line entity passively receives group profile updates from its neighbor entities

• In other words, every entity sends out its group profile to others periodically

• The receiving party decides to accept or discard according to the timestamp and the version

– Active mode• An entity can actively send a request of updating its group

profile to its neighbor entities• Complementary to the passive mode—an entity might show

up at any time and then disconnect after a short interval• In either mode, the shared file names are synchronized while the

files themselves are not, because some entities may be limited (memory, power, bandwith) mobile devices.

• Can download the actual file from peers when needed.

Group Profile Management

24

Applying a Role-based Approach• When a stranger asks to join, it is not always feasible to

apply ATN straightforwardly in a collaboration system

• ATN handles only a two-party case– in collaborations there are typically many entities– very inefficient to perform 1-to-1 negotiations with

every existing member

• Take advantage of the implication of trust relationships among roles to extend two-party ATN– Roles imply some existing trust relationship among

collaborators– A role can be viewed as an integration of some

attributes

25

Real World Digital World

True name X.509, PGP identity certificate

Anonym temporary X.509 certificate with pseudonyms,

SPKI certificate.

Proxy name SDSI certificate,

X.509 proxy certificate

• Support three kinds of different identities-• In open environments, entities are independent and

autonomous. They define their own privacy and make decisions whether to join.

• If we support only one kind of identity, we will lose some potential opportunity of collaborations.

Identities

26

RT: A Role-based Trust Management Language Family [Ninghui Li & John Mitchell, 2003]

RT doesn’t describe the requirements of assigning a role. We add RTA to RT family to do this.

27

• Existing role-based trust management (RT) has local policies created and managed separately by end users alone—so roles are only meaningful to the users who create them.

• In collaborations, roles should be agreed on by collaborators. – The implied trust relationships behind roles should be meaningful to

collaborators.• We added RTA to RT to support this

– Observations • If the requirements of assigning a role are transparent to and

agreed by all users, an entity can easily determine the trustworthiness of another entity by his role or referrer.

• There are three different kinds of requirements: Attribute, Identity, and Majority approval.

– RTA describes the requirements of assigning a role:• Attribute (certificate) requirement

e.g. R Attr1 and (Attr2 or Attr3). Attri is some attribute.• Identity requirement

e.g. R truename or pseudonym.• Majority requirement

e.g. R 50% approval of R1 and 100% approval of R2.

Extending RT for OC

28

The OC Interface

• Any entities can log on to OC with any names they want.

• Collaborative groups can be created by any entity and are propagated in a P2P fashion.

current online peersin OC

current collaborativegroup

29

Group operations Role operations File operations

OC-Enabled Sharing

Currently, all the operations are protected by off-line transmitted password. We are modifying the code and implementing

role-based policies to protect the role application, and file sharing.

30

Using Roles in OC

• OC currently supports simple roles: in order to access a role, a peer node needs to get the role password

• OC supports file sharing in a P2P fashion

• Now adding role based policies for secure file propagation

4 roles in RRT-group

a shared pdf file among

Graduate students

31

Related Work and Projects

• Secure Content Exchange Negotiation System (SCENS): Automated Data Negotiation

• Collaborative Automated Trust Negotiation

• Trustworthy Recommendation Systems

• Local Data Protection for In-Network Processing in Sensor Networks

• Localization Techniques in Sensor Networks

32

SCENS: a general platform for sharing scientific data

• SCENS is a precursor to OC

• Data negotiation (including Automated Data Negotiation, ADN) supports transactions– Parties agree on an access policy through

back-and-forth communications– Final policy is recorded by a central SCENS

server

33

Introduction to SCENS

• Secure Content Exchange Negotiation System• Negotiation-based data sharing

– Negotiate on the conditions under which the data should be shared

• Other types of resource sharing– Service– Storage– Bandwidth– Computing

39

Login interface

User can login with registered username and password or register as new user from this interface.

40

Main interface of SCENS

Register new data

Manage current user’s registered data.

List of registered data from all users.

List of pending negotiations that the user was involved

Leave feedback and review negotiation.

5 MODULES:

1. YOUR DATASETS INFORMATION: user manages his own data: register/review data , sets initial negotiation conditions.

2. Other’s DATASET INFORMATION: module lists all available data. User can view details

3. Query AVAILABLE DATASETS: support data query function.

4. YOUR PENDING NEGOTIATION: lists all ongoing negotiations user is involved in. CLICK “continue” to continue pending negotiations.

5. REVIEW NEGOTIATIONS: module lists all negotiations including the finished negotiations. User can review the negotiation process and give feedback when a negotiation process is done.

41

Register new dataset

By this interface, user can register a new dataset by submitting a data description.

42

Register negotiation conditions for dataset

User can register negotiation conditions by select items from the downlist menu. At the same time, user can define his own conditions.

43

Query data

Query data by submitting metadata description of needed data.

Dataset Details

Query

Query Result

44

Start Negotiation

As soon as the user finds the needed data, he can start the negotiation process using this interface.

Negotiation means changing condition values, adding new conditions, or both.

45

Negotiation process

After two rounds of negotiation, the owner and the requester reach an agreement on the data sharing conditions.

46

FeedbackFeedback information is important to requester because he can decide whether the data and the data owner are reliable or the owner has good reputation.

Efficiency: Apply restrictions on the negotiation process to

keep the parties from negotiating forever.

Security: One problem is that a party may want to decrypt the other party's negotiation strategy; mitigate problem by limiting length of negotiation.

However, a party may try to use different IDs to negotiate with a specific party; by combining information it collected from all negotiations, it may deduce useful information to decrypt the party's strategy.

Another common security problem, DDOS, is also a threat to our negotiation system.

47

Collaborative Automated Trust Negotiation

• Collaborative ATN = CATN• a multi-party extension of ATN (access

control policy for many peers at a time)– [Ye, Makedon, and Ford 2004]

• Uses "Locally Trusted Third Parties" (LTTPs) to help two primary parties

• Addresses deadlocks (cyclic dependencies) and efficiency issues

49

Example of an access policydisclosure sequence

There is at least one credential disclosure sequence that satisfies the access control policies and leads to a successful negotiation

Two peers, P1 and P2, have up to 5 credentials

We put curly brackets around the credentials disclosed by one peer as a unit

50

The Problem of Cyclic Interdependence

• Trust negotiations are not always successful

– A successful credential exchange sequence is not guaranteed to exist.

• Sometimes there are inherent conflicts, such as cyclic interdependence.

– P1 and P2 can not succeed in their trust negotiation as they have cyclically interdependent policies

• the existence of cyclic interdependent policy rules can cause a substantial number of failed trust negotiations in practice

51

Unsuccessful Trust Negotiation

Neither P1 nor P2 wants to disclose its C4 firstThe trust negotiation can not succeed because of the cyclic interdependence between credentials.

When the existing negotiation strategy can not continue, we apply apply a new approach that breaks the interdependency.

52

Collaborative Automated Trust Negotiation CATN: new approach

• If P1 and P2 are two such parties, a third party P3, trusted by both peers, can act as a mediator and disclose their credentials and policy rules to each other when appropriate

• A peer can act as a trusted third party for a limited number of peers in much the same way that a reputation-based system works

• We call such a peer a locally trusted third party= LTTP

53

LTTP

• Break Cyclic Interdependency with LTTP: locally trusted third party– Similar idea to a reputation system– disclose credentials and policy to each other when

appropriate and enable trust negotiation to succeed– Every peer can act as a trusted third party for a limited

number of other peers – Store the disclosed credentials from other peers with a

time limit (credentials do expire)– Disclose certain credentials when requested by their

owner • the peer that needs a LTTP can actively initiate a trust negotiation

to re-activate those credentials.

54

Example

• Suppose Alice and Bob are involved in a car incident.

• However, neither Alice nor Bob is willing to show the driver license/insurance card first.

• If a policeman Peter comes, and shows his police ID to both of them, then Alice and Bob can exchange their driver license and insurance information through Peter.

• Another example could be online transactions.

55

An LTTP acts as a mediator• An LTTP acts as a mediator in a negotiation

– If two peers can not achieve success in their trust negotiation due to cyclic credential interdependency, they ask help from an LTTP

– Each different peer has its own LTTPs– Before two peers ask help from an LTTP, they have

to find a common LTTP trusted by both of them• Each peer maintains a table of peers it has successfully

negotiated with– The size of the table could be very large– Problem: LTTP table maintenance since a peer may

not be able to record information for every peer it has negotiated with.

57

LTTP: Locally Trusted Third Party

• Originally introduced to break credential interdependencies– For Pi, an LTTP is a party that has

successfully finished a trust negotiation with Pi

• Example:

58

pLTTP: Partial LTTP

• Even if Pj has not succeeded in its trust negotiation with Pi , Pj can still possibly help Pi in trust negotiations– They may have exchanged credentials that

can be used to break credential interdependencies

• pLTTP is an extended and generalized version of LTTP

59

pLTTP Example

60

Advantages of pLTTPs

• Performance– Promote successful trust negotiations– Speed up trust building processes

• Security– Privacy

• Sensitive policies• Possession-sensitive credentials

– DDOS attacks

78

83

Trustworthy Recommendation Systems

1. Background

•Recommendation systems help with information overload

•They are highly useful components in SCENS and OC

2. Recommendation attacks

Push or Nuke attacks make items more or less popular than they truly are

3. Our approach to detecting attacks

Using a probabilistic approach to compute the degree of belief of a rating Pr(rating|model).

4. Possible extension

These techniques may be extended to detecting shilling attacks or collusions in reputation systems

84

Why Use Recommendation Systems?

• We have too much stuff around us– Books, movies, web pages…

• Recommendation systems help with information overload• However, should we trust their results?

85

Recommendation attacks• Push and Nuke attacks make items appear more or

less popular than they truly are

• Here, item Z will be “pushed” to Alice even though it is not actually a good option

86

Detecting Recommendation Attacks• Extract a model from the rating matrix• Using a probabilistic approach to compute the degree

of belief of a rating, Pr(rating|model).

87

Related Application:

Local Data Protection for In-Network Processing in Sensor Networks

1. Background

4. Advantages

1.Distributed history-data storageThe history data can be stored more securely locally on sensor nodes instead of in aggregators; this also distributes the burden of storing.

2. Forward-secure past data queries

Even if an adversary compromises the aggregation key between a sensor node and its aggregator, it can only get the data transmitted during the current time period.

2. ProblemExample needs:

• “What is the mean of the temperature from all sensors?”

• “What was the mean an hour ago?”

Assuming the base station does not have history data, we must query the sensor nodes again, and to execute past event queries, we must store temporary local data in sensor nodes

3. Past data recovery methods

1. Shares seed key with all neighbors (Shamir).

2. Evolves to a new key, deletes the old key (Forward Secure Mechanism).

89

• Information is processed within the network, and only the processed information is returned to the base station. This is called In-Network Processing or Aggregation.

• Nodes collecting raw data from sensors (S-node) and then returning the aggregated results to base station are called Aggregators (A-node).

• Example 1: Counting the number of nodes in a network of indeterminate size. A-nodes only return # of its children.

– Base node adds up all intermediate results from A-nodes.

• Example 2: Computing the average temperature of the area monitored by the network.

– The base station only gets one value from each of these aggregators, and no longer knows a specific value of a single node.

Local Data Protection for In-Network Processing in Sensor Neworks [ICPS05]

90

Problems: Past Event Queries & Storing History Data

• Examples:

– At time t1, what is mean of the temperature from all sensors?

– And later, at time t2, what is highest temperature of all sensors?

– But at current time t3, what is highest temperature of all sensors at previous time t1?

• Since the base station does not have history data, we must ask the sensor nodes again

• =>to execute past event queries, we must store temporary local data in sensor nodes

91

Protecting Local Data

• How can we protect the locally stored data when an s-node is physically compromised?– If a sensor node is physically captured, then all the data stored in this sensor

node are compromised.– If we encrypt the data with some keys but also store the keys locally, then the

adversary can get the keys and decrypt the local data. • => we cannot store the encryption keys locally - send elsewhere

• =>a method to escrow the keys to another place and only store the encrypted data locally.

– When the encrypted data needs to be decrypted, the sensor node gets the decryption key from other parties.

– Every time you query a sensor node, it needs to encrypt the data that it collected. – Since sensor nodes also need the key at any time point, apply forward security

mechanism.

92

Forward Security Mechanism Idea

1. The seed key is escrowed and you forget about it.2. Evolve the seed key to the second key which is in the sensor

node3. When you receive a query, then use the second key to

encrypt the data in the sensor4. Then, when you receive another query, you evolve the

second key to the third key and you delete the second keyn Thus:

n Each new key can’t be used to decrypt the data encrypted with the old key.

n At any time point, a sensor node only stores a current secret key and a bunch of data encrypted with previous keys which have been already deleted.

110

Future Work• Integrate tools into SCENS, our negotiation system• Develop more sophisticated group operations, such as

membership revocation, group dissolution, group merging, group nesting.

• Key management for OC, which can support selectively encrypted group profile dissemination.

• Improve our user interface to better help users write policies and recommend general policies for familiar credentials.

• Evaluation benchmarks– define attack models and prove our approaches are secure and

performance is not lowered by the cost introduced by encryption.– compare system with existing systems:

– Author-X [Bertino et. al. 01-04] – GSC [Nata-Rotaru and Li 04] – NGC [Ellison et. al 03]– Clinques [Steiner et. al. 00]– Secure Spread [Amir et. al. 03]