17-03-2014, 08:58 PM
Abstract—A statistical database (SDB) publishes statistical
queries (such as sum, average, count, etc) on subsets of records,
and the data in individual records should be remained secret.
The key representation auditing scheme is proposed to
guarantee the security of online and dynamic SDBs. The core
idea is to convert the original database into key representation
database (KRDB), also this scheme involves converting each
new user query from string representation into key
representation query (KRQ), and stores it in the Audit Query
table (AQ table). We propose three audit stages to repel the
attacks of the snooper to the confidentiality of the individuals.
These stages enable the key representation auditor (KRA) to
conveniently specify the illegal queries which could lead to
disclosing the SDB. Cost estimation for this scheme is
performed, and we illustrate the saving in block accesses (CPU
time) and storage space that are attainable when a KRDB is
used.
Keywords-confidentiality; statistical database; auditing;
compromise
I. INTRODUCTION
A statistical database (SDB) publishes statistical queries
(such as sum, average, count, etc) on subsets of records.
Information is thus hidden by aggregating data, and the
security problem is to ensure that data in individual records
remains secret [1]. Although users are only allowed to access
the statistical information from an SDB, malicious users
(snoopers) can deduce confidential information about some
individuals by stitching the answers of some legal queries.
When any confidential information is disclosed, the SDB is
compromised [2][3]. A typical example of SDB can be
illustrated based on the data held in Table I. In the SDB, the
salary of specific individual should not be disclosed. Table I
shows the original database D summarizing confidential
information about employees. Each employee is classified in
three categories and has one data attribute. The possible
category attributes’ values are as follows:
Gender: {M, F} = {1, 2}
Dept: {CS, EE, PE} = {1, 2, 3}
Level: {BSc, MSc, PhD} = {1, 2, 3}
The possible data attribute’s values are:
Salary (in $): any integer ≥ 0
Table II shows the key representation database (KRDB)
D\ [4], which the conversion result of the original database D
by converting the three category attributes (Gender, Dept,
Level) into one cell (Ui1Ui2Ui3), and the data attribute value
Vi1 will be separated by the sign '.'. The converted two cells
are as following:
Ui1Ui2Ui3 .Vi1
Where, the cell Ui1Ui2Ui3 represents the category
attributes’ classes corresponding to the category attributes
(Gender, Dept, Level). And Vi1 represents the value of the
data attribute (Salary).
queries (such as sum, average, count, etc) on subsets of records,
and the data in individual records should be remained secret.
The key representation auditing scheme is proposed to
guarantee the security of online and dynamic SDBs. The core
idea is to convert the original database into key representation
database (KRDB), also this scheme involves converting each
new user query from string representation into key
representation query (KRQ), and stores it in the Audit Query
table (AQ table). We propose three audit stages to repel the
attacks of the snooper to the confidentiality of the individuals.
These stages enable the key representation auditor (KRA) to
conveniently specify the illegal queries which could lead to
disclosing the SDB. Cost estimation for this scheme is
performed, and we illustrate the saving in block accesses (CPU
time) and storage space that are attainable when a KRDB is
used.
Keywords-confidentiality; statistical database; auditing;
compromise
I. INTRODUCTION
A statistical database (SDB) publishes statistical queries
(such as sum, average, count, etc) on subsets of records.
Information is thus hidden by aggregating data, and the
security problem is to ensure that data in individual records
remains secret [1]. Although users are only allowed to access
the statistical information from an SDB, malicious users
(snoopers) can deduce confidential information about some
individuals by stitching the answers of some legal queries.
When any confidential information is disclosed, the SDB is
compromised [2][3]. A typical example of SDB can be
illustrated based on the data held in Table I. In the SDB, the
salary of specific individual should not be disclosed. Table I
shows the original database D summarizing confidential
information about employees. Each employee is classified in
three categories and has one data attribute. The possible
category attributes’ values are as follows:
Gender: {M, F} = {1, 2}
Dept: {CS, EE, PE} = {1, 2, 3}
Level: {BSc, MSc, PhD} = {1, 2, 3}
The possible data attribute’s values are:
Salary (in $): any integer ≥ 0
Table II shows the key representation database (KRDB)
D\ [4], which the conversion result of the original database D
by converting the three category attributes (Gender, Dept,
Level) into one cell (Ui1Ui2Ui3), and the data attribute value
Vi1 will be separated by the sign '.'. The converted two cells
are as following:
Ui1Ui2Ui3 .Vi1
Where, the cell Ui1Ui2Ui3 represents the category
attributes’ classes corresponding to the category attributes
(Gender, Dept, Level). And Vi1 represents the value of the
data attribute (Salary).