The Role of Cryptography in Database Security.pdf

盖国强

数据库管理系统密码应用技术要求

139

6页

3次

2021-11-30

免费下载

The Role of Cryptography in Database Security

Ueli Maurer

Department of Computer Science

ETH Zurich

CH-8092 Zurich, Switzerland

maurer@inf.ethz.ch

ABSTRACT

In traditional database security research, the database is

usually assumed to be trustworthy. Under this assump-

tion, the goal is to achieve security against external attacks

(e.g. from hackers) and possibly also against users trying

to obtain information beyond their privileges, for instance

by some type of statistical inference. However, for many

database applications such as health information systems

there exist conﬂicting interests of the database owner and

the users or organizations interacting with the database, and

also between the users. Therefore the database cannot nec-

essarily be assumed to be fully trusted.

In this extended abstract we address the problem of deﬁn-

ing and achieving security in a context where the database

is not fully trusted, i.e., when the users must be protected

against a potentially malicious database. Moreover, we ad-

dress the problem of the secure aggregation of databases

owned by mutually mistrusting organizations, for example

by competing companies.

1. INTRODUCTION

1.1 Scope of this Article

Classical database security (e.g. see [3]) relies on many

diﬀerent mechanisms and techniques, including access con-

trol, information ﬂow control, operating system and network

security, prevention of statistical inference, data and user au-

thentication, encryption, time-stamping, digital signatures,

and other cryptographic mechanisms and protocols.

It seems desirable to develop a systematic understand-

ing of database security problems and their solutions and

to come up with a framework. Ideally, such a framework

should give some assurance that all relevant security prob-

lems have been addressed, and it can possibly point out new

security issues not previously considered. It is a goal of this

extended abstract and the corresponding talk to contribute

to developing such a framework and identifying new research

directions for fruitful collaborations of the database, the in-

Permission to make digital or hard copies of all or part of this work for

personal or classroom use is granted without fee provided that copies are

not made or distributed for proﬁt or commercial advantage and that copies

bear this notice and the full citation on the ﬁrst page. To copy otherwise, to

republish, to post on servers or to redistribute to lists, requires prior speciﬁc

permission and/or a fee.

SIGMOD 2004, June 13–18, 2004, Paris, France.

formation security, and the cryptography research commu-

nities.

A major aspect that requires closer examination, and which

has partially been addressed in research directions like pri-

vate information retrieval (PIR) [4], is to reduce the required

level of trust into the database.

1.2 Limitations of Scope

The treatment in this paper is at a quite abstract level,

without explaining how concrete techniques and protocols

work. Some solutions proposed in this paper are of a theo-

retical nature and can become practical only when the com-

puting power and communication bandwidth, or the tech-

niques themselves, have been substantially improved. More-

over, the solutions and protocols are described in an ideal-

ized setting with synchronous communication channels. In

a real-world setting such an assumption may not be fully

justiﬁed, and the protocols addressing this issue are even

more complex.

1.3 Outline

In Section 2 we brieﬂy discuss information security from

a very high-level perspective and compare the design of se-

cure systems with the design of correct systems. We also

distinguish between unilateral and multilateral security. In

Sections 3 and 4 we discuss unilateral database security,

ﬁrst assuming the database, then the user to be trustwor-

thy, where protection must be achieved against the other

party’s potential cheating. In Section 2 we sketch the bi-

lateral security problem where both the database must be

protected against malicious users, and vice versa. A general

paradigm for building multilaterally secure systems, called

secure multi-party computation, is reviewed in Section 6.

Section 7 brieﬂy discusses the secure aggregation of several

databases as an application of secure multi-party computa-

tion.

2. INFORMATION SECURITY

One of the main paradigm shifts of the emerging infor-

mation society is that information is becoming a crucial if

not the most important resource. Information diﬀers radi-

cally from other resources; for instance and it can be copied

without cost, it can be erased without leaving traces. Pro-

tecting the new resource information is a major issue in the

information economy.

We use the term “database” in the most general sense, in-

cluding more general information systems than simple tra-

ditional databases.

Information security has proven to be a notoriously diﬃ-

cult topic. To understand and deﬁne security one must have

a clear understanding of what a system is supposed to ac-

complish and in which ways a potential attacker can try to

prevent the system from operating correctly. In this section

we address these issues at a very general level. It serves as

a basis to address database security in the later sections.

2.1 Unilateral Security

In many security-relevant applications, security is seen as

a unilateral problem: Some system (or entity, or collection

of entities) must be protected against a malicious outsider,

often called an attacker. The system is secure if no attacker

(with certain capabilities) can cause any (signiﬁcant) devi-

ation of the system from the speciﬁed behavior. This in-

cludes, for example, that the attacker cannot extract secret

