security and trust · several trust paths that link the trustor to the recommended trustee exist,...
TRANSCRIPT
![Page 1: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/1.jpg)
Security and Trust Gabriele Costa, Fabio Martinelli,
Ilaria Matteucci(IIT-CNR)
Valérie Issarny and Rachid Saadi(INRIA)
![Page 2: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/2.jpg)
Talk Outline
! Trust model interoperability (Rachid Saadi INRIA-Rocquencourt)
!Security-by-Contract-with-Trust (SxCxT) (Ilaria Matteucci IIT-CNR Pisa)
2
![Page 3: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/3.jpg)
Trust Outline
! Introduction
!Use case
! Trust meta-model
! Trust interoperability
3
![Page 4: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/4.jpg)
Introduction
! Trust management is becoming a central element in today’s open distributed digital environment
! However, existing trust management systems are application and domain dependent
! Hence they often implement different trust models
! As a result, it is really challenging to establish trust relationships across heterogeneous trust management systems
4
![Page 5: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/5.jpg)
Methodology
!A unified description for trust management systems:• A trust meta-model
!Automated mediation process that enables interoperability between trust models:• Trust model composition
5
![Page 6: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/6.jpg)
Outline
6
! Introduction
!Use case
! Trust meta-model
! Trust interoperability
![Page 7: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/7.jpg)
Use Case
7
![Page 8: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/8.jpg)
Use Case
7
![Page 9: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/9.jpg)
Use Case
8
![Page 10: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/10.jpg)
Use Case
8
![Page 11: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/11.jpg)
Use Case
9
![Page 12: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/12.jpg)
Use Case
11
Stadium Security Staff
![Page 13: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/13.jpg)
Use Case
12
Government Trust Model
Stadium Trust Model
GovernmentAgent
StadiumGuard
![Page 14: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/14.jpg)
Outline
13
! Introduction
!Use case
! Trust meta-model
! Trust interoperability
![Page 15: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/15.jpg)
Trust Meta Model
! As defined in [1]: A trustor trusts a trustee with regard to its ability to perform a specific action or to provide a specific service
! Hence, any trust model may basically be defined in terms of the four following elements:• Trust roles abstract the representative behaviors of
stakeholders• Trust metrics define how trust is measured • Trust relations specify trust relationships among stakeholders • Trust operations define how to compute and assess a
relationship
14
![Page 16: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/16.jpg)
! We formally define the trust meta-model as: • where:
• : set of roles• : set of metrics• : set of relations• : set of operations
• We note:• a value from the set
• e.g.,
• a disjunction of values from the set • e.g.,
• a conjunction of values from the set • e.g.,
TM =< R,M,L,O >
MLO
♦S
∧S
S
Trust Meta Model
15
R
s1 ∧ s2 ∧ s3/s1, s2, s3 ∈ S
s1 ∨ s2 ∨ s3/s1, s2, s3 ∈ S∨S
s1 ∈ SS
S
![Page 17: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/17.jpg)
Role Set ( )
! Formally, we define a role as: “r =< name::Id >”
! Stadium Trust model• The Guard: secures the stadium: rG=<name=Guard> • The Manager: manages the reputation of the Guards:
rM=<name=Manager> • The Chief: controls and evaluates the Guards: rC=<name=Chief>
! Government Trust model• The Agent: enforces the government law: rA=<name=Agent>• The Authority: agent’s headquarter (e.g., DGSE, MI6, CIA, etc.):
rT=<name=Authority>
16
R
![Page 18: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/18.jpg)
Metric Set( )
! Different metrics have been defined to measure trust
! There is no widely recognized way to assign trust values• Binary values • Semantic label (e.g., high trust, low trust etc.)• Numerical range (e.g., [-1,1], [0,n], [0,1], etc.)• In many dimensions (e.g., Belief, Disbelief, Uncertainty, etc.)
! Formally, we define a metric as: m=<name::Id, type::Id>
17
M
![Page 19: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/19.jpg)
Example of Trust Metric
!Stadium Trust model:• Guard reputation value: probabilistic value [0,1]
• i.e., mrep=<name=”Reputation”, type=”Probability”>• Chief rate: semantic label (Bonus, Penalty)
• i.e., mrat=<name=”Rate”, type= ”Labels”>
!Government Trust model• Accreditation levels: an integer interval of values [0..3]
• i.e., macc=<name=”Accreditation”, type=”Levels”>
18
![Page 20: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/20.jpg)
Relation Set ( )
In order to formalize trust relationships we first have to identify the different types of
relationships
19
L
![Page 21: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/21.jpg)
Trust Relation Types
20
Alice
Bob is my
friend
Direct Trust relationship
1:1
Bob
Indirect Trust relationship
N:1
1:N
1:1 1:1 1:1
1:1 1:1 1:1
Bob
Alice
1:1 1:11:1
Alice
Bob1:1
Transitive-basedTrust relationship
1:N
Reputation-basedTrust relationship
N:1
TR
1:1
(a) (b) (c)
Fig. 2: Trust Relations
– Transitive-based trust relations are one-to-many (denoted 1:N). Such a relation en-
ables 1 trustor (e.g., Alice in Fig. 2(B)) to indirectly assess the trustworthiness of an
unknown trustee (e.g., Bob in Fig. 2(B)) through the recommendations of a group of
trustees (N). Hence, the computation of 1:N relations results from the concatenation
and/or aggregation of many 1:1 trust relations (arrow T in Fig. 2). The concatena-
tion of 1:1 trust relations usually represents a transitive trust path, where each entity
can trust unknown entities based on the recommendation of its trustees. Thus, this
relationship is built by composing personal trust relations [13,14]. Furthermore, if
several trust paths that link the trustor to the recommended trustee exist, the ag-
gregation can be used to aggregate all given trust recommendations [15]. More
recently, this kind of relation gained importance by the emergence of WS composi-
tion to assess the trustworthiness of Web Services (WS) composition [16,17,18]. In
this case, the aggregation of sub-services recommendation allows defining the trust
recommendation for the whole composition.
– Reputation-based trust relations are many-to-one (denoted N:1). These relations
result from the aggregation of many personal trust relationships of recommenders
having the same trustee (see arrow R in Fig. 2). In other words, the a group of
recommenders (N ) trust a specific subject (e.g., Alice in Fig. 2(C)) to take their
personal opinions and to maintain and provide the reputation of trustees (e.g.,Bob in Fig. 2(C)). Such reputation can be used, by any entity as a reference, to
define its trust relation with unknown ones (e.g., “I trust you because of your goodreputation”,”I distrust you because of your bad reputation”, “I trust you less than
![Page 22: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/22.jpg)
Trust Relation Types
21
Alice
Bob is my
friend
Direct Trust relationship
1:1
Bob
Indirect Trust relationship
N:1
1:N
1:1 1:1 1:1
1:1 1:1 1:1
Bob
Alice
1:1 1:11:1
Alice
Bob1:1
Transitive-basedTrust relationship
1:N
Reputation-basedTrust relationship
N:1
TR
1:1
(a) (b) (c)
Fig. 2: Trust Relations
– Transitive-based trust relations are one-to-many (denoted 1:N). Such a relation en-
ables 1 trustor (e.g., Alice in Fig. 2(B)) to indirectly assess the trustworthiness of an
unknown trustee (e.g., Bob in Fig. 2(B)) through the recommendations of a group of
trustees (N). Hence, the computation of 1:N relations results from the concatenation
and/or aggregation of many 1:1 trust relations (arrow T in Fig. 2). The concatena-
tion of 1:1 trust relations usually represents a transitive trust path, where each entity
can trust unknown entities based on the recommendation of its trustees. Thus, this
relationship is built by composing personal trust relations [13,14]. Furthermore, if
several trust paths that link the trustor to the recommended trustee exist, the ag-
gregation can be used to aggregate all given trust recommendations [15]. More
recently, this kind of relation gained importance by the emergence of WS composi-
tion to assess the trustworthiness of Web Services (WS) composition [16,17,18]. In
this case, the aggregation of sub-services recommendation allows defining the trust
recommendation for the whole composition.
– Reputation-based trust relations are many-to-one (denoted N:1). These relations
result from the aggregation of many personal trust relationships of recommenders
having the same trustee (see arrow R in Fig. 2). In other words, the a group of
recommenders (N ) trust a specific subject (e.g., Alice in Fig. 2(C)) to take their
personal opinions and to maintain and provide the reputation of trustees (e.g.,Bob in Fig. 2(C)). Such reputation can be used, by any entity as a reference, to
define its trust relation with unknown ones (e.g., “I trust you because of your goodreputation”,”I distrust you because of your bad reputation”, “I trust you less than
![Page 23: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/23.jpg)
Direct Trust Relation(1:1 one-to-one)
! It is a one-to-one trust relation (denoted 1:1) since it defines a direct link from:• (1) trustor to (1) trustee
! one-to-one trust relations are maintained locally by trustors
! It represents the trustors’ opinion regarding their trustees:• Objective or Subjective
22
Alice
Bob is my
friend
Direct Trust relationship
1:1
Bob
Indirect Trust relationship
N:1
1:N
1:1 1:1 1:1
1:1 1:1 1:1
Bob
Alice
1:1 1:11:1
Alice
Bob1:1
Transitive-basedTrust relationship
1:N
Reputation-basedTrust relationship
N:1
TR
1:1
(a) (b) (c)
Fig. 2: Trust Relations
– Transitive-based trust relations are one-to-many (denoted 1:N). Such a relation en-
ables 1 trustor (e.g., Alice in Fig. 2(B)) to indirectly assess the trustworthiness of an
unknown trustee (e.g., Bob in Fig. 2(B)) through the recommendations of a group of
trustees (N). Hence, the computation of 1:N relations results from the concatenation
and/or aggregation of many 1:1 trust relations (arrow T in Fig. 2). The concatena-
tion of 1:1 trust relations usually represents a transitive trust path, where each entity
can trust unknown entities based on the recommendation of its trustees. Thus, this
relationship is built by composing personal trust relations [13,14]. Furthermore, if
several trust paths that link the trustor to the recommended trustee exist, the ag-
gregation can be used to aggregate all given trust recommendations [15]. More
recently, this kind of relation gained importance by the emergence of WS composi-
tion to assess the trustworthiness of Web Services (WS) composition [16,17,18]. In
this case, the aggregation of sub-services recommendation allows defining the trust
recommendation for the whole composition.
– Reputation-based trust relations are many-to-one (denoted N:1). These relations
result from the aggregation of many personal trust relationships of recommenders
having the same trustee (see arrow R in Fig. 2). In other words, the a group of
recommenders (N ) trust a specific subject (e.g., Alice in Fig. 2(C)) to take their
personal opinions and to maintain and provide the reputation of trustees (e.g.,Bob in Fig. 2(C)). Such reputation can be used, by any entity as a reference, to
define its trust relation with unknown ones (e.g., “I trust you because of your goodreputation”,”I distrust you because of your bad reputation”, “I trust you less than
![Page 24: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/24.jpg)
Direct Trust Relation(1:1 one-to-one)
! Belonging-driven relationship:• an employee trusts his company
! Social-driven relationship:• trust among friends
! Profit-driven relationship:• a person trusts a trader for managing his portfolio
! Quality-driven relationship:• a person with 15 years of experience
23
Alice
Bob is my
friend
Direct Trust relationship
1:1
Bob
Indirect Trust relationship
N:1
1:N
1:1 1:1 1:1
1:1 1:1 1:1
Bob
Alice
1:1 1:11:1
Alice
Bob1:1
Transitive-basedTrust relationship
1:N
Reputation-basedTrust relationship
N:1
TR
1:1
(a) (b) (c)
Fig. 2: Trust Relations
– Transitive-based trust relations are one-to-many (denoted 1:N). Such a relation en-
ables 1 trustor (e.g., Alice in Fig. 2(B)) to indirectly assess the trustworthiness of an
unknown trustee (e.g., Bob in Fig. 2(B)) through the recommendations of a group of
trustees (N). Hence, the computation of 1:N relations results from the concatenation
and/or aggregation of many 1:1 trust relations (arrow T in Fig. 2). The concatena-
tion of 1:1 trust relations usually represents a transitive trust path, where each entity
can trust unknown entities based on the recommendation of its trustees. Thus, this
relationship is built by composing personal trust relations [13,14]. Furthermore, if
several trust paths that link the trustor to the recommended trustee exist, the ag-
gregation can be used to aggregate all given trust recommendations [15]. More
recently, this kind of relation gained importance by the emergence of WS composi-
tion to assess the trustworthiness of Web Services (WS) composition [16,17,18]. In
this case, the aggregation of sub-services recommendation allows defining the trust
recommendation for the whole composition.
– Reputation-based trust relations are many-to-one (denoted N:1). These relations
result from the aggregation of many personal trust relationships of recommenders
having the same trustee (see arrow R in Fig. 2). In other words, the a group of
recommenders (N ) trust a specific subject (e.g., Alice in Fig. 2(C)) to take their
personal opinions and to maintain and provide the reputation of trustees (e.g.,Bob in Fig. 2(C)). Such reputation can be used, by any entity as a reference, to
define its trust relation with unknown ones (e.g., “I trust you because of your goodreputation”,”I distrust you because of your bad reputation”, “I trust you less than
![Page 25: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/25.jpg)
Indirect Trust Relationship
!As opposed to a direct trust relationship, indirect trust relationship enables assessing:• a priori unknown trustee • with third party’s recommendation(s)
! This can be either:• transitive-based • reputation-based
24
![Page 26: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/26.jpg)
Transitive-Based Trust Relationship(1:N one-to-many)
26
Alice
Bob is my
friend
Direct Trust relationship
1:1
Bob
Indirect Trust relationship
N:1
1:N
1:1 1:1 1:1
1:1 1:1 1:1
Bob
Alice
1:1 1:11:1
Alice
Bob1:1
Transitive-basedTrust relationship
1:N
Reputation-basedTrust relationship
N:1
TR
1:1
(a) (b) (c)
Fig. 2: Trust Relations
– Transitive-based trust relations are one-to-many (denoted 1:N). Such a relation en-
ables 1 trustor (e.g., Alice in Fig. 2(B)) to indirectly assess the trustworthiness of an
unknown trustee (e.g., Bob in Fig. 2(B)) through the recommendations of a group of
trustees (N). Hence, the computation of 1:N relations results from the concatenation
and/or aggregation of many 1:1 trust relations (arrow T in Fig. 2). The concatena-
tion of 1:1 trust relations usually represents a transitive trust path, where each entity
can trust unknown entities based on the recommendation of its trustees. Thus, this
relationship is built by composing personal trust relations [13,14]. Furthermore, if
several trust paths that link the trustor to the recommended trustee exist, the ag-
gregation can be used to aggregate all given trust recommendations [15]. More
recently, this kind of relation gained importance by the emergence of WS composi-
tion to assess the trustworthiness of Web Services (WS) composition [16,17,18]. In
this case, the aggregation of sub-services recommendation allows defining the trust
recommendation for the whole composition.
– Reputation-based trust relations are many-to-one (denoted N:1). These relations
result from the aggregation of many personal trust relationships of recommenders
having the same trustee (see arrow R in Fig. 2). In other words, the a group of
recommenders (N ) trust a specific subject (e.g., Alice in Fig. 2(C)) to take their
personal opinions and to maintain and provide the reputation of trustees (e.g.,Bob in Fig. 2(C)). Such reputation can be used, by any entity as a reference, to
define its trust relation with unknown ones (e.g., “I trust you because of your goodreputation”,”I distrust you because of your bad reputation”, “I trust you less than
! Trustor (1) trusts an unknown trustee through a group of trusted recommenders ??
![Page 27: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/27.jpg)
Transitive-Based Trust Relationship(1:N one-to-many)
• Trustees• The friend of my friend is my friend
• Similar trustees• The friend of my similar friend is my
friend • Enemies
• The enemy of my enemy is my friend
27
Alice
Bob is my
friend
Direct Trust relationship
1:1
Bob
Indirect Trust relationship
N:1
1:N
1:1 1:1 1:1
1:1 1:1 1:1
Bob
Alice
1:1 1:11:1
Alice
Bob1:1
Transitive-basedTrust relationship
1:N
Reputation-basedTrust relationship
N:1
TR
1:1
(a) (b) (c)
Fig. 2: Trust Relations
– Transitive-based trust relations are one-to-many (denoted 1:N). Such a relation en-
ables 1 trustor (e.g., Alice in Fig. 2(B)) to indirectly assess the trustworthiness of an
unknown trustee (e.g., Bob in Fig. 2(B)) through the recommendations of a group of
trustees (N). Hence, the computation of 1:N relations results from the concatenation
and/or aggregation of many 1:1 trust relations (arrow T in Fig. 2). The concatena-
tion of 1:1 trust relations usually represents a transitive trust path, where each entity
can trust unknown entities based on the recommendation of its trustees. Thus, this
relationship is built by composing personal trust relations [13,14]. Furthermore, if
several trust paths that link the trustor to the recommended trustee exist, the ag-
gregation can be used to aggregate all given trust recommendations [15]. More
recently, this kind of relation gained importance by the emergence of WS composi-
tion to assess the trustworthiness of Web Services (WS) composition [16,17,18]. In
this case, the aggregation of sub-services recommendation allows defining the trust
recommendation for the whole composition.
– Reputation-based trust relations are many-to-one (denoted N:1). These relations
result from the aggregation of many personal trust relationships of recommenders
having the same trustee (see arrow R in Fig. 2). In other words, the a group of
recommenders (N ) trust a specific subject (e.g., Alice in Fig. 2(C)) to take their
personal opinions and to maintain and provide the reputation of trustees (e.g.,Bob in Fig. 2(C)). Such reputation can be used, by any entity as a reference, to
define its trust relation with unknown ones (e.g., “I trust you because of your goodreputation”,”I distrust you because of your bad reputation”, “I trust you less than
! Trustor (1) trusts an unknown trustee through a group of trusted recommenders ??
![Page 28: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/28.jpg)
Reputation-Based Trust Relationship(N:1 many-to-one)
28
Alice
Bob is my
friend
Direct Trust relationship
1:1
Bob
Indirect Trust relationship
N:1
1:N
1:1 1:1 1:1
1:1 1:1 1:1
Bob
Alice
1:1 1:11:1
Alice
Bob1:1
Transitive-basedTrust relationship
1:N
Reputation-basedTrust relationship
N:1
TR
1:1
(a) (b) (c)
Fig. 2: Trust Relations
– Transitive-based trust relations are one-to-many (denoted 1:N). Such a relation en-
ables 1 trustor (e.g., Alice in Fig. 2(B)) to indirectly assess the trustworthiness of an
unknown trustee (e.g., Bob in Fig. 2(B)) through the recommendations of a group of
trustees (N). Hence, the computation of 1:N relations results from the concatenation
and/or aggregation of many 1:1 trust relations (arrow T in Fig. 2). The concatena-
tion of 1:1 trust relations usually represents a transitive trust path, where each entity
can trust unknown entities based on the recommendation of its trustees. Thus, this
relationship is built by composing personal trust relations [13,14]. Furthermore, if
several trust paths that link the trustor to the recommended trustee exist, the ag-
gregation can be used to aggregate all given trust recommendations [15]. More
recently, this kind of relation gained importance by the emergence of WS composi-
tion to assess the trustworthiness of Web Services (WS) composition [16,17,18]. In
this case, the aggregation of sub-services recommendation allows defining the trust
recommendation for the whole composition.
– Reputation-based trust relations are many-to-one (denoted N:1). These relations
result from the aggregation of many personal trust relationships of recommenders
having the same trustee (see arrow R in Fig. 2). In other words, the a group of
recommenders (N ) trust a specific subject (e.g., Alice in Fig. 2(C)) to take their
personal opinions and to maintain and provide the reputation of trustees (e.g.,Bob in Fig. 2(C)). Such reputation can be used, by any entity as a reference, to
define its trust relation with unknown ones (e.g., “I trust you because of your goodreputation”,”I distrust you because of your bad reputation”, “I trust you less than
! We can trust unknown trustees if they have a good reputation.
! We can distrust unknown trustees if they have a bad reputation.
! Recommenders (N) contribute with their feedbacks (sent to the trustor) to build the reputation of an unknown trustee (1)
![Page 29: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/29.jpg)
Reputation-Based Trust Relationship(N:1 many-to-one)
• Centralized (ebay like): • trusted central server
• Distributed:• randomly define the manager through a
hash function, e.g., CAN and Chord• replicate the reputation by defining
more than one manager
29
Alice
Bob is my
friend
Direct Trust relationship
1:1
Bob
Indirect Trust relationship
N:1
1:N
1:1 1:1 1:1
1:1 1:1 1:1
Bob
Alice
1:1 1:11:1
Alice
Bob1:1
Transitive-basedTrust relationship
1:N
Reputation-basedTrust relationship
N:1
TR
1:1
(a) (b) (c)
Fig. 2: Trust Relations
– Transitive-based trust relations are one-to-many (denoted 1:N). Such a relation en-
ables 1 trustor (e.g., Alice in Fig. 2(B)) to indirectly assess the trustworthiness of an
unknown trustee (e.g., Bob in Fig. 2(B)) through the recommendations of a group of
trustees (N). Hence, the computation of 1:N relations results from the concatenation
and/or aggregation of many 1:1 trust relations (arrow T in Fig. 2). The concatena-
tion of 1:1 trust relations usually represents a transitive trust path, where each entity
can trust unknown entities based on the recommendation of its trustees. Thus, this
relationship is built by composing personal trust relations [13,14]. Furthermore, if
several trust paths that link the trustor to the recommended trustee exist, the ag-
gregation can be used to aggregate all given trust recommendations [15]. More
recently, this kind of relation gained importance by the emergence of WS composi-
tion to assess the trustworthiness of Web Services (WS) composition [16,17,18]. In
this case, the aggregation of sub-services recommendation allows defining the trust
recommendation for the whole composition.
– Reputation-based trust relations are many-to-one (denoted N:1). These relations
result from the aggregation of many personal trust relationships of recommenders
having the same trustee (see arrow R in Fig. 2). In other words, the a group of
recommenders (N ) trust a specific subject (e.g., Alice in Fig. 2(C)) to take their
personal opinions and to maintain and provide the reputation of trustees (e.g.,Bob in Fig. 2(C)). Such reputation can be used, by any entity as a reference, to
define its trust relation with unknown ones (e.g., “I trust you because of your goodreputation”,”I distrust you because of your bad reputation”, “I trust you less than
! Recommenders (N) contribute with their feedbacks (sent to the trustor) to build the reputation of an unknown trustee (1)
![Page 30: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/30.jpg)
Relation Set ( )
! Recall: A trustor trusts a trustee with regard to its ability to perform a specific action or to provide a specific service
! Thus:• A relation set defines all the relations “l” as:
• A relation has a name and is defined within a specific context• A relation can be implemented by different trustors and
trustees (role)• A relation is evaluated by a specific metric • A relation has a type Tl={1:1, 1:N, N:1}
30
l =< name::Id, ctx::Id, type::♦T l, trustor::∨R, trustee::∨R, metric::♦M >
L
![Page 31: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/31.jpg)
Government (Distributed) Trust Model: "TMD"
Stadium (Centralized) Trust Model: "TMC"
RA=Agent
LtAA=1:N
RT= Authority LtTT=1:N
LdTA=1:1LdAT=1:1
RC=Chief
RM=Manager
RG=Guard
LdCM=1:1
LrMG=N:1
LdCM=1:1
LtCG=1:N
BA
LdCG=1:1
LdTT=1:1
LdAA=1:1
LtTA=1:N
Example of Trust Relation
31
![Page 32: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/32.jpg)
Government (Distributed) Trust Model: "TMD"
Stadium (Centralized) Trust Model: "TMC"
RA=Agent
LtAA=1:N
RT= Authority LtTT=1:N
LdTA=1:1LdAT=1:1
RC=Chief
RM=Manager
RG=Guard
LdCM=1:1
LrMG=N:1
LdCM=1:1
LtCG=1:N
BA
LdCG=1:1
LdTT=1:1
LdAA=1:1
LtTA=1:N
Example of Trust Relation
31
ldCM =< name = ”ServerRecommendation”, ctx = ”Security”,
type = ”1:1”, trustor = ”(rC ∨ rG)”, trustee = ”rM”,metric = ”mrec” >
![Page 33: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/33.jpg)
Operation Set ( )
! The operation set includes the operations that can be performed by an entity over relations to assess the trustworthiness of another entity
! We formally define an operation:
! Where • name identifies an operation• host specifies the role(s) that hosts (executes) the operation• input gives the trust relations that are required to perform an assessment
operation and the output gives the resulting trust relation• call denotes a continuation• type defines the type of operation
32
o =< name::Id, host::∨R, type::♦To, input::∧L, output::♦L, call::∧O >
O
![Page 34: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/34.jpg)
Operation Set ( )
! The operation set includes the operations that can be performed by an entity over relations to assess the trustworthiness of another entity
! We formally define an operation:
! Where • name identifies an operation• host specifies the role(s) that hosts (executes) the operation• input gives the trust relations that are required to perform an assessment
operation and the output gives the resulting trust relation• call denotes a continuation• type defines the type of operation ??
33
o =< name::Id, host::∨R, type::♦To, input::∧L, output::♦L, call::∧O >
O
![Page 35: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/35.jpg)
Trust Operation Types
34
Alice
Bob is my
friend
Direct Trust relationship
1:1
Bob
Indirect Trust relationship
N:1
1:N
1:1 1:1 1:1
1:1 1:1 1:1
Bob
Alice
1:1 1:11:1
Alice
Bob1:1
Transitive-basedTrust relationship
1:N
Reputation-basedTrust relationship
N:1
TR
1:1
(a) (b) (c)
Fig. 2: Trust Relations
– Transitive-based trust relations are one-to-many (denoted 1:N). Such a relation en-
ables 1 trustor (e.g., Alice in Fig. 2(B)) to indirectly assess the trustworthiness of an
unknown trustee (e.g., Bob in Fig. 2(B)) through the recommendations of a group of
trustees (N). Hence, the computation of 1:N relations results from the concatenation
and/or aggregation of many 1:1 trust relations (arrow T in Fig. 2). The concatena-
tion of 1:1 trust relations usually represents a transitive trust path, where each entity
can trust unknown entities based on the recommendation of its trustees. Thus, this
relationship is built by composing personal trust relations [13,14]. Furthermore, if
several trust paths that link the trustor to the recommended trustee exist, the ag-
gregation can be used to aggregate all given trust recommendations [15]. More
recently, this kind of relation gained importance by the emergence of WS composi-
tion to assess the trustworthiness of Web Services (WS) composition [16,17,18]. In
this case, the aggregation of sub-services recommendation allows defining the trust
recommendation for the whole composition.
– Reputation-based trust relations are many-to-one (denoted N:1). These relations
result from the aggregation of many personal trust relationships of recommenders
having the same trustee (see arrow R in Fig. 2). In other words, the a group of
recommenders (N ) trust a specific subject (e.g., Alice in Fig. 2(C)) to take their
personal opinions and to maintain and provide the reputation of trustees (e.g.,Bob in Fig. 2(C)). Such reputation can be used, by any entity as a reference, to
define its trust relation with unknown ones (e.g., “I trust you because of your goodreputation”,”I distrust you because of your bad reputation”, “I trust you less than
Bootstrapping Aggregation Concatenation Refreshing
One-to-One (1:1) X X
One-to-Many (1:N) X X
Many-to-One (N:1) X X X
Table 1: Trust assessment operations
[16]. Most existing solutions simply initialize trust relation with a fixed value (e.g.,
0.5 [6], a uniform Beta probabilistic distribution [8]). Other approaches include among
others: initializing existing trust relations according to given peers recommendations
[17]; applying a sorting mechanism instead of assigning fixed values [18]; and assess-
ing trustees into different contexts (e.g., fixing a car, babysitting, etc.) and then inferring
unknown trust values from known ones of similar or correlate contexts [16,2].
All the solutions dealing with 1:N trust assessment mainly define the concatenationand the aggregation operations, in order to concatenate and to aggregate trust recom-
mendations by computing the average [18], the minimum or the product [1] of all the
intermediary trust values. In the case of Web service composition, some approaches
(e.g., [15]) evaluate the recommendation for each service by evaluating its provider,
whereas other approaches (e.g., [11]) evaluate the service itself in terms of its previous
invocations, performance, reliability, etc. Then, trust is composed and/or aggregated ac-
cording to the service composition flow (sequence, concurrent, conditional and loop).
Aggregation operations such as Bayesian probability (e.g., [13]) are often used for
the assessment of N:1 (reputation-based) trust relations. Trust values are then repre-
sented by a beta Probability Density Function [8], which takes binary ratings as inputs
(i.e., positive or negative) from all trustors. Thus, the reputation score is refreshed from
the previous reputation score and the new rating [14]. The advantage of Bayesian sys-
tems is that they provide a theoretically sound basis for computing reputation scores
and can also be used to predict future behavior.
Finally, refreshing operations are mainly trigged by trustors to refresh 1:1 and N:1
trust relations, after receiving stakeholders’ feedback.
3 Trust Meta-Model
Following the above, we formally define the trust meta-model as: TM =< R,L,M,O >,
where R, L, M and O are the finite sets of trust roles, relations, metrics and operations.
3.1 Trust Meta-Model Formalization
As detailed below, each set of TM consists of elements where an element can have a
simple value (e.g., string) or a complex value. A complex value of an element is either
an exclusive combination of values (only one of the values) ∨v (e.g., v1∨v2∨v3) or an
inclusive combination of values (one or more elements) ✸v (e.g., v1 ∧ v2 ∧ (v3 ∨ v4))of elements.
![Page 36: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/36.jpg)
Trust Operation Types
35
Alice
Bob is my
friend
Direct Trust relationship
1:1
Bob
Indirect Trust relationship
N:1
1:N
1:1 1:1 1:1
1:1 1:1 1:1
Bob
Alice
1:1 1:11:1
Alice
Bob1:1
Transitive-basedTrust relationship
1:N
Reputation-basedTrust relationship
N:1
TR
1:1
(a) (b) (c)
Fig. 2: Trust Relations
– Transitive-based trust relations are one-to-many (denoted 1:N). Such a relation en-
ables 1 trustor (e.g., Alice in Fig. 2(B)) to indirectly assess the trustworthiness of an
unknown trustee (e.g., Bob in Fig. 2(B)) through the recommendations of a group of
trustees (N). Hence, the computation of 1:N relations results from the concatenation
and/or aggregation of many 1:1 trust relations (arrow T in Fig. 2). The concatena-
tion of 1:1 trust relations usually represents a transitive trust path, where each entity
can trust unknown entities based on the recommendation of its trustees. Thus, this
relationship is built by composing personal trust relations [13,14]. Furthermore, if
several trust paths that link the trustor to the recommended trustee exist, the ag-
gregation can be used to aggregate all given trust recommendations [15]. More
recently, this kind of relation gained importance by the emergence of WS composi-
tion to assess the trustworthiness of Web Services (WS) composition [16,17,18]. In
this case, the aggregation of sub-services recommendation allows defining the trust
recommendation for the whole composition.
– Reputation-based trust relations are many-to-one (denoted N:1). These relations
result from the aggregation of many personal trust relationships of recommenders
having the same trustee (see arrow R in Fig. 2). In other words, the a group of
recommenders (N ) trust a specific subject (e.g., Alice in Fig. 2(C)) to take their
personal opinions and to maintain and provide the reputation of trustees (e.g.,Bob in Fig. 2(C)). Such reputation can be used, by any entity as a reference, to
define its trust relation with unknown ones (e.g., “I trust you because of your goodreputation”,”I distrust you because of your bad reputation”, “I trust you less than
Bootstrapping Aggregation Concatenation Refreshing
One-to-One (1:1) X X
One-to-Many (1:N) X X
Many-to-One (N:1) X X X
Table 1: Trust assessment operations
[16]. Most existing solutions simply initialize trust relation with a fixed value (e.g.,
0.5 [6], a uniform Beta probabilistic distribution [8]). Other approaches include among
others: initializing existing trust relations according to given peers recommendations
[17]; applying a sorting mechanism instead of assigning fixed values [18]; and assess-
ing trustees into different contexts (e.g., fixing a car, babysitting, etc.) and then inferring
unknown trust values from known ones of similar or correlate contexts [16,2].
All the solutions dealing with 1:N trust assessment mainly define the concatenationand the aggregation operations, in order to concatenate and to aggregate trust recom-
mendations by computing the average [18], the minimum or the product [1] of all the
intermediary trust values. In the case of Web service composition, some approaches
(e.g., [15]) evaluate the recommendation for each service by evaluating its provider,
whereas other approaches (e.g., [11]) evaluate the service itself in terms of its previous
invocations, performance, reliability, etc. Then, trust is composed and/or aggregated ac-
cording to the service composition flow (sequence, concurrent, conditional and loop).
Aggregation operations such as Bayesian probability (e.g., [13]) are often used for
the assessment of N:1 (reputation-based) trust relations. Trust values are then repre-
sented by a beta Probability Density Function [8], which takes binary ratings as inputs
(i.e., positive or negative) from all trustors. Thus, the reputation score is refreshed from
the previous reputation score and the new rating [14]. The advantage of Bayesian sys-
tems is that they provide a theoretically sound basis for computing reputation scores
and can also be used to predict future behavior.
Finally, refreshing operations are mainly trigged by trustors to refresh 1:1 and N:1
trust relations, after receiving stakeholders’ feedback.
3 Trust Meta-Model
Following the above, we formally define the trust meta-model as: TM =< R,L,M,O >,
where R, L, M and O are the finite sets of trust roles, relations, metrics and operations.
3.1 Trust Meta-Model Formalization
As detailed below, each set of TM consists of elements where an element can have a
simple value (e.g., string) or a complex value. A complex value of an element is either
an exclusive combination of values (only one of the values) ∨v (e.g., v1∨v2∨v3) or an
inclusive combination of values (one or more elements) ✸v (e.g., v1 ∧ v2 ∧ (v3 ∨ v4))of elements.
![Page 37: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/37.jpg)
Trust Operation Types
36
Alice
Bob is my
friend
Direct Trust relationship
1:1
Bob
Indirect Trust relationship
N:1
1:N
1:1 1:1 1:1
1:1 1:1 1:1
Bob
Alice
1:1 1:11:1
Alice
Bob1:1
Transitive-basedTrust relationship
1:N
Reputation-basedTrust relationship
N:1
TR
1:1
(a) (b) (c)
Fig. 2: Trust Relations
– Transitive-based trust relations are one-to-many (denoted 1:N). Such a relation en-
ables 1 trustor (e.g., Alice in Fig. 2(B)) to indirectly assess the trustworthiness of an
unknown trustee (e.g., Bob in Fig. 2(B)) through the recommendations of a group of
trustees (N). Hence, the computation of 1:N relations results from the concatenation
and/or aggregation of many 1:1 trust relations (arrow T in Fig. 2). The concatena-
tion of 1:1 trust relations usually represents a transitive trust path, where each entity
can trust unknown entities based on the recommendation of its trustees. Thus, this
relationship is built by composing personal trust relations [13,14]. Furthermore, if
several trust paths that link the trustor to the recommended trustee exist, the ag-
gregation can be used to aggregate all given trust recommendations [15]. More
recently, this kind of relation gained importance by the emergence of WS composi-
tion to assess the trustworthiness of Web Services (WS) composition [16,17,18]. In
this case, the aggregation of sub-services recommendation allows defining the trust
recommendation for the whole composition.
– Reputation-based trust relations are many-to-one (denoted N:1). These relations
result from the aggregation of many personal trust relationships of recommenders
having the same trustee (see arrow R in Fig. 2). In other words, the a group of
recommenders (N ) trust a specific subject (e.g., Alice in Fig. 2(C)) to take their
personal opinions and to maintain and provide the reputation of trustees (e.g.,Bob in Fig. 2(C)). Such reputation can be used, by any entity as a reference, to
define its trust relation with unknown ones (e.g., “I trust you because of your goodreputation”,”I distrust you because of your bad reputation”, “I trust you less than
Bootstrapping Aggregation Concatenation Refreshing
One-to-One (1:1) X X
One-to-Many (1:N) X X
Many-to-One (N:1) X X X
Table 1: Trust assessment operations
[16]. Most existing solutions simply initialize trust relation with a fixed value (e.g.,
0.5 [6], a uniform Beta probabilistic distribution [8]). Other approaches include among
others: initializing existing trust relations according to given peers recommendations
[17]; applying a sorting mechanism instead of assigning fixed values [18]; and assess-
ing trustees into different contexts (e.g., fixing a car, babysitting, etc.) and then inferring
unknown trust values from known ones of similar or correlate contexts [16,2].
All the solutions dealing with 1:N trust assessment mainly define the concatenationand the aggregation operations, in order to concatenate and to aggregate trust recom-
mendations by computing the average [18], the minimum or the product [1] of all the
intermediary trust values. In the case of Web service composition, some approaches
(e.g., [15]) evaluate the recommendation for each service by evaluating its provider,
whereas other approaches (e.g., [11]) evaluate the service itself in terms of its previous
invocations, performance, reliability, etc. Then, trust is composed and/or aggregated ac-
cording to the service composition flow (sequence, concurrent, conditional and loop).
Aggregation operations such as Bayesian probability (e.g., [13]) are often used for
the assessment of N:1 (reputation-based) trust relations. Trust values are then repre-
sented by a beta Probability Density Function [8], which takes binary ratings as inputs
(i.e., positive or negative) from all trustors. Thus, the reputation score is refreshed from
the previous reputation score and the new rating [14]. The advantage of Bayesian sys-
tems is that they provide a theoretically sound basis for computing reputation scores
and can also be used to predict future behavior.
Finally, refreshing operations are mainly trigged by trustors to refresh 1:1 and N:1
trust relations, after receiving stakeholders’ feedback.
3 Trust Meta-Model
Following the above, we formally define the trust meta-model as: TM =< R,L,M,O >,
where R, L, M and O are the finite sets of trust roles, relations, metrics and operations.
3.1 Trust Meta-Model Formalization
As detailed below, each set of TM consists of elements where an element can have a
simple value (e.g., string) or a complex value. A complex value of an element is either
an exclusive combination of values (only one of the values) ∨v (e.g., v1∨v2∨v3) or an
inclusive combination of values (one or more elements) ✸v (e.g., v1 ∧ v2 ∧ (v3 ∨ v4))of elements.
![Page 38: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/38.jpg)
Bootstrapping
! Initially, a trust model evaluates trust relationships with a fixed value (often low)
! Infer unknown trust values from known ones of similar or correlative contexts
• If no prior related context exists, these solutions can not infer trust
! Infer trust by monitoring social activity (proximity)
37
![Page 39: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/39.jpg)
Concatenation & Aggregation
! The multiplication (value[0,1])
! The average
! The Belief model (Belief, Disbelief, Uncertainty)
! The Bayesian systems (binary rating: positive, negative)
! The fuzzy logic models (linguistically fuzzy concepts)
! The experience models (weight the present actions with respect to the past history):
38
Trust = α ∗ old+ (1− α) ∗ new
![Page 40: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/40.jpg)
Government (Distributed) Trust Model: "TMD"
Stadium (Centralized) Trust Model: "TMC"
RA=Agent
LtAA=1:N
RT= Authority LtTT=1:N
LdTA=1:1LdAT=1:1
RC=Chief
RM=Manager
RG=Guard
LdCM=1:1
LrMG=N:1
LdCM=1:1
LtCG=1:N
BA
LdCG=1:1
LdTT=1:1
LdAA=1:1
LtTA=1:N
Example of Operations
39
![Page 41: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/41.jpg)
Government (Distributed) Trust Model: "TMD"
Stadium (Centralized) Trust Model: "TMC"
RA=Agent
LtAA=1:N
RT= Authority LtTT=1:N
LdTA=1:1LdAT=1:1
RC=Chief
RM=Manager
RG=Guard
LdCM=1:1
LrMG=N:1
LdCM=1:1
LtCG=1:N
BA
LdCG=1:1
LdTT=1:1
LdAA=1:1
LtTA=1:N
Example of Operations
39
osCF =< name = ”setChiefFeedback”, host = ”rC”, type = ”Refreshing”,
out = ”ldCG”, call = ”oaGR” >
oaGR =< name = ”assessGuardReputation”, host = ”rM”, type = ”aggregation”,
in = ”ldCG”, out = ”lrMG”, call = ”osGR” >
osGR =< name = ”setGuardReputation”, host = rM , type = refreshing,
in = lrMG, out = lrMG >
![Page 42: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/42.jpg)
Outline
! Introduction
!Use case
! Trust meta-model
! Trust interoperability
40
![Page 43: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/43.jpg)
Trust Models Interoperability
! Objectives: • Interoperability
• Provide roles of a given model (target model TMT) the ability to assess roles that pertain to another trust model (source model TMS)
• For instance: • Guards should help Agents to find suspects. • This requires that any Agent be able to assess the accreditation of
Guards.
• Transparency
41
![Page 44: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/44.jpg)
Trust Models Interoperability
! Objectives: • Interoperability
• Provide roles of a given model (target model TMT) the ability to assess roles that pertain to another trust model (source model TMS)
• For instance: • Guards should help Agents to find suspects. • This requires that any Agent be able to assess the accreditation of
Guards.
• Transparency
41
Mapping rules
Mediation
![Page 45: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/45.jpg)
Trust Models Interoperability
! Objectives: • Interoperability
• Provide roles of a given model (target model TMT) the ability to assess roles that pertain to another trust model (source model TMS)
• For instance: • Guards should help Agents to find suspects. • This requires that any Agent be able to assess the accreditation of
Guards.
• Transparency
41
Mapping rules
MediationTrust model c
omposition
![Page 46: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/46.jpg)
Mapping Rule Set ( )
! Given two trust models: TMx and TMy
• Each mapping rule associates :• a source role (rs) with a target role (rt) • to define that the source role (rs) of (TMS) plays the target role (rt) in (TMT).
! For example:• The objective: an Agent has to check the accreditation of a Guard.• Guards are seen as Agents in the Government trust model.• The Guard will have to play the role of an Agent
• We note:
42
Ψxy = {ψkST /ψ
kST = (rs : TMS)� (rt : TMT )}
Where S, T ∈ {x, y}, S �= T
ψkST
(rG : TMC)� (rA : TMD)
6.3 Composing Trust Models
The aim of composing different trust models is to provide roles of a given model (which we call target
model T ) the ability to assess roles that pertains to another trust models (which we call source model
S). For instance, according to the terrorist alert scenario, Guards should help Policemen to find suspects.
This requires that any Policeman should be able to assess the accreditation of Guards. To do so, mapping
of roles from two distinct trust models (TMx and TMy) is explicitly defined through a set of mapping rules
Ψxy, as follows:
Ψxy = {ψkST /ψ
kST = (rs : TMS)� (rt : TMT )}
Where S, T ∈ {x, y}, S �= T(6.5)
Each mapping rule associates a source role with a target role so as to define that the source role rs of
TMS plays the target role rt in TMT . In fact, in order to initiate any relationship across trust models, roles
of different models have to be mapped into local roles, since roles of a given trust model are designed to
communicate only with roles from the same trust model. For instance, in order to enable Policemen to
assess Guards (see Figure 6.4, Step 1), we identify which role in the Policeman trust model corresponds
to the Guard. Intuitively, we can define the rule: (rG : TMC)� (rP : TMD), which means that Guards (i.e.,
rG : TMC) of the centralized trust model are seen by the distributed trust model (TMD) as Policemen(rP : TMD).
Given the specification of trust models, their composition relies on mapping their respective roles.
Then, the existing trust relations and operations are extended to relate roles from the composed models,
and new assessment operations are required to map trust relations from one model to another. Finally, the
resulting mapping and extensions are implemented through mediation [100] so as to make composition
transparent to existing systems, which leads us to introduce the corresponding mediator role.
Formally, the composition, denoted by�Ψxy
, of two trust models TMx and TMy, which introduces the
trust model TMxy, is defined as follows:
TMxy = TMx�Ψxy
TMy
= < Rx,Mx,Lx,Ox >�Ψxy
< Ry,My,Ly,Oy >
=
� Rxy = Rx ∪ Ry ∪ µRxy
Mxy = Mx ∪My
Lxy = L+x ∪ L
+y
Oxy = O+x ∪O
+y ∪ µOxy
� (6.6)
where:
• Ψxy is the set of mapping rules over roles that enables the composition of TMx and TMy;
• µRxy and µOxy are the new sets of mediator roles and mediation operations, respectively;
• (L+x and L
+y ) and (O+
x and O+y ) are the extended relations and operations, respectively.
As illustrated in Figure 6.4, the composition process is performed in two steps:
1. Role Mapping: Processes the mapping rules of Ψxy in order to enable the target model to manage
the source roles, for instance: the Guard is perceived as a trustee Policeman into the Police trust
model.
2. Recommendation mediation: If indirect relations are extended, we introduce a mediator to play the
role of a recommender from the target model, which is able to assess the source role from the
source trust model. For instance, the mediator can play the role of an Authority that recommends to
other Authorities, a given Guard, according to its reputation. To do so, the mediator will further play
the role of a Guard to retrieve that reputation.
In the following, we elaborate, role mapping and recommendation mediation to generate the sets of
mediator roles, and mediation operations (i.e., µRxy, and µOxy) and extended relations and operations
(i.e., L+x , L+
y , O+x , O+
y ).
CONNECT 231167 100/125
![Page 47: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/47.jpg)
Composition Process
43
Assess ? Agent Guard
Authority Chief
1
1- Mapping rule
![Page 48: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/48.jpg)
Composition Process
43
Assess ? Agent Guard
Authority Chief
1
Mediator2
2- Enable mediation with third party recommenders
1- Mapping rule
![Page 49: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/49.jpg)
! Formally, the composition, of TMx and TMy, based on the set of mapping rules !xy is defined as follows:
! is the set of the mediator roles! are the extended relations and operations,
respectively! is the set of mediation operations
Trust Model Composition
44
6.3 Composing Trust Models
The aim of composing different trust models is to provide roles of a given model (which we call target
model T ) the ability to assess roles that pertains to another trust models (which we call source model
S). For instance, according to the terrorist alert scenario, Guards should help Policemen to find suspects.
This requires that any Policeman should be able to assess the accreditation of Guards. To do so, mapping
of roles from two distinct trust models (TMx and TMy) is explicitly defined through a set of mapping rules
Ψxy, as follows:
Ψxy = {ψkST /ψ
kST = (rs : TMS)� (rt : TMT )}
Where S, T ∈ {x, y}, S �= T(6.5)
Each mapping rule associates a source role with a target role so as to define that the source role rs of
TMS plays the target role rt in TMT . In fact, in order to initiate any relationship across trust models, roles
of different models have to be mapped into local roles, since roles of a given trust model are designed to
communicate only with roles from the same trust model. For instance, in order to enable Policemen to
assess Guards (see Figure 6.4, Step 1), we identify which role in the Policeman trust model corresponds
to the Guard. Intuitively, we can define the rule: (rG : TMC)� (rP : TMD), which means that Guards (i.e.,
rG : TMC) of the centralized trust model are seen by the distributed trust model (TMD) as Policemen(rP : TMD).
Given the specification of trust models, their composition relies on mapping their respective roles.
Then, the existing trust relations and operations are extended to relate roles from the composed models,
and new assessment operations are required to map trust relations from one model to another. Finally, the
resulting mapping and extensions are implemented through mediation [100] so as to make composition
transparent to existing systems, which leads us to introduce the corresponding mediator role.
Formally, the composition, denoted by�Ψxy
, of two trust models TMx and TMy, which introduces the
trust model TMxy, is defined as follows:
TMxy = TMx�Ψxy
TMy
= < Rx,Mx,Lx,Ox >�Ψxy
< Ry,My,Ly,Oy >
=
� Rxy = Rx ∪ Ry ∪ µRxy
Mxy = Mx ∪My
Lxy = L+x ∪ L
+y
Oxy = O+x ∪O
+y ∪ µOxy
� (6.6)
where:
• Ψxy is the set of mapping rules over roles that enables the composition of TMx and TMy;
• µRxy and µOxy are the new sets of mediator roles and mediation operations, respectively;
• (L+x and L
+y ) and (O+
x and O+y ) are the extended relations and operations, respectively.
As illustrated in Figure 6.4, the composition process is performed in two steps:
1. Role Mapping: Processes the mapping rules of Ψxy in order to enable the target model to manage
the source roles, for instance: the Guard is perceived as a trustee Policeman into the Police trust
model.
2. Recommendation mediation: If indirect relations are extended, we introduce a mediator to play the
role of a recommender from the target model, which is able to assess the source role from the
source trust model. For instance, the mediator can play the role of an Authority that recommends to
other Authorities, a given Guard, according to its reputation. To do so, the mediator will further play
the role of a Guard to retrieve that reputation.
In the following, we elaborate, role mapping and recommendation mediation to generate the sets of
mediator roles, and mediation operations (i.e., µRxy, and µOxy) and extended relations and operations
(i.e., L+x , L+
y , O+x , O+
y ).
CONNECT 231167 100/125
6.3 Composing Trust Models
The aim of composing different trust models is to provide roles of a given model (which we call target
model T ) the ability to assess roles that pertains to another trust models (which we call source model
S). For instance, according to the terrorist alert scenario, Guards should help Policemen to find suspects.
This requires that any Policeman should be able to assess the accreditation of Guards. To do so, mapping
of roles from two distinct trust models (TMx and TMy) is explicitly defined through a set of mapping rules
Ψxy, as follows:
Ψxy = {ψkST /ψ
kST = (rs : TMS)� (rt : TMT )}
Where S, T ∈ {x, y}, S �= T(6.5)
Each mapping rule associates a source role with a target role so as to define that the source role rs of
TMS plays the target role rt in TMT . In fact, in order to initiate any relationship across trust models, roles
of different models have to be mapped into local roles, since roles of a given trust model are designed to
communicate only with roles from the same trust model. For instance, in order to enable Policemen to
assess Guards (see Figure 6.4, Step 1), we identify which role in the Policeman trust model corresponds
to the Guard. Intuitively, we can define the rule: (rG : TMC)� (rP : TMD), which means that Guards (i.e.,
rG : TMC) of the centralized trust model are seen by the distributed trust model (TMD) as Policemen(rP : TMD).
Given the specification of trust models, their composition relies on mapping their respective roles.
Then, the existing trust relations and operations are extended to relate roles from the composed models,
and new assessment operations are required to map trust relations from one model to another. Finally, the
resulting mapping and extensions are implemented through mediation [100] so as to make composition
transparent to existing systems, which leads us to introduce the corresponding mediator role.
Formally, the composition, denoted by�Ψxy
, of two trust models TMx and TMy, which introduces the
trust model TMxy, is defined as follows:
TMxy = TMx�Ψxy
TMy
= < Rx,Mx,Lx,Ox >�Ψxy
< Ry,My,Ly,Oy >
=
� Rxy = Rx ∪ Ry ∪ µRxy
Mxy = Mx ∪My
Lxy = L+x ∪ L
+y
Oxy = O+x ∪O
+y ∪ µOxy
� (6.6)
where:
• Ψxy is the set of mapping rules over roles that enables the composition of TMx and TMy;
• µRxy and µOxy are the new sets of mediator roles and mediation operations, respectively;
• (L+x and L
+y ) and (O+
x and O+y ) are the extended relations and operations, respectively.
As illustrated in Figure 6.4, the composition process is performed in two steps:
1. Role Mapping: Processes the mapping rules of Ψxy in order to enable the target model to manage
the source roles, for instance: the Guard is perceived as a trustee Policeman into the Police trust
model.
2. Recommendation mediation: If indirect relations are extended, we introduce a mediator to play the
role of a recommender from the target model, which is able to assess the source role from the
source trust model. For instance, the mediator can play the role of an Authority that recommends to
other Authorities, a given Guard, according to its reputation. To do so, the mediator will further play
the role of a Guard to retrieve that reputation.
In the following, we elaborate, role mapping and recommendation mediation to generate the sets of
mediator roles, and mediation operations (i.e., µRxy, and µOxy) and extended relations and operations
(i.e., L+x , L+
y , O+x , O+
y ).
CONNECT 231167 100/125
(L+x ,L
+y ), (O
+x ,O
+y )
6.3 Composing Trust Models
The aim of composing different trust models is to provide roles of a given model (which we call target
model T ) the ability to assess roles that pertains to another trust models (which we call source model
S). For instance, according to the terrorist alert scenario, Guards should help Policemen to find suspects.
This requires that any Policeman should be able to assess the accreditation of Guards. To do so, mapping
of roles from two distinct trust models (TMx and TMy) is explicitly defined through a set of mapping rules
Ψxy, as follows:
Ψxy = {ψkST /ψ
kST = (rs : TMS)� (rt : TMT )}
Where S, T ∈ {x, y}, S �= T(6.5)
Each mapping rule associates a source role with a target role so as to define that the source role rs of
TMS plays the target role rt in TMT . In fact, in order to initiate any relationship across trust models, roles
of different models have to be mapped into local roles, since roles of a given trust model are designed to
communicate only with roles from the same trust model. For instance, in order to enable Policemen to
assess Guards (see Figure 6.4, Step 1), we identify which role in the Policeman trust model corresponds
to the Guard. Intuitively, we can define the rule: (rG : TMC)� (rP : TMD), which means that Guards (i.e.,
rG : TMC) of the centralized trust model are seen by the distributed trust model (TMD) as Policemen(rP : TMD).
Given the specification of trust models, their composition relies on mapping their respective roles.
Then, the existing trust relations and operations are extended to relate roles from the composed models,
and new assessment operations are required to map trust relations from one model to another. Finally, the
resulting mapping and extensions are implemented through mediation [100] so as to make composition
transparent to existing systems, which leads us to introduce the corresponding mediator role.
Formally, the composition, denoted by�Ψxy
, of two trust models TMx and TMy, which introduces the
trust model TMxy, is defined as follows:
TMxy = TMx�Ψxy
TMy
= < Rx,Mx,Lx,Ox >�Ψxy
< Ry,My,Ly,Oy >
=
� Rxy = Rx ∪ Ry ∪ µRxy
Mxy = Mx ∪My
Lxy = L+x ∪ L
+y
Oxy = O+x ∪O
+y ∪ µOxy
� (6.6)
where:
• Ψxy is the set of mapping rules over roles that enables the composition of TMx and TMy;
• µRxy and µOxy are the new sets of mediator roles and mediation operations, respectively;
• (L+x and L
+y ) and (O+
x and O+y ) are the extended relations and operations, respectively.
As illustrated in Figure 6.4, the composition process is performed in two steps:
1. Role Mapping: Processes the mapping rules of Ψxy in order to enable the target model to manage
the source roles, for instance: the Guard is perceived as a trustee Policeman into the Police trust
model.
2. Recommendation mediation: If indirect relations are extended, we introduce a mediator to play the
role of a recommender from the target model, which is able to assess the source role from the
source trust model. For instance, the mediator can play the role of an Authority that recommends to
other Authorities, a given Guard, according to its reputation. To do so, the mediator will further play
the role of a Guard to retrieve that reputation.
In the following, we elaborate, role mapping and recommendation mediation to generate the sets of
mediator roles, and mediation operations (i.e., µRxy, and µOxy) and extended relations and operations
(i.e., L+x , L+
y , O+x , O+
y ).
CONNECT 231167 100/125
![Page 50: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/50.jpg)
! Extend trust relations according to the mapping rule
Government (Distributed) Trust Model: "TMD"
Stadium (Centralized) Trust Model: "TMC"
RA=Agent
LtAA=1:N
RT= Authority LtTT=1:N
LdTA=1:1LdAT=1:1
RC=Chief
RM=Manager
RG=Guard
LdCM=1:1
LrMG=N:1
LdCM=1:1
LtCG=1:N
BA
LdCG=1:1
LdTT=1:1
LdAA=1:1
LtTA=1:N
Composition Process (Step 1)
45
ltAA =< name = ”RemoteTrustAgent”, ctx = ”Security”, type = ”1:N”,
trustor = ”rA”, trustee = ”rA”,metric = ”mAcc” >
![Page 51: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/51.jpg)
! Extend trust relations according to the mapping rule
Government (Distributed) Trust Model: "TMD"
Stadium (Centralized) Trust Model: "TMC"
RA=Agent
LtAA=1:N
RT= Authority LtTT=1:N
LdTA=1:1LdAT=1:1
RC=Chief
RM=Manager
RG=Guard
LdCM=1:1
LrMG=N:1
LdCM=1:1
LtCG=1:N
BA
LdCG=1:1
LdTT=1:1
LdAA=1:1
LtTA=1:N
Composition Process (Step 1)
45
(rG : TMC)� (rA : TMD)
ltAA =< name = ”RemoteTrustAgent”, ctx = ”Security”, type = ”1:N”,
trustor = ”rA”, trustee = ”rA”,metric = ”mAcc” >
![Page 52: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/52.jpg)
! Extend trust relations according to the mapping rule
Government (Distributed) Trust Model: "TMD"
Stadium (Centralized) Trust Model: "TMC"
RA=Agent
LtAA=1:N
RT= Authority LtTT=1:N
LdTA=1:1LdAT=1:1
RC=Chief
RM=Manager
RG=Guard
LdCM=1:1
LrMG=N:1
LdCM=1:1
LtCG=1:N
BA
LdCG=1:1
LdTT=1:1
LdAA=1:1
LtTA=1:N
Composition Process (Step 1)
46
(rG : TMC)� (rA : TMD)
ltAA =< name = ”RemoteTrustAgent”, ctx = ”Security”, type = ”1:N”,
trustor = ”rA”, trustee = ”rA ∨ rG”,metric = ”mAcc” >
LtAA
![Page 53: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/53.jpg)
Composition Process (Step 2)
47
Assess ? Agent Guard
Authority Chief
1
Mediator2
Requesterrole
Recommenderrole
![Page 54: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/54.jpg)
Government (Distributed) Trust Model: "TMD"
Stadium (Centralized) Trust Model: "TMC"
RA=Agent
LtAA=1:N
RT= Authority LtTT=1:N
LdTA=1:1LdAT=1:1
RC=Chief
RM=Manager
RG=Guard
LdCM=1:1
LrMG=N:1
LdCM=1:1
LtCG=1:N
BA
LdCG=1:1
LdTT=1:1
LdAA=1:1
LtTA=1:N
Composition Process (Step 2)
48
Requester
role
Recommenderrole
![Page 55: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/55.jpg)
Government (Distributed) Trust Model: "TMD"
Stadium (Centralized) Trust Model: "TMC"
RA=Agent
LtAA=1:N
RT= Authority LtTT=1:N
LdTA=1:1LdAT=1:1
RC=Chief
RM=Manager
RG=Guard
LdCM=1:1
LrMG=N:1
LdCM=1:1
LtCG=1:N
BA
LdCG=1:1
LdTT=1:1
LdAA=1:1
LtTA=1:N
Composition Process (Step 2)
48
Requester
role✓
Recommenderrole
Similarity
![Page 56: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/56.jpg)
Government (Distributed) Trust Model: "TMD"
Stadium (Centralized) Trust Model: "TMC"
RA=Agent
LtAA=1:N
RT= Authority LtTT=1:N
LdTA=1:1LdAT=1:1
RC=Chief
RM=Manager
RG=Guard
LdCM=1:1
LrMG=N:1
LdCM=1:1
LtCG=1:N
BA
LdCG=1:1
LdTT=1:1
LdAA=1:1
LtTA=1:N
Composition Process (Step 2)
49
Requestor
role✓
Recommenderrole
ocRP =< name = ”concatRemoteAgent”, host = rA, type = concatenation,
in = ldAT ∧ ltTA, out = ltAA >Concatenation operation
![Page 57: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/57.jpg)
Government (Distributed) Trust Model: "TMD"
Stadium (Centralized) Trust Model: "TMC"
RA=Agent
LtAA=1:N
RT= Authority LtTT=1:N
LdTA=1:1LdAT=1:1
RC=Chief
RM=Manager
RG=Guard
LdCM=1:1
LrMG=N:1
LdCM=1:1
LtCG=1:N
BA
LdCG=1:1
LdTT=1:1
LdAA=1:1
LtTA=1:N
Composition Process (Step 2)
49
Requestor
role✓
Recommenderrole
ocRP =< name = ”concatRemoteAgent”, host = rA, type = concatenation,
in = ldAT ∧ ltTA, out = ltAA >Concatenation operation
✓
![Page 58: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/58.jpg)
Government (Distributed) Trust Model: "TMD"
Stadium (Centralized) Trust Model: "TMC"
RA=Agent
LtAA=1:N
RT= Authority LtTT=1:N
LdTA=1:1LdAT=1:1
RC=Chief
RM=Manager
RG=Guard
LdCM=1:1
LrMG=N:1
LdCM=1:1
LtCG=1:N
BA
LdCG=1:1
LdTT=1:1
LdAA=1:1
LtTA=1:NRequester
role✓
Recommenderrole✓
Composition Process (Step 3)
! Extend all the operations that are performed by the requestor and the recommender to the mediator (extend the host attribute)
! Enhance the mediator with mediation operations to link operations and to translate metrics’ value (extend the call attribute)
50
! Extend all relations that sink in the recommender role to sink in the mediator (extend the trustee attribute)
! Extend all relations that start from the requestor to also start from the mediator (extend the trustor attribute)
![Page 59: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/59.jpg)
Trust Conclusion
! We defined a meta-model and illustrate its expressivity over a centralized and a distributed scenario
! We presented an automated trust model composition with mediation
! Heterogeneous networked systems are able to assess each other
! Security-by-Contract can be extended with Trust for guaranteeing more efficient run-time security
51
![Page 60: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/60.jpg)
Security Outline
! Security-by-Contract (SxC)• Contract definition• Policy definition• SxC architecture
! Extending SxC with Trust (SxCxT)• Trust management module• Contract monitoring• SxCxT architecture
! Application to the CONNECT world! Conclusion
52
![Page 61: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/61.jpg)
Contract
A contract is a formal complete andcorrect specification of the behavior ofthe application for what concernsrelevant security actions (e.g., VirtualMachine API call, Operating SystemCalls). It defines a subset of the traces ofall possible security actions.
![Page 62: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/62.jpg)
Policy
A policy is a formal completespecification of the acceptablebehavior of applications to beexecuted on the platform for whatconcerns relevant security actions(e.g., Virtual Machine API call,Operating System Calls).It defines a subset of the traces ofall possible security actions.
![Page 63: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/63.jpg)
Security-By-Contract (SxC)
![Page 64: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/64.jpg)
Security-By-Contract (SxC)
The main goal is to ensure that the application satisfies the policy!
![Page 65: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/65.jpg)
Security-By-Contract (SxC)
The main goal is to ensure that the application satisfies the policy!
Two ways:
![Page 66: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/66.jpg)
Security-By-Contract (SxC)
The main goal is to ensure that the application satisfies the policy!
Two ways:1.The application satisfies the contract and the contract adheres to the policy. Then the application can be safely executed with further controls.
![Page 67: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/67.jpg)
Security-By-Contract (SxC)
The main goal is to ensure that the application satisfies the policy!
Two ways:1.The application satisfies the contract and the contract adheres to the policy. Then the application can be safely executed with further controls.
• How to check that the code adheres to the contract and the contract to the policy: (Abstract interpretation, Model checking, Trust)
![Page 68: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/68.jpg)
Security-By-Contract (SxC)
The main goal is to ensure that the application satisfies the policy!
Two ways:1.The application satisfies the contract and the contract adheres to the policy. Then the application can be safely executed with further controls.
• How to check that the code adheres to the contract and the contract to the policy: (Abstract interpretation, Model checking, Trust)
2.The application does not satisfy the contract, or the contract does not adhere to the policy, the policy is directly enforced at run-time.
![Page 69: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/69.jpg)
SxC Architecture
Two approaches:
• Prior midlet execution at deployment time (Verification of code/policy
compliance through contracts)• During midlet execution (run-time
enforcement)
6
![Page 70: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/70.jpg)
Verification at Deployment Time
Basically, we check on device two facts:The code is compliant with the contract
This can be done in several waysProof carrying code, trust on code/contract
signer The contract is compliant with the local policy
We check that one process simulates the other by using symbolic simulation techniques
![Page 71: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/71.jpg)
Contract-Policy Matching
The idea underlying contract-policy matching is thatany sequence of security relevant actions allowed by thecontract is also allowed by the policy.
![Page 72: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/72.jpg)
Contract-Policy Matching
The idea underlying contract-policy matching is thatany sequence of security relevant actions allowed by thecontract is also allowed by the policy.
!"#$%&'
![Page 73: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/73.jpg)
Contract-Policy Simulation Matching
We use simulation relation for contract-policymatching.
A contract transition system is simulated by apolicy one, if, for each transition corresponding to acertain security action of the contract (and sopossibly performed by the program), the policy has asimilar transition and resulting contract system is yet simulated by the resulting policy one.
![Page 74: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/74.jpg)
Security-By-ContractTwo ways:
1. The applet satisfies the contract and the contract adheres to the policy. Then the applet can be safely executed;
2. The applet does not satisfy the contract, or the contract does not adhere to the policy, the policy is directly enforced at run time.
One crucial point is the checking of the satisfactionthat the applet satisfies the contract:
• Abstract interpretation• Model checking• Simply trust on the a third party that certify that the applet satisfies
the contract (in the simplest case the certifier is actually the code provider).
![Page 75: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/75.jpg)
Why SxCxT?
In the SxC paradigm, the mobile code is runif its origin is trusted.SxCxT extends it by adding a component forthe contract monitoring that allows us tocheck if the execution of the applicationadheres to its contract and, according tothe answer, we update the level of trust ofthe provider.
11
![Page 76: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/76.jpg)
How SxCxT Extends SxCThe S!C!T paradigm extends the S!C in two phases:
at deploy-time by setting the monitoring state at run-time by applying the contract monitoring procedure
for adjusting the provider trust level
The SxCxT has two new modules:a run-time contract monitoring for allowing to manage
applications trust level anda trust management mechanism able to guarantee that a
mobile application can be safely executed on mobile devices, according to trust recommendations.
![Page 77: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/77.jpg)
Security-by-Contract with Trust Architecture
Security-by-Contract-with-Trust
Each Networked System runs its own part of the CONNECTor. Two possible scenarios arise:• the NSs are provided of the Security-by-Contract-with-Trust (×C×T for short) mechanism.• the NSs are not provided of the S×C×T. In this case we are in the same case of the centralized on
that we describe later because we do not have any possibility of controlling the code that run on theNSs
In the following we consider the first case, i.e., that the NSs are able to run the S×C×T for enforcingsecurity policies. In particular, the S×C×T paradigm is applied for guaranteeing at run-time that:
• local private policies, that are not shared neither with the CONNECT infrastructure, are satisfied.Example of local private policies are private policies regarding, for instance the GPS coordinates ofthe NS itself, the right for accessing to the private data stored on the device of the NS, and so on.
• none NS tries to attack the other NS by manipulating the part of the CONNECTor running on it.Indeed, let us suppose that one of the two NS is a malicious agent. When it receives the part ofCONNECTor that it is in charge to run, the NS manipulates it in order to attack the other NS duringthe communication.
In both these cases, even if the CONNECTor is synthesized in such a way it is not malicious, once it isdeployed on a possible malicious platform, the CONNECTor becomes a possible malicious agent. Underthis assumption, each NS able to run the S×C×T paradigm can enforce its own private and public securitypolicies. Here we briefly describe how the S×C×T paradigm works.
The S×C×T Workflow The S×C×T workflow [38, 37] results as in Figure 7.1. It consists of the followingsteps:
Matchcontract& Policy
Y
N
TrustedApplication
YN
Start
Enforcepolicy &monitorcontract
Monitorcontract
Scenario MC
Execu
teApplicatio
n
Scenario EPMC
STEP 1 STEP 2
Figure 7.1: The Extended Security-by-Contract Application Workflow
• Step 1-Trust Assessment: Once (part of) the CONNECTor is downloaded on each NetworkedSystem, before executing it, the trust module decides if it trusts or not that the execution of theCONNECTor satisfies its contract. Since NSs may implement different trust models, we apply thetrust model composition introduced in Chapter 6. So that, both NSs that aim at being connected canassess the trustworthiness of each other
• Step 2-Contract Driven Deployment: According to this trust measure, the security module decidesif just monitoring the contract (Scenario MC, where MC stands for Monitor of the Contract) or bothenforcing the policy and monitoring1 the contract (Scenario EPMC, where EPMC stands for Enforcethe Policy and Monitor the Contract), thus going into one on the scenarios described in Step 3.Indeed, we have two cases:
1Note that the the monitoring mechanisms referred here is different from the one described in Chapter 5. Indeed, it is an activeand synchronous run-time monitoring running by the NS itself and it is not run by the monitoring enabler.
CONNECT 231167 112/125
![Page 78: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/78.jpg)
SxCxT Steps (1)
Step 1- Trust Assessment: Once a mobile application is downloaded on the mobile device, before executing it, the trust module decides if it is trusted or not according to a fixed trust threshold.
Step 2- Contract Driven Deployment: According to this trust measure, the security module defines if just monitoring the contract or both enforce the policy and monitoring the contract.
![Page 79: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/79.jpg)
SxCxT steps (2)
Step 3 -Contract Monitoring vs Policy Enforcement Scenarios: Depending on the chosen scenario the security module is in charge to monitor either the policy or the contract and save the execution traces (logs).
Step 4- Trust Feedback Inference: Finally, the trust module parses the S×C×T produced logs and infers trust feedback.
![Page 80: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/80.jpg)
MC Scenario (1)
Scenario MC: The contract satisfies the policy. Only the contract is monitored, i.e., we check is he
execution adheres to the contractunder these conditions, contract adherence also implies policy
compliance.
If no violation is detected then the application worked as expected.
If there is a violation, this means that a trusted party provided us with a fake contract.
Our framework reacts to this event by updating the level of trust of the provider and switching to the policy enforcement modality.
16
![Page 81: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/81.jpg)
MC Scenario (2)
17
Scenario MC The contract satisfies the policy. In this case our monitoring/enforcement infras-tructure is required to monitor only the CONNECTor contract. Indeed, under these conditions,contract adherence also implies policy compliance. If no violation is detected then the CON-NECTor worked as expected. Otherwise, we discovered that a trusted party provided us with afake contract. The CONNECT infrastructure reacts to this event by reducing the level of trust ofthe indicted provider and switching to the policy enforcement modality.
Scenario EPMC The contract does not satisfy the policy. Since the contract declares some po-tentially undesired behaviour, policy enforcement is turned on. Similarly to a pure enforcementframework, our system guarantees that executions are policy-compliant. However, monitoringcontract during these executions can provide a useful feedback for better tuning the trust vector.Hence, our framework also allows for a mixed monitoring and enforcement configuration. Thisconfiguration is activated on a statistical base.
Let us notice that, in both the previous scenarios, contract monitoring plays a central role. Indeed, acontract violation denotes that a trusted provider released a fake contract.
• Step 3-Contract Monitoring vs Policy Enforcement Scenarios: Depending on the chosen sce-nario the security module is in charge to monitor either the policy or the contract and save theexecution traces (logs).
• Step 4-Trust Feedback Inference: Finally, the trust module parses the S×C×T produced logs andinfers trust feedback.
RU
NN
ING
Applic
atio
n
CaptureEvent
ContinueExecution
RaiseSecurityException
CHECKCONTRACTVIOLATION
Y
N
UpdateTrust
UpdateMonitorState
EnforcePolicy
CheckPolicy
Violation
N
Y
STEP 3 STEP 4
Figure 7.2: The Contract Monitoring Configuration in the MC Scenario
RU
NN
ING
Applic
atio
n
CaptureEvent
ContinueExecution
RaiseSecurityException
CHECKCONTRACTVIOLATION
Y
N
UpdateTrust
UpdateMonitorState
CheckPolicy
Violation
N
Y
STEP 4 STEP 3
Figure 7.3: The Contract Monitoring Configuration in the EPMC Scenario
Trust measures assigned to security assertions can be adjusted as a result of a contract monitoringstrategy. Indeed, trust measures associated with the NS concern on the contract goodness mainly. Up-dated trust measures will influence on future interactions of the CONNECT infrastructure with that particular
CONNECT 231167 113/125
![Page 82: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/82.jpg)
EPMC Scenario (1)
Scenario EPMC: The contract does not satisfy the policy. policy enforcement is turned on Monitoring contract is turned on
It provides a useful feedback for better tuning the trust vector.
Our framework also allows for a mixed monitoring and enforcement configuration.
This configuration is activated on a statistical base.
18
![Page 83: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/83.jpg)
EPMC Scenario (2)
19
Scenario MC The contract satisfies the policy. In this case our monitoring/enforcement infras-tructure is required to monitor only the CONNECTor contract. Indeed, under these conditions,contract adherence also implies policy compliance. If no violation is detected then the CON-NECTor worked as expected. Otherwise, we discovered that a trusted party provided us with afake contract. The CONNECT infrastructure reacts to this event by reducing the level of trust ofthe indicted provider and switching to the policy enforcement modality.
Scenario EPMC The contract does not satisfy the policy. Since the contract declares some po-tentially undesired behaviour, policy enforcement is turned on. Similarly to a pure enforcementframework, our system guarantees that executions are policy-compliant. However, monitoringcontract during these executions can provide a useful feedback for better tuning the trust vector.Hence, our framework also allows for a mixed monitoring and enforcement configuration. Thisconfiguration is activated on a statistical base.
Let us notice that, in both the previous scenarios, contract monitoring plays a central role. Indeed, acontract violation denotes that a trusted provider released a fake contract.
• Step 3-Contract Monitoring vs Policy Enforcement Scenarios: Depending on the chosen sce-nario the security module is in charge to monitor either the policy or the contract and save theexecution traces (logs).
• Step 4-Trust Feedback Inference: Finally, the trust module parses the S×C×T produced logs andinfers trust feedback.
RU
NN
ING
Applic
atio
n
CaptureEvent
ContinueExecution
RaiseSecurityException
CHECKCONTRACTVIOLATION
Y
N
UpdateTrust
UpdateMonitorState
EnforcePolicy
CheckPolicy
Violation
N
Y
STEP 3 STEP 4
Figure 7.2: The Contract Monitoring Configuration in the MC Scenario
RU
NN
ING
Applic
atio
nCaptureEvent
ContinueExecution
RaiseSecurityException
CHECKCONTRACTVIOLATION
Y
N
UpdateTrust
UpdateMonitorState
CheckPolicy
Violation
N
Y
STEP 4 STEP 3
Figure 7.3: The Contract Monitoring Configuration in the EPMC Scenario
Trust measures assigned to security assertions can be adjusted as a result of a contract monitoringstrategy. Indeed, trust measures associated with the NS concern on the contract goodness mainly. Up-dated trust measures will influence on future interactions of the CONNECT infrastructure with that particular
CONNECT 231167 113/125
![Page 84: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/84.jpg)
The CONNECT World
Networked Systems are the end-users in our network.
Enablers are the entities that receive requests from users. They store all information for creating/ choosing an appropriate CONNECTor for allowing the communication among different networked system.
CONNECTors are the final product of our framework. CONNECTors allow different devices used by different networked systems to communicate with each other even if they use different interface communication protocols.
![Page 85: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/85.jpg)
Contract in CONNECT
A contract (in CONNECT) represents the correct specification of the behavior of the CONNECTor provided by the enabler for allowing the communication
![Page 86: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/86.jpg)
Policy in CONNECT
A policy (in CONNECT) is set a local policy of each networked system. It declares what each NS aspects from the CONNECTor.
![Page 87: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/87.jpg)
Security in CONNECT According to the CONNECTor Life-cycle
CONNECT Infrastructure
Between CONNECT and NSs
CONNECTed system
Synthesis Time i)All Enablers are safe;ii)Some Enabler is malicious
i)The NSs are safe;ii) At least one NS is malicious
Deployment Time i)The Nss are safe;ii) At least one NSs ismalicious
Execution Time i)All Enablers are safe;ii)Some Enabler could be malicious
i)The Nss are safe;ii) At least one NSs ismalicious
i)Each NS could be a malicious agentii) CONNECT does not trust NSs
![Page 88: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/88.jpg)
Security in CONNECT According to the CONNECTor Life-cycle
CONNECT Infrastructure
Between CONNECT and NSs
CONNECTed system
Synthesis Time i)All Enablers are safe;ii)Some Enabler is malicious
i)The NSs are safe;ii) At least one NS is malicious
Deployment Time i)The Nss are safe;ii) At least one NSs ismalicious
Execution Time i)All Enablers are safe;ii)Some Enabler could be malicious
i)The Nss are safe;ii) At least one NSs ismalicious
i)Each NS could be a malicious agentii) CONNECT does not trust NSs
![Page 89: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/89.jpg)
Security between the Infrastructure and the NSs Layer
Threat Model:Each Networked System involved could be amalicious agent. NSs trust the CONNECTframework but they do not trust each other.The CONNECT framework does not trustNSs.
![Page 90: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/90.jpg)
Security between the Infrastructure and the NSs Layer
Centralized: In this case the CONNECTor and the enabler, that runs the connector, can be considered as the same thing form the security point of view.
Security policies are set on the running platform, i.e. on the enabler that run the CONNECTor.
The security policies of the NSs cannot be enforced
![Page 91: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/91.jpg)
Distributed1)if the CONNECTor run only on the NSs there is no
security constraints between the infrastructure and the NS layer because the CONNECTor is already deployed and it is out of the control of the infrastructure.
2) if part the connector is deployed on one of the enabler of the infrastructure we refer to the centralized case
Security between the Infrastructure and the NSs Layer
![Page 92: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/92.jpg)
Each Networked System Runs its Own Part of the CONNECTor
Two possible scenarios arise:
• the NSs are provided of the SxCxT mechanism.
• the NSs are not provided of the SxCxT. In this case we are in the same case of the centralized scenario
![Page 93: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/93.jpg)
NSs run SxCxT (1)
The SxCxT paradigm is applied for guaranteeing at run-time that:
• local private policies, that are not shared neither with the CONNECT infrastructure, are satisfied.
Example of local private policies are private policies regarding, for instance the GPS coordinates of he NS itself, the right for accessing to the private data stored on the device of the NS, and so on.
![Page 94: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/94.jpg)
NSs run SxCxT (2)
• none NS tries to attack the other NS by manipulating the part of the CONNECTor running on it.
One of the two NS is a malicious agent. When it
receives the part of CONNECTor that it is in charge to run, the NS manipulates it in order to attack the other NS during the communication.
![Page 95: Security and Trust · several trust paths that link the trustor to the recommended trustee exist, the ag-gregation can be used to aggregate all given trust recommendations [15]. More](https://reader034.vdocuments.net/reader034/viewer/2022051917/6009172568e0dc6c3129df38/html5/thumbnails/95.jpg)
Conclusion
We apply of the Security-by-Contract-with-Trust framework to CONNECT world. Indeed we show a strategy for establishing a secure communication among components of the Network by guaranteeing that they are connected through the usage of a secure CONNECTor