TRUST-BASED SECURE INFORMATION SHARING BETWEEN
FEDERAL GOVERNMENT AGENCIES
Peng Liu
School of Information Sciences and Technology, The Pennsylvania State University, 003B Thomas
Building, University Park, PA 16802. E-mail: [email protected]
Amit Chetal
Department of Computer Science and Engineering, The Pennsylvania State University, 220 Pond
Laboratory, University Park, PA 16802. E-mail: [email protected]
The September 11 attack and the following
investigations show that there is a serious information
sharing problem among the relevant federal
government agencies, and the problem can cause
substantial deficiencies in terrorism attack detection.
This paper performs a systematic analysis of the causes
of this problem; and it finds that existing secure
information sharing technologies and protocols cannot
provide enough incentives for government agencies to
share information with each other without worrying
that their own interests can be jeopardized. Although
trust-based information access is well studied in the
literature, the existing trust models, which are based on
certified
attributes,
cannot
support
effective
information sharing among government agencies,
which requires an interest-based trust model. To solve
this information sharing problem, this paper proposes
an innovative interest-based trust model and a novel
information sharing protocol, where a family of
information sharing policies are integrated, and
information exchange and trust negotiation are
interleaved with and interdependent upon each other.
In addition, an implementation of this protocol is
presented using the emerging technology of XML Web
Services. The implementation is totally compatible with
the Federal Enterprise Architecture reference models
and can be directly integrated into existing EGovernment systems.
1.1. Information Sharing Problems among Government Agencies
For one, agencies acted as stovepipes, or rigid
functionally organized departments [71]. For instance,
there were multiple watch lists that existed across the
federal agencies in regards to suspecting malicious
terrorists. Each agency had a separate watch list based on
separate data organization and schema, but none of the
watch lists had details about the other and the watch lists
were not unified by any means. Moreover, there was a
lack of communication between agencies. In fact, even
President Bush conceded, “In terms of whether or not the
FBI and the CIA were communicating properly, I think it
is clear that they weren’t” [27]. So, the government
agencies could not aggregate their information properly.
1.2. Development of E-Government Initiatives
Because of the stovepipes that existed between
several government agencies, the president and the rest of
the congressional staff developed 24 E-Government
initiatives [36]. These initiatives could generate several
billion dollars in savings and specify plans so agencies can
collaborate and share their information in a more efficient
manner, thereby consolidating information.
1.3. Establishing the Federal Enterprise Architecture
In order to address and fulfill the E-Government
initiatives, there needs to be a flexible, comprehensible,
standardized (reference) model. This model is known as
the Federal Enterprise Architecture (FEA) [31]. It is vitally
important for agencies to communicate in a more citizencentric, unifying way, where information can be
exchanged in a more efficient manner. As a result, this new
FEA will leverage technology investments to avoid
unnecessary duplication of infrastructure amongst
agencies, link business processes through shared, yet
protected information systems, and leverage disparate
1. INTRODUCTION
After the terrorist attacks of September the 11th on
American soil, much of the nation spoke out for a drastic
change within the federal government. One of the primary
changes focused on addressing information sharing
amongst government agencies. With efficient information
sharing, government agents will be able to predict and
possibly preempt attacks form occurring. However, prior
to September the 11th, serious information sharing
problems existed within government agencies.
1
business processes [7]. It is clear that enabling effective
information sharing is a major goal of the FEA. (In
effective information sharing, the information held by one
agency, if useful to another agency, will be timely
disclosed to the other agency in a cooperative, proactive
manner in most, if not all, cases.) In fact, one of the most
intriguing E-Government initiatives is the EAuthentication initiative, whose objective is: “Build and
enable the mutual trust needed to support widespread use
of electronic interactions between the public and
government and across governments…” [36].
1.4. Limitations of Existing Information Sharing Technologies
However, existing information technologies are very
limited to achieve the goal of the E-Authentication
initiative, i.e., building mutual trust between agencies in
such a way that effective information sharing can be
enabled, since they cannot build the level of trust that is
needed to provide enough incentives for government
agencies to share information with each other without
worrying that their own interests can be jeopardized.
Although the FEA provides a solid, standardized platform
for agencies to collaborate with each other, the FEA
assumes the use of existing trust models, and agencies are
still reluctant to share sensitive information with one
another. Several government agencies declared that they
were reluctant to share sensitive information with one
another and are not comfortable since they don’t entirely
trust the other agencies. This study shows that although
trust-based information access is well studied in the
literature [11, 12, 17, 18, 44], the existing trust models,
which are based on certified attributes, cannot support
effective information sharing among government agencies,
which requires an interest-based trust model. Information
sharing among government agencies requires a different,
more restrictive trust model primarily due to two reasons:
(1) much of the information that each agency carries is
highly sensitive, so agencies find it difficult to simply let
another agency gain access or observe its sensitive
information without first developing enough trust with the
other agency; (2) the differences and conflicts-of-interest
existing between agencies require a more accountable and
fair information sharing procedure, where the (mutual)
trust is not only affected by certified attributes and crossagency authority-mapping, but also affected by whether a
win-win information sharing can be achieved without
jeopardizing the interests of any agency involved.
1.5. Our Contributions
First, this paper performs a systematic analysis of the
causes of the information sharing problem among
government agencies, and it identifies the unique trust
2
management requirements for effective information
sharing among government agencies. Second, this paper
proposes an innovative interest-based trust model and a
novel information sharing protocol, where a family of
information sharing policies are integrated, and
information exchange and trust negotiation are interleaved
with and interdependent upon each other. Third, an
implementation of this protocol is presented using the
emerging technology of XML Web Services. The
implementation is totally compatible with the FEA
reference models and can be directly integrated into
existing E-Government systems. We believe the proposed
trust model and information sharing protocol may
dramatically improve the effectiveness of information
sharing among government agencies and reduce the
deficiencies in countering terrorism attacks.
1.6. Paper Organization
The rest of the paper is organized as follows. In Section 2,
we address the FEA and its limitations. Section 3
addresses “which kind of trust models is necessary to
enable effective information sharing among government
agencies?” In Section 4, we survey the literature of
information sharing and show why existing information
sharing technologies cannot support effective information
sharing among government agencies. Section 5 presents
our trust model and our information sharing protocol. In
Section 6, we present an XML Web Services based
implantation of our information sharing protocol. In
Section 7, we conclude the paper.
2. FEDERAL ENTERPRISE ARCHITECTURE
In this section, we provide an overview of the FEA so
that in Section 3 we can show why the FEA is limited in
enabling effective information sharing, and in Section 6 we
can present a FEA-based implementation of our
information sharing protocol.
The FEA exists as a function-oriented framework for
describing the business operations of the federal
government. It is also independent of the agencies that
perform those operations [35]; this means that the
architecture provides support for all agencies, independent
of each agency’s operations.
2.1. Principles of Federal Enterprise Architecture
Initially, it is important to understand that there are
several principles that form the basis for the federal
enterprise architecture [35]. For one, since much of the
information stored by each agency requires proprietary
software dependencies, there should be an establishment of
standards, mainly the establishment of federal
interoperability standards. By using the emerging new web
standards such as XML and XML Web services, agencies
will be free from software and hardware dependences.
These new standards will allow for increased collaboration
and cross-agency information exchanging. Also, another
vital principle involves capitalizing on standardization
measures based on common functions between agencies.
Federal agencies are attempting to develop reusable
functions that exist across agencies and purchase
architecture components that will allow for increased
collaboration and eliminate redundancy [31].
Moreover, another principle revolves around
coordinating the technology investments among the federal
agencies. Since there is constant overlap of functions
between the different agencies, vertical and horizontal
integration will allow for a reduction in spending, causing
a huge increase in federal financial savings.
Finally, a critical principle is to protect federal
information against malicious attacks and unauthorized
access. Since much of the federal information will be
represented in a more collaborative manner through new
web standards such as XML and web services [10], new
security measures need to be taken. Mainly, sensitive
information is no longer designated to one agency but
rather is flowing among agencies, so sharing such sensitive
information needs to be better protected because the
damage caused by an attack can be dramatically magnified
across multiple government agencies through the “bridges”
built by the FEA.
based on a hierarchical construct for describing the
business operations of the federal government [33].
The basic procedure (to develop this reference model)
involves looking at previous efforts that agencies used to
identify their functions, and then once the list was formed
in its entirety, categorize the functions into designated
mutually exclusive business areas.
2.2.2. Data Reference Model
The data reference model shows how the components
of the business reference model can be used to develop
cross-agency information exchanges, and it provides a
form of data standardization between the agencies. The
data reference model will be used to describe the types of
interactions and information exchanges that occur between
the federal government and its various customers.
XML, extensible markup language, plays a critical
role in developing the E-Government data reference
model. XML provides a mechanism for federal lines of
business to define and standardize XML schemas so some
lines of businesses can interact with other lines of
businesses. XML provides a standard way for preserving
and communicating information encoding, tagging, and
internationalizing information [73]. In XML, tags can be
created to represent each function for a particular line of
business. Also, these XML tags can be transmitted via
HTTP or some other protocol so other agencies can then
use these common functions, create new ones, or build
upon them.
2.2. Models of Federal Enterprise Architecture
The principles that make up the federal enterprise
architecture clearly address the existing stovepipes that
exist between agencies and address the issues behind the
E-Government initiatives. However, to have a deeper
understanding of the FEA, we need to discuss the four
reference models of the FEA, namely the business
reference model, the data reference model, the application
capability reference model, and the technical reference
model [33]. The four models are connected in a
hierarchical fashion in the sense that each lower level
model is a detailed layout (or exploration) of typically one
aspect of the corresponding higher level model. These
models depict the process of how the federal enterprise
architecture is used for cross-agency information sharing
and collaboration.
2.2.1. Business Reference Model
First, the business reference model describes the lines
of business of each agency, and identifies the customers
and partners of each agency. The business reference model
is a high level view of the federal enterprise architecture
3
2.2.3. Application Capability Reference Model
The application capability reference model describes
how the application capabilities support the business
objectives [16]. The application capability reference model
is comprised of two sub-models: the conceptual process
model and the interoperability model.
The conceptual process model, as shown in Figure 1,
describes the bridge between the functional view of the
business reference model and the technology needed to
carry out the cross-agency information exchanges. In order
to retrieve information from an agency application, six
layers of services (i.e., the end user layer, the access portal
layer, the crosscutting requirements layer, the web
platform layer, the applications interface layer, and the
enterprise data and applications layer) need to be
developed so that the information exchanges can take place
and each agency will be able to receive his/her desired
information. The interoperability model, as shown in
Figure 2, describes the primary application components
that support the conceptual process model and how they
interoperate within and across the lines of businesses [31].
The interoperability occurs at the user, data, and
application level.
FIG. 3. Technical Reference Model
3. NEED FOR AN INTEREST-BASED TRUST MODEL
In this section, before we show why FEA is limited
in enabling effective information sharing among
government agencies, we will first identify the agencies’
specific requirements on the (mutual) trust model.
3.1. Why There Is a Lack of Trust among Agencies?
FIG. 1. Conceptual Process Model
FIG. 2. Interoperability Model
2.2.4. Technical Reference Model
Finally, the technical reference model, as shown in
Figure 3, shows how technology is being used to deliver
application capabilities. The technical reference model
defines how the hardware, software, and physical location
can support the businesses, data, and functions [61]. The
purpose of the technical reference model is for better
coordination, development, and support of the EGovernment initiatives and cross-agency information
sharing.
4
The primary reason that spurs the hesitation and
reluctance for agencies to share their sensitive information
with one another is that they simply don’t trust each other.
The lack of trust is due to several reasons. We believe a
major reason is that conflicts of interest usually exist
between agencies and as a result, having agency A share
some information with agency B may actually compromise
the interests of agency A. In fact, “the conflict between the
agencies is deeply rooted. Even an event as horrible as
[Sept 11] cannot erase five decades of turf battles” [40].
Agencies may experience a great deal of friction in
cooperating in a joint effort, and information sharing
usually plays an important role in these frictions. As a
result, unfair information sharing and misuse of shared
information can substantially discourage the agencies
involved in a joint effort to share information with each
other. To illustrate, when two agencies A and B are
cooperating in a joint effort, if agency A shares a piece of
information (with B) which is critical to a task assigned to
B, but B hides a piece of information which is critical to a
task assigned to A, then B can perform much better than A,
and the performance difference may give B a lot of
advantages in competing with A. Hence, to ensure that
his/her interests will not be jeopardized, agency A may
want to do the same thing as B does, that is, A will stop
sharing information with B (proactively). In this way, as
more agencies hide their information, there will be less and
less mutual trust staying between agencies.
Moreover, the above problem can be further
exacerbated by two facts: (a) there are a lot of
misunderstandings between government agencies; (b) little
accountability is provided in existing information sharing
processes. Fact (a) indicates that agencies may possess
substantial misunderstandings (or doubt) about one another
in terms of the intent, objective, and strategies of
information sharing due to some inherent differences in
their agency structures, cultures, intra-agency policies,
beliefs, responsibilities, and missions. For example, “the
deeply ingrained differences between the CIA and FBI
have long prevented them from working together...” [40].
The misunderstandings between agencies can make one
agency “sense” more risk or less trust when sharing
information with another agency, thus they can further
discourage agencies to share information.
Fact (b) exacerbates the above problem since the lack
of accountability makes it difficult to resolve the conflicts
caused by unfair or misused information sharing among
agencies. Since the “bad” player cannot be easily identified
or published, one agency will probably “sense” more risk
or less trust when sharing information with another
agency.
Another reason for the lack of trust between agencies
is that shared information may be improperly processed by
an agency due to the following observations. First, internal
corruption might exist between government agencies. In
fact, in a recent survey by the Computer Institute and the
FBI, it was reported that a great deal of organizations face
insider attacks [48]. Internal corruption within an agency
may seriously jeopardize the other agencies’ trust in the
agency. Second, responsibility and seriousness needs to
take charge in order for cross-agency information sharing
to take place. In fact, one Colonel Steve York, stated that,
“The government has to lead by example. Within the
government, agencies don’t trust each other. The
government has to break down these walls …” [75].
3.2. Requirements on the Trust Model
Information sharing schemes are trust-based; and
whether an information sharing scheme can lead to
effective information sharing among government agencies
is heavily dependent upon the trust model on top of which
the information sharing scheme is constructed. The reasons
about why there is a lack of trust among agencies imply
that the trust model for effective cross-agency information
sharing needs to satisfy the following requirements:
A. The trust model should be built in such a way that
win-win information sharing will always increase
the mutual trust. An information sharing procedure
between two agencies is a win-win procedure if the
interests (or payoffs) of both agencies will be
increased (to a similar degree) when the procedure
ends. If win-win information sharing does not increase
the mutual trust or even decreases the mutual trust,
then the success of a win-win information sharing may
not be able to promote more valuable and successful
information sharing, since a higher level of mutual
trust is usually needed to make the two agencies
willing to share more sensitive or important
information. On the other hand, if this requirement is
satisfied, a win-win information sharing procedure can
increase the mutual trust which can in turn encourage
more valuable win-win information sharing, and since
more sensitive information can be shared, more
interests can be obtained by both agencies. This
property has the potential to transform the situation
where “nobody wants to share information” to the
5
situation where “everybody wants to share
information”.
B. The trust model should be built in such a way that
win-lose information sharing will always decrease
the trust of the loser in the winner. An information
sharing procedure is a win-lose procedure if the
interests of (at least) one agency will be decreased
when the procedure ends. When requirement A is
satisfied, this requirement implies that “bad” agencies
that hide information to “steal” more interests can
actually be punished due to the following reason: (a)
win-lose information sharing hurts mutual trust; and
degraded trust will prevent more information sharing;
(b) hence, good agencies will have less and less winlose information sharing with bad agencies and more
and more win-win information sharing will good
agencies; and as a result, after a relatively long period
of time, all the good agencies will gain a lot of
interests but the bad agencies can only gain very little.
C. Requirements A and B indicate that interests must
be part of the trust model.
D. Requirement C indicates that information validity
and utility must be part of the trust model. This is
because the interests that an agency can gain through
an information sharing procedure are ultimately
determined by the validity and utility of the
information the agency received. A piece of
information must be valid (i.e., with high integrity) in
order to be useful. And the utility of the piece of
information is also determined by such factors as
whether it is needed by the agency and whether it is
critical to solve a critical problem faced by the agency.
3.3. Limitations of Existing Trust Models
Of course, the trust model for information sharing
among government agencies is built on the shoulder of
existing trust models, which as we will shown in Section 4
shortly, can be broken down into three layers:
identification and authentication build the first layer of
trust; certified attributes built the second layer of trust; and
delegation builds the third layer of trust.
However, as we will shown in Section 4 shortly, a
serious drawback of existing information sharing
technologies is that the existing trust models do not satisfy
the four requirements we have identified above. Existing
trust models can enable agencies to trust “who you are”,
“the attributes you have”, “the authorities you have”, but
cannot enable agencies to trust “this information sharing
procedure will increase my interests” or “this information
sharing procedure will be a win-win one”. In summary,
credentials and authorities are the basis of existing trust
models, but they cannot deliver interests guarantees,
however, information sharing among government agencies
requires an interest-based trust model.
3.4. Limitations of FEA
Although the federal enterprise architecture provides a
solid foundation for cross-agency information exchanging,
it assumes the use of existing trust models which are not
interest-based as we will show in Section 4 shortly. As a
result, without a new interest-based trust model, even if the
FEA is fully implemented, agencies will be still reluctant
to freely share information with one another.
4. EXISTING INFORMATION SHARING
TECHNOLOGIES
In this section, we present a classification of existing
information sharing technologies and show why they are
limited in enabling effective information sharing among
government agencies. Existing information sharing
technologies can be classified into two categories: (a)
privacy-preserving information sharing, where two parties
with information x and y respectively share their
information with each other in such a way that a function
of x and y, denoted f(x,y), is computed and learned by the
two parties, but the privacy of x and y is preserved during
the information sharing process, that is, the two parties
learn only f(x,y) and nothing else; and (b) non-privacypreserving information sharing, where two parties with
information x and y respectively can not only share a
function of x and y with each other but also share (part of)
x and/or (part of) y with each other.
4.1. Privacy-Preserving Information Sharing
Privacy-preserving information sharing techniques
can be broken down into three sub-categories: (a1) trust
third party techniques; (a2) secure multi-party
computation; and (a3) application specific techniques.
4.1.1. Trust Third Party
The two parties give their data (i.e., x and y) to a
“trusted” third party and have the third party do the
computation (i.e., computing the value of f(x,y)) [3, 49].
However, the third party has to be completely trusted, both
with respect to intent and competence against security
breaches. The level of trust required may be too high for
this solution to be practically used by government
agencies.
4.1.2. Secure Multi-Party Computation
There are two parties with inputs x and y respectively
(each one is typically a n-dimension vector) and the goal of
6
secure multi-party computation is to compute a function
f(x,y) without involving a third party such that the two
parties learn only f(x,y) and nothing else. See [42, 57] for a
discussion of various approaches to this problem.
Yao [74] showed that any multi-party computation can
be solved by building a combinational circuit, and
simulating that circuit. A variant of Yao’s protocol is
presented in [58] where the number of oblivious transfers
is proportional to the number of inputs and not the size of
the circuit. However, this approach is too expensive,
especially in communication cost. For example, for n = 1
million, the communication time for the circuit-based
protocol is 144 days (using a T1 line), which is clearly too
long for government agencies to share information with
each other.
4.1.3. Application Specific Solutions
Without involving a third party, efficient privacypreserving information sharing is possible in some specific
information sharing settings, where some specific data
structures and some specific forms of secure multi-party
computation (i.e., specific forms of f(x,y)) can be exploited
substantially to reduce the complexity. For example[1], a
researcher proposes a set of efficient protocols for
information sharing across private databases, where the
notion of minimal information sharing across private
databases is formalized, and the unique characteristics of
the relational data model and the associated query
operators are exploited to achieve both privacy and
efficiency. Compared with [74], for n = 1 million, the
communication time of [1] is only 0.5 hours instead of 144
days.
4.2. Non-Privacy-Preserving Information Sharing
Privacy preserving is actually not a requirement for
most, if not all, information sharing activities between
government agencies. The techniques for non-privacypreserving information sharing can be broken down into
three sub-categories: (b1) privilege-based information
sharing; (b3) trust-based information sharing; and (b3) fair
data exchange.
4.2.1. Privilege-Based Information Sharing
Access control technologies can be used to support
both intra-organization and inter-organization information
sharing. Within a single organization, information (stored
in files or databases) can be shared by assigning proper
authorizations (or privileges) to the subjects (i.e., users).
For example, when Alice and Bob are both authorized to
access a piece of information x, x is shared by Alice and
Bob. Authorization management is well studied in the field
of access control. For example, a popular authorization
management scheme is role based access control [21].
Inter-organization access control focuses on how to allow
a user U of organization A to access a piece of information
x owned by organization B. To make the access control
policy of each organization intact, inter-organization
access control needs to map (or translate) U’s
authorizations in organization A to some corresponding
authorizations in organization B. Good methods to do such
mappings are developed in the literature [4, 63]. However,
inter-organization access control is limited in sharing
information among government agencies, since interorganization access control assumes that organizations
trust each other with respect to both the validity of
information and the validity of authorizations; however,
this level of trust may not be “reachable” between two real
world agencies in many information sharing scenarios.
Finally, for a set of organizations that distribute, store,
and utilize their information in a decentralized fashion,
digital credentials (on top of a PKI) can be used to
facilitate the enforcement of both intra-organization and
inter-organization access control. Using digital credentials,
each organization can certify the roles, attributes, and
authorizations associated with her employees, and the PKI
can ensure that the digital credentials issued by each
organization are verifiable so that forged credentials will
never be used. In addition, to make such enforcements
more efficient, privileges can be delegated from one party
to another party [2, 41].
O would like to offer (or share) a free software package
only to college students, while O does not trust any
university directly. Instead, O accepts accrediting
credentials issued by the software Accrediting Board for
Universities (ABU). As a result, to get the software for
free, a student Alice of university StateU needs to show O
not only a credential issued by StateU which says that
Alice is a student of StateU, but also a credential issued by
ABU which says that StateU is an accredited university of
ABU. In other words, O establishes its trust in Alice
through a chain of two credentials: the credential issued by
ABU makes O trust StateU and its credentials, and the
credential issued by StateU makes O trust Alice.
In summary, trust-based information sharing is
composed of two key technologies: (1) trust management;
and (2) attributed or role-based access control. Trust
management enables a party to trust a credential (and its
content) issued by a stranger through a chain of other
“proving” credentials. Then attributed (or role) based
access control can be used to disclose a piece of
information based on the attributes certified by a trusted
credential. Delegation is an inherent part of trust based
information sharing. For example, in the above example, O
in fact delegates the authority over the identification of
preferred customers to ABU.
Trust management technologies can be broken down
into three sub-categories: (1) credential-chain-based trust
management; (2) trust negotiation; and (3) ad hoc trust
management.
4.2.2. Trust-Based Information Sharing
•
Although privilege-based information sharing may
work well under centralized trust, privilege-based
information sharing cannot handle information sharing
under decentralized trust. Under centralized trust, there is
one authority which everybody trusts, however, such
authority does not exist under decentralized trust where
one party typically trusts only a couple of other parties. We
can use information sharing under centralized trust for
trust-based information sharing. Trust plays an implicit
role in privilege-based information sharing where every
credential can be verified in a straightforward way. In
contrast, trust plays a much more explicit role in trustedbased information sharing. For example, if organization A
does not trust organization B, A will not trust credentials
issued by B, and no employee of B can access information
owned by A unless he or she holds a credential issued by a
party trusted by A.
In trust-based information sharing, everybody
determines whether to share a piece of information (with
others) based on trust; and the access control is typically
enforced based on the attributes or roles associated with
the subjects. To illustrate, assume an online software store
7
•
Credential-chain-based trust management: In this
category, a chain of credentials issued by a set of
parties can be used to make one party trust another
party with respect to the other party’s attributes.
Technologies in this category include but are not
limited to SPKI/SDSI [18], KeyNote [12], PolicyMaker [11], REFEREE [17], and Delegation Logic
[44]. Moreover, in [51, 52], the concept of partial trust
is introduced, where one may consider someone to be
completely trusted, completely un-trusted, completely
unknown, or somewhere in between.
Trust negotiation [46]: In this category, each party
can have multiple credentials containing different sets
of attributes. To establish trust between two parties,
they use access control policies that specify what
combinations of digital credentials a stranger must
disclose to gain access to a local information resource.
However, to preserve the privacy of sensitive
credentials, a credential will not be disclosed to party
B by party A unless party A has a certain level of trust
in B, which is established based on a set of credentials
disclosed from B to A. Therefore, A and B need to
interactively negotiate their trust on each other
through typically multiple rounds of trust-based
credential exchange. A party can use many different
strategies to negotiate trust, however, to preserve
parties’ autonomy, each party should ideally be able to
choose its negotiation strategy independently, while
still being guaranteed that negotiations will succeed
whenever possible, i.e., that the two parties’ strategies
will interoperate.
•
Ah hoc trust management: In this category,
credentials are not necessary to establish trust. For
example, in [45], a simple distributed trust model is
proposed where numerical ad hoc trust levels are
maintained for each party to measure the degrees to
which it trusts the other parties. In [23], a protocol for
maintaining and exchanging reputations in peer-topeer networks is proposed. Note that reputations can
be directly mapped to trust levels. In [55], a
reputation-based trust model for peer-to-peer ecommerce communities is proposed.
4.2.3. Fair Data Exchange
Experience with e-commerce has shown that an
exchange of one data item for another between mutually
distrusted parties is usually the crux of an electronic
transaction. Fair data exchange technologies have been
used in many applications such as non-repudiation of
message transmission [43], certified mail [24], contract
signing [9], and e-payment systems [20, 70]. An exchange
is fair if at the end of the exchange, either each party
receives the item it expects or neither party receives any
additional information about the other’s item. Fair data
exchange protocols in the literature can be broken into two
categories: third party protocols which use a trusted or
semi-trusted third party and gradual exchange protocols
[9] where the probability of correctness is gradually
increased over several rounds of communications. Third
party protocols can be further classified into two subcategories: exchanges with online third parties [20, 39],
where an exchange cannot be completed without using the
trusted channel even if both parties play honestly, and
exchange with offline third parties [5, 8], where an
exchange can be completed without interferences of the
trusted third party if the two parties play honestly and the
third party is needed only when a party does not play
honestly. A third party is trusted if it will neither
misbehave on its own, nor conspire with either of the
players. A third party is semi-trusted if the third party may
misbehave on its own but will not conspire with either of
the two parties [39].
Although information sharing usually involves data
exchange, the type of information sharing in fair data
exchange and the type of information sharing in EGovernment are very different. In particular, first,
8
information sharing in fair data exchange is fairness-based,
but information sharing in E-Government is trust-based.
Fair data exchange protocols focus on fairness, nonrepudiation and atomicity, but information sharing in EGovernment focuses on trust, access control, and privacy.
Trust is easy to establish in fair data exchange, but hard in
information sharing in E-Government, where fairness is
not necessarily a requirement. Information sharing in EGovernment typically requires the two pieces of
information to be exchanged between two parties are of
similar types, but fair data exchange protocols typically
exchange very different types of information.
As a result, fair data exchange technologies are
limited in supporting information sharing among
government agencies. Relying on a trusted third party may
be too strong a requirement for practical information
sharing. Using a semi-trusted third party cannot help much,
since although the third party will not conspire with either
of the two agencies, none of the two agencies may want to
reveal the information they want to share with each other
to the third party due to the sensitivity of the information.
Finally, using a gradual data exchange protocol may be too
expensive and cause substantial delays.
4.3. The Uniqueness of Our Trust-based Information Sharing
Scheme
Although our information sharing scheme is built on
top of the set of existing information sharing technologies,
it has several unique features. In particular,
•
Our scheme is FEA specific. Our scheme is
motivated by a systematic analysis of the specific
security requirements for information sharing in EGovernment. To our best knowledge, our scheme is
the only information sharing scheme that satisfies the
set of security requirements identified in Section 3.
•
Our scheme makes validity and utility of
information part of the trust model. That is,
whether Agency A trusts agency B is also affected by
the information (and its validity and utility) that A has
obtained from B besides credentials. In credentialchain-based trust management and trust negotiation,
trust is only affected by credentials. However,
experience with real world cross-agency information
sharing shows that even if Agency A believes that an
agent of B has a set of eligible attributes, A may not
want to share a piece of sensitive information with the
agent due to some conflicts of interests between A and
B.
•
Interleaved information sharing and trust
negotiation. In [47], each information unit is only
associated with a combination of credentials, and the
trust level is increased only due to the disclosure of
more credentials. By contrast, in our scheme, the trust
level may also be increased when the shared
information is valid and appreciated. In [47], an
information unit will be disclosed only when the trust
negotiation succeeds. Otherwise, no information will
be disclosed. By contrast, in our protocol, information
sharing and trust negotiation are interleaved. Partial
information sharing is in fact used to “negotiate” trust.
Even if the two parties cannot finish the n-round
information sharing process, they still could share
some valuable information with each other during the
process. In this way, information sharing is more
efficient and cost-effective.
•
Web services based implementation. Such
implementation not only enables our scheme to be
seamlessly integrated into the FEA reference model,
but also enables our scheme to be easily integrated
into a variety of existing E-Government applications.
5. INFORMAITON SHARING FRAMEWORK
Our information sharing framework has two parts: (1) an
interest-based trust model; and (2) an information sharing
protocol built on top of the trust model.
5.1 Assumptions
•
•
•
Centralized trust. We assume that all the agencies
that want to share information with each other trust a
single certification authority (CA) and any credentials
issued by the CA. We assume the CA may delegate
the authority to certify an attribute of a government
agent to an agency. In this way, one agency may trust
the credentials issued by another agency in an indirect
fashion through a specific delegation credential issued
by the CA. Two agencies need not to know each other
in advance in order to be able to share information.
Secure communication channels. We assume that
all the agencies are using a secure communication
channel to share information with each other since the
shared information can be very sensitive. We assume
the secure channel can ensure the confidentiality and
integrity of the messages being transmitted. Denial-ofservice attacks may happen but are out of the scope of
this paper.
Intra-agency information sharing is in place. In
fact, intra-agency information sharing can be easily
achieved using the set of existing information sharing
technologies overviewed in Section 4, where (a)
centralized trust is naturally built; (b) when the
agency’s information systems are centralized, access
9
control can be directly used to share information
among units within the agency where agents playing a
more responsible role can access more sensitive
information than other agents; (c) when the agency’s
information systems are distributed and of large scale,
digital credentials and delegation can be used, where
the amount of information that an agent can access is
determined by “which attributes (e.g., a role) are
associated with the agent?” Note that intra-agency
information sharing typically does not need an
interest-based trust model and existing trust models
are usually good enough to enable effective intraagency information sharing.
5.2 Design Goals and Requirements
The ultimate goal of our information sharing scheme
is to transform the situation where “nobody wants to share
information” to the situation where “everybody wants to
proactively share information”, so that mutual trust can be
rebuilt among agencies, differences between agencies can
be tolerated, misunderstandings among agencies can be
minimized, conflicts can be resolved, and effective
information sharing can be achieved.
To achieve this goal, the information sharing scheme
needs to satisfy the following requirements:
a) The trust building procedure, part of the information
sharing protocol, should provide enough incentives for
agencies to do win-win information sharing and
should discourage win-lose information sharing. In
this way, more agencies will do win-win information
sharing and “bad” agencies will be punished by doing
win-lose information sharing.
b) To satisfy requirement (a), the information sharing
protocol must ensure that no agency can get
significant amount of advantages during any steps of
the protocol if he/she hides information or does not
play honestly, because otherwise win-lose information
sharing will be encouraged.
c) Requirement (b) indicates that during any step of the
information sharing protocol no significant amount of
information can be disclosed, because otherwise the
agency who receives the significant amount of
information can abort and get significant amount of
advantages.
d) Since no significant amount of information can be
disclosed in any step of the protocol, gradual
information disclosing is required.
e) Requirements (b) and (d) indicate the disclosing of
information from agency A to agency B and from B to
A should be interleaved with each other, because
otherwise the agency who discloses the information
first will be the loser even if he/she discloses the
information gradually.
f)
Requirements (a) and (e) indicate that trust building
and information exchange should be interleaved with
each other, since validity and utility of information are
part of trust, and trust is a precondition for information
disclosure.
g) Fairness: The protocol should ensure that every
information-sharing procedure is fair, that is, no
matter where the procedure stops (note that an agency
may abort at any point of the procedure), the
information or the interests gained by the two agencies
(involved in the procedure) should be almost the same.
From the perspective of trust building, fairness can be
interpreted as: either the information is exchanged and
the trust levels are increased, or the information is not
exchanged at all and the trust levels are dropped, but
nothing in between could happen. This requirement
can be viewed as being deduced from requirement (a).
released when the condition is satisfied?” The condition of
an IR component policy can consist of 0 to 4 predicates.
When there are 0 predicates, there is no restriction to
disclose the information unit. When there are 4 predicates,
as Figure 4 shows, when agency A wants to determine
whether to disclose an information unit to agency B, the
first predicate is to check if B is “authorized” to access the
information unit. How such checking should be done is
specified by an access control policy which we will define
shortly.
Condition: access-control-passed({Cb1, …, Cbp}, Uaj)
AND received-and-valid(Ub1, …, Ubq) AND
utility(Ub1, …, Ubq) >3 AND TL(B) >4
Action: release information unit Uaj to B
FIG. 4. An Example IR Component Policy
5.3 Information Sharing Policies
We use four types of information sharing policies in the
information sharing protocol. They are information release
(IR) policies, credential release (CR) policies, trust level
adjustment (TLA) policies, and access control (AC)
policies.
To illustrate the four types of policies, we need to first
introduce a set of notations. In our protocol, we assume
there are two agencies: A and B. We assume Ca1, …, Cam
are the m credentials held by agency A; and Cb1, …, Cbn
are the n credentials held by agency B. We assume Ua1,
…, Uau are the u units of information owned by A; and Ub1,
…, Ubv are the v units of information owned by B. We
assume TL(A) is the trust level of A in the eyes of agency
B, which indicates the degree to which B trusts A; and
TL(B) is the trust level of B maintained by A. We assume
the trust levels are quantified using an integer from 1 to 10,
the simplest way. Although trust levels can be quantified in
a more complicated way, numerical trust levels are enough
to show the idea of our information sharing protocol.
Finally, we assume utitlity(Uai) measures the utility level of
information unit Uai to agency A, which indicates the
degree to which Uai is useful to A. We assume utilities are
quantified using an integer from 1 to 7.
Now we define the four types of information sharing
policies one by one following an order that can best
illustrate the relationships among these policies.
An information release policy is used to help agency A
to determine when a specific information unit can be
disclosed to agency B. An IR policy is simply a set of
component policies. An example IR component policy is
shown in Figure 4, where we can see that an IR component
policy is composed of two parts: the condition part is a
conjunction or disjunction of a set of predicates, and the
action part specifies the information unit that can be
10
Condition: received-and-verified(Cb1, …, Cbp) AND
attributes-carried({Cb1, …, Cbp}, {a1, …, ar}) AND
received-and-valid(Ub1, …, Ubq) AND utility(Ub1, …,
Ubq) >4
Action: increase the value of TL(B) by 1
FIG. 5. An Example TLA Component Policy
Condition: received-and-valid(Ub1, …, Ubq) AND
utility(Ub1, …, Ubq) >3 AND TL(B) >5 AND
received-and-verified(Cb1, …, Cbp) AND attributescarried({Cb1, …, Cbp}, {a1, …, ar})
Action: release credential Caj to B
FIG. 6. An Example CR Component Policy
Condition: received-and-verified(Cb1, …, Cbp) AND
attributes-carried({Cb1, …, Cbp}, {a1, …, ar})
Action: B can access information unit Uaj
FIG. 7. An Example AC Component Policy
The second predicate is to verify the validity of the
information units that agency A has already received from
B through the (same) information sharing procedure so
far. The third predicate is to check the utilities already
earned by A through the protocol run. We assume the
validity is checked and the utilities are measured by a
human being. How to have a software agent check the
validation and measure the utilities is one of our future
research topics. The fourth predicate is to check if A has
built a certain level of trust in B.
In summary, the first predicate builds the lower level
trust needed for cross-agency information sharing. The
second and third predicates are to satisfy design
requirements (a), (b), (c), (d), (e), and (g). The fourth
predicate is to satisfy design requirement (f).
In our scheme, trust levels are dynamically
maintained based on a specific trust level adjustment
policy. An example TLA component policy is shown in
Figure 5, where (a) the first and second predicates build
the lower level trust on top of which interest-based trust
can be built. The attribute-carried() predicate will help
agency A build a level of certified-attribute-based trust in
B. Note that this level of trust is exactly the type of trust
built by existing trust management techniques (see Section
4). (b) The third and fourth predicates build an additional
level of interest-based trust. Finally, it should be noticed
that Figure 4 and Figure 5 show clearly how trust building
and information exchange are interleaved with each other.
In our scheme, the disclosure of credentials is also
controlled by a credential release policy, since credentials
may contain very sensitive attributes (e.g., the
responsibility of a special FBI agent). An example CR
component policy is shown in Figure 6, where we can see
that whether to release a credential to B is not only
dependent on whether B has released some sensitive
credentials to A, but also dependent upon the level of
interest-based trust A has in B, since releasing sensitive
credentials may also hurt the interests of an agency. It
should be noticed that our CR policies are different from
existing trust negotiation policies [46].
Finally, an access control policy determines whether
an agency is eligible or authorized to access an
information unit owned by another agency. An example
AC component policy is shown in Figure 7, where we can
that our access control policies are almost the same as
existing trust-based information access policies [44].
Nevertheless, it should be noticed that Figures 6 and 7
show that information exchange and credential negotiation
are actually interleaved with each other. Figure 4, Figure
5, and Figure 6 show that trust building and credential
negotiation are actually also interleaved with each other.
5.4 Information Sharing Protocol
agency A initiates the information sharing procedure by
asking B to disclose information unit Ub3. We assume A
also discloses a credential, namely Ca1, together with the
request. B processes this request via P1 as follows: (a) P1
will first use Ca1 to adjust the value of TL(A) according to
a TLA component policy, we assume as a result, TL(A) is
increased from 1 to 2. Next, P1 will check the set of IR
component policies regarding Ub3. We assume {Ca1, Ca2,
Ca3} are needed to access Ub3. So each access-controlpassed() predicate in these component policies will be
evaluated as FLASE. Next, to enable agency A to disclose
Ca2 and Ca3 to B (so that B may disclose Ub3 to A), B needs
also to disclose some information units and credentials to
A so that the set of security requirements listed in Section
5.2 can be satisfied. Hence, B will disclose Ub1 and Cb1 in
message 2. Here Ub1 can be disclosed because we assume
there is an IR component policy regarding Ub1 allows B to
do so based on Ca1 and TL(A). Moreover, B asks A to
disclose Ua3.
When A receives message 2, P2 will first use Ub1 and
Cb1 to adjust the value of TL(B). Next, P2 will check
his/her IR and CR component policies to figure out which
credentials and/or information units can be disclosed. We
assume {Cb1, Cb2, Cb3} are needed to disclose Ua3, and Ua1
and Ca2 can be disclosed due to Ub1, Cb1, and the fact that
TL(B) is increased.
When B receives message 3, P3 will do almost the
same type of things as P2 does and as a result, Ub2 and Cb2
are disclosed. When A receives message 4, P4 will do
almost the same type of things as P2 does and as a result,
Ua2 and Ca3 are disclosed. When B receives message 5, P5
will do almost the same type of things as P3 does and as a
result, Ub3 and Cb3 are disclosed. Finally, when A receives
message 6, A will disclose Ua3 in message 7.
Agency A
[1] “I want Ub3”, Ca1
[2] “I can only release Ub1”, Ub1,
“I want Ua3”, Cb1
P2
11
P3
[5] “I can release Ua2”, Ua2,
“I can release Ca3 now”, Ca3
[6] “I can release Ub3”, Ub3,
“I can release Cb3 now”, Cb3
P6
P1
[3] “I can only release Ua1”, Ua1,
“I can release Ca2 now”, Ca2
[4] “I can release Ub2”, Ub2,
“I can release Cb2 now”, Cb2
P4
The four types of information sharing policies clearly
indicate how an information sharing protocol should run.
In this section, instead of giving a formal specification of
the protocol, we use an example to illustrate how the
protocol works.
The example is shown in Figure 8, where the protocol
run involves seven messages and six major procedures,
namely P1, …, P6, after some of the messages. We assume
Agency B
[7] “I can release Ua3”, Ua3,
P5
FIG. 8. An Example Run of the Information Sharing
Protocol
Although we will not formally specify our information
sharing protocol, a formal specification of the protocol
should be easily figured out based on the above example
protocol run.
5.5 Discussion
First, some people may wonder “how can agency A
know after receiving message 1 that Ua1 and Ca2 will be
needed to enable B to finally disclose Ub3?” The answer
has two parts: (a) agency B can tell A via message 1
which kind of credentials is needed for B to disclose Ub3.
B can figure out this information based on his/her IR and
CR component policies using the techniques developed in
[46]. (b) Ua1 is chosen primarily because of the relation
between Ua1 and Ua3. Since B wants Ua3, so information
related to Ua3 should be able to increase the interests of B
and encourage B to increase his/her trust in A. For
example, Ua1 can be an approximation (or estimation) of
Ua3.
Second, our information sharing scheme has three key
features: (1) it uses an interest-based trust model where
utilities of shared information units are part of the mutual
trust. (2) It interleaves trust negotiation and information
exchange, where not only trust negotiation is gradually
done but also information sharing is gradually done. (3) It
satisfies the set of security requirements identified in
Section 5.2. Therefore, our information sharing scheme
can meet the design goals identified in Section 5.2.
6. PROTOTYPE IMPLEMENTATION
To be completely compatible with the FEA, we
implement our information sharing scheme using XML
web services. Web services are an emerging, state-of-theart technology that provides the perfect technology for
integrating and sharing information among agencies. One
of its primary features is interoperability of two systems.
Web services are a critical part of both the FEA conceptual
process reference model and the interoperability reference
model, since web services can enable government agencies
with different types of information systems (e.g., different
data management schemes, different operating systems,
different network protocols) to communicate and interact
with each other in a platform transparent fashion.
6.1. Components of Web Services
The components of XML web services include
applications, UDDI, WSDL, and SOAP [16]. Applications
may be clients of XML web services provided by another
12
application, providers of XML web services to other
applications, or both [31]. UDDI, Universal Description
Discovery and Integration, provides a registry of available
XML web services. The Web Service Description
Language (WSDL) provides an XML based description of
XML web services and how to interact with them [14].
The WSDL is the interface definition language of XML
web services. Finally, SOAP, or Simple Object Access
Protocol, is a lightweight remote-procedure-call protocol
that uses XML to format messages and HTTP to transmit
messages [3].
The general procedure of using a web service starts
when a client searches for the web service from an UDDI
registry. The UDDI registry in some sense is equivalent to
the yellow pages in a phone book. However, the UDDI
registry is not a completely secure registry and in fact is a
public registry. Many government officials are very
reluctant to populate a public registry of web services
using the UDDI standard [29]. As a result, government
agencies that wish to share their services with each other
will share the service description information through a
secure communication channel. In either way, the client
will be able to obtain a description of the web service,
which is written in WSDL, through a private or public
registry. Then, the client can retrieve the description
(written in WSDL), parse the XML data contained in the
description, and learn the URL of the web service and the
right ways to call the web service using SOAP. At the web
server end, each SOAP request will be first received by the
SOAP listener then forwarded to a specific request
processor, called the WSDL server, which will parse the
XML data contained in the SOAP request. A set of service
requests which can be understood by the server
application will be generated after the XML data are
parsed, and the set of service requests will be sent to the
server application for processing.
6.2. Microsoft .NET XML Web Services
We implement our information sharing scheme using
Microsoft .NET, which provides a very powerful, mobile,
and developer friendly infrastructure for creating a web
service. Many real world government agencies have
already deployed some .NET web services.
Some important components of XML web services in
.NET include the .ASMX file extension, the .ASPX file
extension, and the WSDL. Initially, the web service itself
is implemented using the .ASMX file extension.
Essentially, .ASMX files are based on ASP .NET. In these
.ASMX files, besides the code that implements each web
method of the web service, the set of web methods that
compose the web service are also defined using a set of
<WebMethod> tags.
After the (web service) provider creates all of its
functions or web methods in the .ASMX files, it creates a
WSDL description of the web service, where the client can
find the exposed methods of the web service, the
parameters and return types that these methods expose, and
any other exposed information. The WSDL description is
generated based on the set of <WebMethod> tags.
Finally, the client uses an .ASPX file to call the web
service. The .ASPX file is generated based on the WSDL
description of the web service that the client can get from a
registry.
[SoapHeader("Credentials",Required=true)]
[WebMethod]
public return_type function_name()
{
//Code used to implement web method
}
according to the service descriptions and send it to an
information-sharing web service provided by Y (note that
the request message is similar to message (1) in Figure 8).
(d) When the information sharing service of Y receives
the request message, it will process the request according
to the information sharing protocol we illustrated in
Section 5.4. Note that if an agent of Y (i.e., a human being)
needs to be involved in the information sharing procedure,
the service of Y will notify the agent and prepare an
interface for the agent to jump in.
(e) In the following, the agent of Y and the agent of X
can follow the information sharing protocol (e.g., the
procedure shown in Figure 8) in a naïve manner, except
that in the implementation the support service functions as
the “proxy” for the agent of X, and the information sharing
service functions as the “proxy” for the agent of Y.
6.5. An Example Implementation
FIG. 9. SOAP Header Format in .NET
6.4. How to Use XML Web Services to Implement Our
Information Sharing Protocol?
In general, we can use XML web services to implement
our information sharing protocol as follows: (a) each
agency X provides a set of information-sharing web
services to the agencies who may want to share
information with agency X. The WSDL descriptions of
these web services should be composed and disclosed to an
agency that wants to share information with X in a secure
way, since such descriptions may themselves contain
sensitive information and should only be readable to
certain authorized agencies. (b) In addition, each agency X
provides a specific information- sharing-support web
service to her own agents. Since this service (i.e., the
URL) is pre-known to every agent of X, no WSDL
description or registration is needed.
(c) When an agent of agency X wants to get a specific
information unit U from agency Y, the agent will first
authenticate himself/herself to the information-sharingsupport service (“support service” for short) provided by
X. Next, the agent will use a standardized interface
(provided by the support service) to ask the support service
to initiate an information sharing procedure with agency
Y. However, to have an error-free information sharing
procedure with Y, the support service must first understand
which kinds of information sharing services are provided
by Y and how these services should be called (or used) in
terms of the procedures and the message format that need
to be followed. Hence, before the support service starts the
information sharing procedure, it will first search for the
WSDL descriptions of the services provided by Y. Next,
the support service will compose a request message
13
To better understand how exactly web services can be
used for two agencies to share information (with each
other) within the federal enterprise architecture framework,
we implemented a simple information sharing system
prototype using XML web services for a real world
information sharing application between two agencies. In
particular, we use this prototype to support FBI and CIA to
share anti-terrorism information with each other1.
However, for simplicity, we implement the FBI’s
information sharing web service, but do not implement the
support service of the CIA; instead, we make a CIA agent
directly call the FBI’s service. (Note that this
implementation can be easily extended to include all the
components we mentioned in Section 6.4.)
In this prototype, we assume both the FBI and the CIA
contain pertinent information with regards to antiterrorism. For example, the FBI may maintain such antiterrorism information as criminal lists and the CIA may
maintain such anti-terrorism information as a set of
intelligence gatherings1. The steps that the two agencies
will take in sharing information with each other are
depicted in Figure 10. In particular, we assume a CIA
agent wants to get an information unit from the FBI. So
initially, the FBI will create an information-sharing web
service and specify the web methods for the service. Then
the FBI will send the WSDL description of the service (or
the set of web methods) to a secure web site (or a secure
channel) for the CIA agent to retrieve. A sample of the
WSDL service description is shown in Figure 11.
Moreover, one way to create the secure channel in the
federal enterprise architecture is to use a trusted broker. In
1
The FBI and CIA used in this implementation are used only as example
agencies. The real government agencies may contain different names,
perform different responsibilities, and contain different types of
information.
particular, when one agency X needs to share information
with another agency Y, it can simply send its WSDL
service description along with the agency it wants to share
information with, to a broker. The broker will allow an
agency to access the service description only if the agency
is authenticated as Y.
1.
2.
3.
4.
FBI, the web service provider agency develops its
information sharing policies and establishes the
corresponding web methods
The FBI passes the WSDL description of its
information sharing web service to a secure channel
The CIA agent, i.e., the web service client, retrieves
the WSDL description
The client parses the WSDL description, calls the
corresponding web methods of the information
sharing web service to initiate and interact with the
FBI’s service in such a way that the information
sharing protocol can be successful executed
FIG. 10. Steps of Information Sharing between Two
Agencies Using Web Services
6.5. Key Features
The prototype implementation has several interesting
features, which are as follows. These features indicate the
benefits of using XML web services.
• It supports two-way information sharing. When the
CIA client calls a FBI web method, the client can
disclose some credentials or information to the FBI.
On the other hand, the execution of a FBI web method
can disclose some credentials or information to the
CIA agent in several ways. For example, the FBI web
method can show an information unit or a credential
directly on the interface (i.e., a web browser) used by
the CIA agent. For another instance, the FBI web
method can guide the CIA agent to download an
information unit or a credential via the web browser.
• It provides multiple web methods for building trust.
• It exploits SOAP header authentication to counter
session hijack attacks. The idea of SOAP header
authentication is shown in Figure 9. That is, a web
method can be executed only if the credentials (e.g., a
password) provided by the client can authenticate the
client. Using this technique, the FBI web service can
enforce dynamic authentication for each web method
in such a way that the attacker will not succeed in
replaying web methods or hijacking an ongoing
information sharing session.
• It provides privacy for using web methods. That is,
clients not qualified to run a web method (due to trust
and authorizations) will never be able to see “what is
the web method about?” or “how should the web
method be used?”
• It provides a design for peer-to-peer cross-agency
information sharing.
• It provides a powerful, easy-to-use interface with
.NET technology.
• It integrates information sharing and data
management. Both the CIA client and the FBI web
service manage the information units they may share
in a MS ACCESS database.
6.6. Limitations
FIG. 11. WSDL Description of an Information-Sharing Web
Service
Once the client (on behalf of the CIA agent) retrieves
the WSDL description, using an XML parser, it will
analyze the service description and determine the input
arguments for the web methods that it needs to invoke
during the protocol run via SOAP messaging.
14
Nevertheless, at this stage, the prototype is still
preliminary and it has several limitations, which are as
follows. The last three limitations can be overcome by
better engineering, while the first limitation needs future
research, which we will address in Section 7.
1) It requires human interaction.
2) It is only an emulation of the real world information
sharing activities between FBI and CIA. It uses
emulated data instead of real data.
3) It uses a small, centralized database.
4) Using a broker to create a secure channel for WSDL
service descriptions distribution introduces some extra
overhead compared with using UDDI.
7. CONCLUSION AND FUTURE RESEARCH
Although trust-based information access is well studied
in the literature, the existing trust models, which are based
on certified attributes, cannot support effective information
sharing among government agencies, which requires an
interest-based trust model. To solve this information
sharing problem, this paper proposes an innovative
interest-based trust model and a novel information sharing
protocol, where a family of information sharing policies
are integrated, and information exchange and trust
negotiation are interleaved with and interdependent upon
each other. In addition, an implementation of this protocol
is presented using the emerging technology of XML Web
Services. The implementation is totally compatible with
the Federal Enterprise Architecture reference models and
can be directly integrated into existing E-Government
systems. We believe our cross-agency information sharing
scheme can transform the situation where “nobody wants
to share information” to the situation where “everybody
wants to proactively share information”, so that the mutual
trust can be rebuilt among agencies, differences between
agencies can be tolerated, misunderstandings among
agencies can be minimized, conflicts can be resolved, and
effective information sharing can be achieved. With
secure, effective information sharing, the agencies’ ability
to predict attacks and preempt them can be significantly
enhanced.
In addition, the following future research issues are
identified and successful resolution of these research issues
can further improve the agencies’ ability to effectively and
efficiently share information with each other.
7.1 Develop Privacy Preserving UDDI Registry
One way to improve upon the existing implementation
is to develop a privacy preserving UDDI registry. With
such a UDDI, an agency A will be able to register his/her
information sharing services without losing privacy, in the
sense that his/her services will only be visible to the
agencies that B would like to share information with. In
this way, agencies can enjoy the simplicity and efficiency
of UDDI without losing confidentiality; and no dedicated
secure service notice facilities are needed.
information with each other on behalf of the corresponding
agencies. In this way, human being can be completely or
partially relieved from the labors (or efforts) needed to run
the information sharing protocol; and more efficient and
timely information sharing may be achieved. More timely
information sharing can mean more timely detection of
terrorism attacks and less damage caused by such attacks.
A key research issue in using software agents is how to
enable a software agent to intelligently evaluate the
validity and utility of a piece of information. Although this
issue is out of the scope of this paper, we believe artificial
intelligence and natural language processing would play an
important role in this research.
7.3. Cookie Management for Incremental Trust Negotiation
Another interesting future research area would be to
develop cookie management between two agencies.
Cookies are information stored on your own computer for
future use after some www sessions. With the development
of cookie management, two agencies that have already
built certain level of trust with one another don’t have to
redevelop the mutual trust. Instead, they could use cookies
to remember the current trust state for future reuse. In this
way, information sharing can be made quicker and more
efficient. Nevertheless, a drawback of using cookies is that
the security risk is increased.
7.4. Direct Querying According to Previously Stored Information
In relation to this research, another efficient way for
each agency to share information with one another is for
them to directly “query” the other agencies’ databases
according to the database scheme information they were
already given. For instance, if two agencies have already
shared information with one another, then each agency
would have already obtained substantial scheme
information about the other agency’s databases. Such
scheme information may enable both agencies to compose
accurate, executable queries. By sending a query directly
from one agency to another, an agency will be able to
pinpoint the information he/she wants to get in a finer
granularity.
REFERENCES
1
2
7.2. Develop Automated Software Agents for Trust Negotiation
Another way to improve upon the existing
implementation is to develop automated or semi-automated
software agents who negotiate trust and share sensitive
15
3
Agrawal R., Evfimievski A., Srikant, R. (2003).
Information Sharing Across Private Databases. In Proc.
ACM SIGMOD 2003, San Diego, CA.
Ahn, G., Chu, B., Zhang, L. (2001). A Role-Based
Framework for Healthcare Information Systems. In Proc.
ACM Symposium on Access Control Models and
Technologies, pages 153-162.
Ajmani, S., Morris R., Liskov, B. (2001). A Trusted ThirdParty Computation Service. Technical report MIT-LCS-TR847, MIT
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Akella, Y., Bilello, M., Dawson, S., De Capitani di
Vimercati, S., Samarati, P., Lincoln, P., Tan, Y.,
Wiederhold, G. (2000). Secure Access Wrapper: Mediating
Security between Heterogeneous Databases. In Proc. of the
DARPA Information Survivability Conference and
Exposition, Hilton Head, South Carolina.
Asokan, N., Shoup, V. (1998). Asynchronous Protocols for
Optimistic Fair Exchange. Proc. IEEE Symposium on
Research in Security and Privacy, pages 86-99, CA.
Augustyniak, M. (2002). SAMS Teach Yourself .NET XML
Web Services in 24 Hours. SAMS Publishing, Indianapolis,
Indiana.
April, C. A., Fonseca, B. (2002). Monumental Mission.
InfoWorld,
http://www.infoworld.com/article/02/09/06/020909ctgovt_1.
html
Bao, F., Deng, R.H., Mao, W. (1998). Efficient and
Practical Fair Exchange Protocols with Off-Line TTP. Proc.
IEEE Symposium on Research in Security and Privacy,
pages 86-99, CA.
Ben-Or, M., Goldreich, O., Micali, S., Rivest, R.L. (1990).
A Fair Protocol for Signing Contracts. IEEE Transactions
on Information Theory, Vol. 36, No. 1, pp 40-46.
Birbeck, M., Diamond, J., Duckett, J., Gudmundsson, O.G.,
Kobak, P., Lenz, E., Livingstone, S., Marcus, D., Mohr, S.,
Ozu, N., Pinnock, J., Visco, K., Watt, A., Williams, K.,
Zaev, Z., (2001). Professional XML, 2nd Ed., Wrox Press,
Birmingham, UK.
Blaze, M., Feigenbaum, J., Ioannidis, J., Keromytis, A.D.
(1996). Decentralized Trust Management. In Proc. the 1996
IEEE Symposium on Security and Privacy, pages 164-173.
Blaze, M., Feigenbaum, J., Ioannidis, J., Keromytis, A.D.
(1999). The Keynote Trust-Management System, version 2,
IETF RFC 2704.
Bush, G. W. (2002). Presidential Memo on the Importance
of E-Government: Memorandum for the Heads of Executive
Departments and Agencies. Office of the Press Secretary.
http://www.whitehouse.gov/news/releases/2002/07/2002071
0-6.html.
Cameron, D. (1998). E-Commerce Security Strategies:
Protecting the Enterprise. Computer Technology Research
Group, Charleston, South Carolina.
Carbone, G., Stoddard, G. (2001). Open Source Enterprise
Solutions. Wiley Computer Publishing, New York, New
York.
Champion, M. E. (2002). Web Services Architecture: W3C
Working Draft. W3C.
http://www.w3.org/TR/2002/WD-ws-arch-20021114.
Chu, Y., Feigenbaum, J., LaMacchia, B., Resnick, P.,
Strauss, M. (1997). REFEREE: Trust Management for Web
Applications. World Wide Web Journal, Vol. 2, pages 706734.
Clarke, D., Elien, J., Ellison, C., Fredette, M., Morcos, A.,
Rivest, R.L. (2001). Certificate Chain Discovery in
SPKI/SDSI. Journal of Computer Security, Vol. 9, No. 4, pp
285-322.
Connel, P. O., Gray, E., Jensen, C., Seigneur, J.-M., Weber,
S., Yong, C. (2002). Towards a Framework for Assessing
Trust-Based Admission Control in Collaborative Ad Hoc
16
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
Applications. Informatics and Mathematical Modeling,
Technical University of Denmark, Lyngby, Denmark.
Cox, B., Sirbu, M., Tygar, D., (1995). NetBill Security
and Transaction Protocol, Proc. the First USENIX Workshop
on Electronic Commerce, pages 77-88, New York.
Coyne, E.J., Feinstein, H.L., Sandhu, R., Youman, C.E.
(1996). Role-Based Access Control Models. IEEE
Computer, Vol. 29, No. 2.
Cummins, F. A., (2002). Enterprise Integration: An
Architecture for Enterprise Application Systems Integration.
Wiley Computer Publishing, New York, New York.
Damiani, E., Paraboschi, S., Vimercati, S. (2002). A
Reputation-Based Approach for Choosing Reliable
Resources in Peer-to-Peer Networks. Proc. ACM Conference
on Computer and Communications Security, Washington,
DC, USA, pp207-216.
Deng, R.H., Gong, L., Lazer, A.A., Wang, W. (1996).
Practical Protocols for Certified Electronic Mail. Journal of
Network and System Management, Vol. 4, No. 3.
Digital Signature Initiative. (1997). The Digital Signature
Trust Management Architecture. W3C,
http://www.w3.org/Dsig/DsigTrustSystem.html.
R Dodds, L. (2002). In a Lather About Security. O’Reilly
Network. http://ww.xml.com/pub/a/2002/02/27/securitylather.html.
Donovan, J. (2002). U.S.: Congress Probes FBI And CIA
Intelligence Failures. RadioFreeEurope.
http://ww.rferl.org/nca/features/2002/06/05062002152908.as
p.
Ettinger, J.E. Ed. (1993). Information Security. Chapman
& Hall, London, United Kingdom.
Ewald, T. (2002). The Web Services Idea. Microsoft
Corporation.
http://msdn.microsoft.com/webservices/understanding/read
me/default.aspx.
Farah, J. (2002). U.S. Government Doesn’t Trust
Americans. WorldNetDaily.
http://www.worldnetdaily.com/news/printerfriendly.asp?ARTICLE_ID=28308.
Federal CIO Council. (2002). E-Gov Enterprise Architecture
Guidance(Common Reference Model. FEA Working Group.
http://ww.cio.gov/documents/ EGov_Guidance_July_25_Final_Draft_2_0a.pdf.
Federal Enterprise Architecture Program Management
Office. (2002). The Business Reference Model Version
1.0:A Foundation for Government Wide Improvement.
Federal Architecture Program Management Office.
http://www.feapmo.gov/resources/fea_brm_release_docume
nt_rev_1.pdf.
Federal Enterprise Architecture Program Management
Office. (2002). The Business Reference Model Version
1.0:Agency Briefing Federal Architecture Program
Management Office.
http://www.feapmo.gov/fea_downloads.htm.
Federal Enterprise Architecture Program Management
Office. (2002). Draft Business Reference Model Common
Response Document. Federal Architecture Program
Management Office..
http://www.feapmo.gov/fea_downloads.htm.
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
Federal Enterprise Architecture Program Management
Office. (2002). Solution Architects Working Group:
Overview of Missions and Objectives. Federal Architecture
Program Management Office.
http://xml.gov/presentations/sawg/overview.ppt.
Federal Enterprise Architecture Program Management
Office. (2002). Twenty Four Presidential Priority E-Govt
Initiatives. Federal Architecture Program Management
Office. http://www.feapmo.gov/fea.htm.
Fedorov, A. (2002). A Programmer’s Guide to .NET.
Addison-Wesley, London, United Kingdom.
Fernandez, E. B. (2002) Web Services Security: Current
status and the future. Web Services Architect.
http://www.webservicesarchitect.com/content/
articles/fernandez01.asp.
Franklin, M.K., Reiter, M.K. (1997). Fair Exchange with a
Semi-Trusted Third Party. Proc. 4th ACM Conference on
Computer and Communications Security, pages 1-7, Zurich,
Switzerland.
French, M. (2003) CIA, FBI Wrangle Over Threat Center.
Federal Computer Week.
http://www.fcw.com/fcw/articles/2003/0421/web-ciafbi-0423-03.asp.
Gasser, M., McDermott, E. (1990). An Architecture for
Practical Delegation in a Distributed System. IEEE
Symposium on Research in Security and Privacy, Oakland,
CA.
Goldreich, O. (2001). Secure Multi-Party Computation.
Working Draft, Version 1.3.
Gollmann, D., Zhou, J. (1996). A Fair Non-Repudiation
Protocol. Proc. IEEE Symposium on Research in Security
and Privacy, pages 55-61, Oakland, CA.
Grosof, B.N., Feigenbaum, J., Li, N. (2003). Delegation
Logic: A Logic-Based Approach to Distributed
Authorization. ACM Transactions on Information and
Systems Security, Vol. 6, No. 1, pp 128-171.
Hailes, S., Rahman, A. (1997). A Distributed Trust Model.
Proc. New Security Paradigm Workshop, ACM.
Hess, A., Jacobson, J., Jarvis, R., Seamons, K.E., Smith, B.,
Yu, L. Yu, T., Winslett, M. (2002). Negotiating Trust on the
Web. IEEE Internet Computing.
Hoque, F. (2000). e-Enterprise: Business Models,
Architecture, and Components. Cambridge University
Press, New York, New York.
Jarrell, D. (2002) The Value of Information Sharing.
Federal Computer Incident Response Center.
http://www.fedcirc.gov.
Jefferies, N., Mitchell, C., Walker, M. (1995). A Proposed
Architecture for Trusted Third Party Services. In
Cryptography Policy and Algorithms Conference, Springer
LNCS Volume 1029, pp 98-104.
Jones, V.E., Seamons, K.E., Winsborough, W.H. (1999).
Automated Trust Negotiation. Open Group Conference,
Montreal, Quebec.
Josang, A. (1999). An Algebra for Assessing Trust in
Certification Chains. Proc. Network and Distributed Systems
Security Symposium, The Internet Society.
Josang, A. (1997). The Right Type of Trust for Distributed
Systems. Proc. New Security Paradigm Workshop, ACM.
17
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
Kaler, C. Ed. (2002). Web Services Security: WS-Security.
IBM. http://www106.ibm.com/developerworks/webservices/library/wssecure/.
Krill, Paul. (2002). UDDI Endures Reality Check Debate.
InfoWorld.
http://www.infoworld.com/article/02/04/26/020426hnuddi_1
.html.
Liu, L., Xiong, L. (2003). A Reputation-Based Trust Model
for Peer-to-Peer E-Commerce Communities. Proc. 4th ACM
Conference on Electronic Commerce, San Diego.
Microsoft Visual Studio. NET. (2002). XML Web Services
Security. Microsoft.
http://msdn.microsoft.com/vstudio/techinfo/article/XMLweb
services/security.asp.
Naor, M., Nissim, K. (2001). Communication Preserving
Protocols for Secure Function Evaluation. In Proc. of the
ACM Symposium on Theory of Computing, pages 590-599.
Naor, M., Pinkas, B., Summer, R. (1999). Privacy
Preserving Auctions and Mechanism Design. Proc. of the 1st
ACM Conference on Electronic Commerce, pages 129-139,
Denver, Colorado.
Network of Reform Groups. (1999). The Effective National
Drug Strategy 1999. Network of Reform Groups.
http://www.csdp.org/edcs/page45.htm.
OMB Watcher. (2002). NY State Confidential
Memorandum. OMB Watcher.
http://www.ombwatch.org/info/2001/NYSinventory.html.
Open Resource Group. (1999). Technical Reference Model
in Detail. The Open Group.
http://www.opengroup.org/architecture/togaf7/presents/togaf
_ovu.pdf.
Opplinger, R. (1999). Security Technologies for the World
Wide Web. Artech House, Boston, MA.
Osborn, S. L. (2002). Integrating Role Graphs: A Tool for
Security Integration. Data and Knowledge Engineering, Vol.
43, No. 3, pp. 317-333.
Pipkin, D.L. (2000). Information Security: Protecting the
Global Enterprise. Prentice Hall, Upper Saddle River, New
Jersey.
Scheer, A.-W. (1998). ARIS – Business Process
Frameworks. Springer, Berlin, Germany.
Seamons, K.E., Winslett, M., Yu, T. (2001). Limiting the
Disclosure of Access Control Policies During Automated
Trust Negotiation. Network and Distributed System Security
Symposium. San Diego, CA.
Shirky, C. (2002) Web Services-An Executive Summary.
O’Reilly Network.
http://www.oreillynet.com/pub/a/webservices/2002/04/12/ex
ecreport.html.
Skonnard, A. (2002). Understanding XML Namespaces.
DevelopMentor.
http://msdn.microsoft.com/msdnmag/issues/01/07/xml/defau
lt.aspx.
Tabor, R. (2002). Microsoft .NET XML Web Services.
SAMS Publishing, Indianapolis, Indiana.
Tygar, J.D. (1998). Atomicity Versus Anonymity:
Distributed Transactions for Electronic Commerce, Proc.
24th VLDB Conference, pages 1-12, New York.
71
72
73
74
75
76
77
Ulanoff, L. (2002). An Insider’s Look at Homeland Security
and Technology. PC Magazine.
http://www.pcmag.com/article2/0,4149,652467,00.asp.
Washington Technology. (2002). Understanding the Federal
Enterprise Architecture. Washington Technology.
http://216.70.54.91/ad_sup/blueprintl.
Wolter, R. (2001). XML Web Services Basics. Microsoft
Corporation.
http://msdn.microsoft.com/library/default.asp?url=/library/e
n-us/dnwebsrv/html/webservbasics.asp.
Yao, A.C. (1986). How to Generate and Exchange Secrets.
Proc. of the 27th Annual Symposium on Foundations of
Computer Science, pages 162-167. Toronto, Canada.
York, S. (1997). Battling the Cyberthreat. Wabash
Magazine.
http://www.wabash.edu/magazine/1997/fall/features/face_of
_conflict/cyber_threat.htm.
http://www.cia.gov.
http://www.fbi.gov
18