information.

In order to deﬁne security, one must hence deﬁne the sys-

tem speciﬁcation, i.e., what the system is supposed to do

under normal circumstances, as well as the adversary’s ca-

pabilities. Such a speciﬁcation of capabilities can include

the available computing power, access to side information,

etc.

Typical examples of unilateral security problems are the

protection of a computer system by security mechanisms of

the operating system, as well as the protection of an orga-

nization’s internal network against hackers, for instance by

ﬁrewalls and intrusion detection technology.

Another, perhaps less obvious example of unilateral se-

curity is the protection of the communication between two

parties against an eavesdropper, for example by encryption.

Although b oth parties must be protected, the situation is

nevertheless a unilateral one because the required protection

of the two parties is (jointly) against an external eavesdrop-

p er, not against each other.

Database security is often seen as a unilateral security

problem: The database system must be protected against

outsiders and possibly also against potentially malicious users,

but is itself assumed to be trustworthy.

2.2 Multilateral Security

In contrast to unilateral security, many security-relevant

applications require the protection of several parties, each

against the potential misbehavior of some other parties, pos-

sibly against all other parties.

A simple example of bilateral security are on-line trans-

actions where both the customer and the vendor want to

b e protected against malicious behavior by the other. In

practice, such bilateral security issues are often not really

addressed and instead “solved” by assuming that one of the

parties (e.g. the vendor) is trustworthy.

Another such example, which needs some more explana-

tion, is the classical software piracy problem. The software

vendor has developed some useful functionality (e.g. a col-

lection of statistical tools), while the customer wants to ap-

ply the functionality to his data. The (idealized) speciﬁca-

tion is that a customer who pays is allowed to use the func-

tionality. This speciﬁcation is implemented by the vendor

by encoding the functionality in a software package, sending

the software to the customer, and the customer running the

Note that one need not distinguish between users and out-

siders. The outsider could be deﬁned as a user with no

privileges.

software on his machine. However, this achieves more than

the speciﬁcation, in an undesirable way: The user cannot

only apply the functionality to his data, he can pass this ca-

pability on to other parties (software piracy). This problem

is sometimes addressed by extra hardware mechanisms, but

usually it is addressed only by legal deterrence, which means

that from a purely technical viewpoint (which we take in this

paper) the user is assumed to be trusted.

There is a dual (for now quite theoretical) solution to this

problem. Instead of having the vendor send the software to

the user, the user could send his data to the vendor for pro-

cessing. More precisely, the vendor could run a web-service

which manages, stores, and processes a customer’s data. In

this case, the customer need not receive the software but

must of course fully trust the service provider.

Ideally, one would like to solve the software piracy prob-

lem in a fair and symmetric manner such that neither the

vendor must send the software to the user nor must the user

send the data to the vendor. This is a typical example of

a speciﬁcation which could easily be solved if a mutually

trusted party were available. This party could obtain the

software and the user’s data and perform all operations for

the user, giving only him access to the result of the com-

putation. We will discuss in Section 6 that many security

solutions can be seen as the simulation of a virtual trusted

party by the actual involved parties.

Another example of multi-lateral security, involving three

entities, are on-line auctions. The auctioneer, the bidder,

and the party oﬀering an object need to be protected against

possible fraud by another party (and, of course, also against

external attackers). An even higher level of security is ach-

ieved if each party is protected against the other two parties

cheating collectively with a joint strategy.

Yet another example of multilateral security is e-voting

discussed below.

2.3 Deﬁning Security

As mentioned above, in order to deﬁne security one must

deﬁne the system speciﬁcation, i.e., what the system is sup-

posed to do under normal circumstances, as well as the ad-

versary’s capabilities. But how should one model the ad-

versary if one wants to achieve security simultaneously for

diﬀerent groups of potential cheaters?

Let us address the system speciﬁcation ﬁrst. In the above

software example, the speciﬁcation is simply that the user

should obtain the result of applying the software to his data.

However, both discussed implementations achieve more, ac-

tually too much from a security point of view. The speci-

ﬁcation can be seen as an idealized system which performs

exactly (and only) the desired operations.

As another example, a secure communication channel is

an idealized system with three parties, the sender, the re-

ceiver, and the eavesdropp er. The speciﬁcation is such that

the sender can choose a message, the receiver gets it, and

the eavesdropper gets nothing. Encryption is a secure im-

plementation of this speciﬁcation if one can argue that the

ciphertext seen by the eavesdropper gives no information (in

a computational sense) about the message.

For e-voting the speciﬁcation is that each voter can choose

his vote and that all voters should learn the correct outcome

of the vote evaluated according to the rules. The fact that

votes need to be communicated is not part of the actual

speciﬁcation, but of course some form of communication is