Multilevel

Security for
Relational
Databases

Osama S. Faragallah
El-Sayad M. El-Rabaie • Fathi E. Abd El-Samie
Ahmed I. Sallam • Hala S. El-Sayed
 Multilevel
Security for
Relational
Databases
OTHEr TITLES FrOM AUErBACH PUBLICATIONS AND CrC PrESS

Agile Strategy Management: Techniques for Intrusion Detection in Wireless Ad-Hoc

Continuous Alignment and Improvement Networks
Soren Lyngso Edited by Nabendu Chaki and
ISBN 978-1-4665-9607-8 Rituparna Chaki
Anonymous Communication Networks: ISBN 978-1-4665-1565-9
Protecting Privacy on the Web
Network Innovation through OpenFlow
Kun Peng
and SDN: Principles and Design
ISBN 978-1-4398-8157-6
Edited by Fei Hu
Big Data, Mining, and Analytics: ISBN 978-1-4665-7209-6
Components of Strategic
Decision Making Programming Languages for MIS:
Stephan Kudyba Concepts and Practice
ISBN 978-1-4665-6870-9 Hai Wang and Shouhong Wang
ISBN 978-1-4822-2266-1
BYOD for Healthcare
Jessica Keyes Security for Multihop Wireless Networks
ISBN 978-1-4822-1981-4 Edited by Shafiullah Khan
C: From Theory to Practice and Jaime Lloret Mauri
George S. Tselikis and Nikolaos D. Tselikas ISBN 978-1-4665-7803-6
ISBN 978-1-4822-1450-5
Security for Service Oriented Architectures
Creating and Marketing New Products Walter Williams
and Services ISBN 978-1-4665-8402-0
Rosanna Garcia
ISBN 978-1-4822-0360-8 The Art of Linux Kernel Design:
Illustrating the Operating System
Disturbance Observer-Based Control: Design Principle and Implementation
Methods and Applications
Lixiang Yang
Shihua Li, Jun Yang, Wen-Hua Chen, and
ISBN 978-1-4665-1803-2
Xisong Chen
ISBN 978-1-4665-1579-6 The SAP Materials Management
Empowering Project Teams: Using Project Handbook
Followership to Improve Performance Ashfaque Ahmed
Marco Sampietro and Tiziano Villa ISBN 978-1-4665-8162-3
ISBN 978-1-4822-1755-1
The State of the Art in Intrusion
Formal Languages and Computation: Prevention and Detection
Models and Their Applications Edited by Al-Sakib Khan Pathan
Alexander Meduna ISBN 978-1-4822-0351-6
ISBN 978-1-4665-1345-7
Wi-Fi Enabled Healthcare
How I Discovered World War II’s
Ali Youssef, Douglas McDonald II, Jon
Greatest Spy and Other Stories of
Linton, Bob Zemke, and Aaron Earle
Intelligence and Code
ISBN 978-1-4665-6040-6
David Kahn
ISBN 978-1-4665-6199-1 ZigBee® Network Protocols and
Introduction to Software Project Applications
Management Edited by Chonggang Wang, Tao Jiang,
Adolfo Villafiorita and Qian Zhang
ISBN 978-1-4665-5953-0 ISBN 978-1-4398-1601-1
 Multilevel
Security for
Relational
Databases
Osama S. Faragallah
El-Sayad M. El-Rabaie • Fathi E. Abd El-Samie
Ahmed I. Sallam • Hala S. El-Sayed
CRC Press
Taylor & Francis Group
6000 Broken Sound Parkway NW, Suite 300
Boca Raton, FL 33487-2742

© 2015 by Taylor & Francis Group, LLC

CRC Press is an imprint of Taylor & Francis Group, an Informa business

No claim to original U.S. Government works

Version Date: 20140929

International Standard Book Number-13: 978-1-4822-0540-4 (eBook - PDF)

This book contains information obtained from authentic and highly regarded sources. Reasonable efforts have been
made to publish reliable data and information, but the author and publisher cannot assume responsibility for the
validity of all materials or the consequences of their use. The authors and publishers have attempted to trace the
copyright holders of all material reproduced in this publication and apologize to copyright holders if permission to
publish in this form has not been obtained. If any copyright material has not been acknowledged please write and let
us know so we may rectify in any future reprint.

Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced, transmitted,
or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented, includ-
ing photocopying, microfilming, and recording, or in any information storage or retrieval system, without written
permission from the publishers.

For permission to photocopy or use material electronically from this work, please access www.copyright.com
(http://www.copyright.com/) or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood Drive, Danvers,
MA 01923, 978-750-8400. CCC is a not-for-profit organization that provides licenses and registration for a variety
of users. For organizations that have been granted a photocopy license by the CCC, a separate system of payment
has been arranged.

Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for
identification and explanation without intent to infringe.
Visit the Taylor & Francis Web site at
http://www.taylorandfrancis.com

and the CRC Press Web site at

http://www.crcpress.com
Contents

P r e fa c e xi
About the Authors xiii

C h a p t e r 1 C o n c e p t s o f D ata b a s e S e c u r i t y 1
1.1 Database Concepts 1
1.2 Relational Database Security Concepts 5
1.3 Access Control in Relational Databases 7
1.3.1 Discretionary Access Control 7
1.3.2 Mandatory Access Control 10
1.3.3 Role-Based Access Control 12
1.4 Work Objectives 13
1.5 Book Organization 15

C h a p t e r 2 B a s i c C o n c e p t of M u lt i l e v e l D ata b a s e
Securit y 17
2.1 Introduction 17
2.2 Multilevel Database Relations 18
2.3 Polyinstantiation 19
2.3.1 Invisible Polyinstantiation 20
2.3.2 Visible Polyinstantiation 21
2.3.3 Types of Polyinstantiation 22
2.3.4 Architectural Considerations in Supporting
Polyinstantiation 23
2.4 Multilevel Database Security Models 24
2.4.1 SeaView Model 24
2.4.2 Jajodia–Sandhu Model 26
2.4.3 Smith–Winslett Model 27

v
vi C o n t en t s

2.4.4 MLR Model 28

2.4.5 Belief-Consistent Multilevel Secure Data Model 29
2.5 Performance Study 30
2.5.1 Experimental Database Structure 30
2.5.2 Impact of Varying the Number of Tuples 31
2.5.3 Impact of Varying the Number of Attributes 31
2.5.4 Impact of Varying the Number of
Security Levels 32
2.5.5 Analysis of Experimental Results 32
2.6 Summary 33

o f MLS / D BMS M o d e l s
C h a p t e r 3 I mp l e m e n tat i o n 35
3.1 Introduction 35
3.2 SeaView Model 35
3.2.1 Selected Operation Procedure 35
3.2.2 Insert Operation Procedure 36
3.2.3 Update Operation Procedure 38
3.2.4 Delete Operation Procedure 38
3.3 Jajodia–Sandhu Model 40
3.3.1 Select Operation Procedure 40
3.3.2 Insert Operation Procedure 41
3.3.3 Update Operation Procedure 42
3.3.4 Delete Operation Procedure 43
3.4 Smith–Winslett Model 43
3.4.1 Select Operation Procedure 43
3.4.2 Insert Operation Procedure 44
3.4.3 Update Operation Procedure 46
3.4.4 Delete Operation Procedure 46
3.5 Multilevel Relational (MLR) Model 47
3.5.1 Select Operation Procedure 47
3.5.2 Insert Operation Procedure 48
3.5.3 Update Operation Procedure 50
3.5.4 Delete Operation Procedure 50
3.5.5 Uplevel Operation Procedure 52
3.6 Belief-Consistent Multilevel Secure Relational
Data Model 53
3.6.1 Basic Procedures for Operations 53
3.6.1.1 Xview (Label) Procedure 53
3.6.1.2 Pl (Label) Procedure 55
3.6.1.3 Sl (Label) Procedure 56
3.6.1.4 Ib (Label) Procedure 57
3.6.2 Select Operation Procedure 57
3.6.3 Insert Operation Procedure 57
3.6.4 Verify Operation Procedure 59
3.6.5 Update Operation Procedure 60
3.6.6 Delete Operation Procedure 62
 C o n t en t s vii

3.7 Comparative Study for Multilevel Database Models 64

3.8 Summary 64

C h a p t e r 4 F u n d a m e n ta l s o f I n f o r m at i o n E n c r y p t i o n 65
4.1 Introduction 65
4.2 Basic Concepts of Cryptography 65
4.2.1 Goals of Cryptography 65
4.2.2 Principles of Encryption 66
4.3 Classification of Encryption Algorithms 67
4.3.1 Classification according to Encryption
Structure 67
4.3.2 Classification according to Keys 68
4.3.3 Classification according to Percentage of
Encrypted Data 70
4.4 Cryptanalysis 70
4.5 Conventional Symmetric Block Ciphers 71
4.5.1 Data Encryption Standard (DES) 71
4.5.2 Double DES 72
4.5.3 Triple DES 74
4.5.4 International Data Encryption Algorithm
(IDEA) 74
4.5.5 Blowfish 75
4.5.6 RC5 Algorithm 75
4.5.6.1 RC5 Encryption Algorithm 75
4.5.6.2 RC5 Decryption Algorithm 76
4.5.6.3 RC5 Key Expansion 77
4.5.7 RC6 Algorithm 78
4.5.7.1 RC6 Encryption Algorithm 78
4.5.7.2 RC6 Decryption Algorithm 79
4.5.8 The Advanced Encryption Standard (AES) 81
4.6 Modes of Operation 83
4.6.1 The ECB Mode 83
4.6.2 The CBC Mode 85
4.6.3 The CFB Mode 85
4.6.4 The OFB Mode 86

C h a p t e r 5 E n c r y p t i o n - B a s e d M u lt i l e v e l M o d e l for

DBMS 89
5.1 Introduction 89
5.2 The Encryption-Based Multilevel Database Model 90
5.3 Manipulation 92
5.3.1 The INSERT Statement 92
5.3.2 The DELETE Statement 93
5.3.3 The SELECT Statement 94
5.3.4 The UPDATE Statement 96
5.3.5 The UPLEVEL Statement 97
viii C o n t en t s

5.4 Performance Study 100

5.4.1 Experimental Database Structure 100
5.4.2 SELECT Query 102
5.4.2.1 Impact of Varying the Number
of Tuples 103
5.4.2.2 Impact of Varying the Number
of Attributes 104
5.4.2.3 Impact of Varying the Number
of Security Levels 105
5.4.3 JOIN Query 105
5.4.3.1 Impact of Varying the Number
of Tuples 106
5.4.3.2 Impact of Varying the Number
of Attributes 107
5.4.3.3 Impact of Varying the Number
of Security Levels 107
5.4.4 UPDATE Query 108
5.5 Analysis of Experimental Results 109
5.6 Summary 111

C h a p t e r 6 F o r m a l A n a ly s i s f o r E n c r y p t i o n - B a s e d
M u lt i l e v e l M o d e l f o r D BMS 113
6.1 Introduction 113
6.2 The Encryption-Based Multilevel Model for
DBMS Definition 114
6.2.1 MLR Model Definition 114
6.2.2 Encryption-Based Multilevel Model for
DBMS Definition 115
6.3 Integrity Properties 117
6.3.1 Entity Integrity 117
6.3.2 Polyinstantiation Integrity 118
6.3.3 Data-Borrow Integrity 118
6.3.4 Foreign Key Integrity 118
6.3.5 Referential Integrity 119
6.4 Manipulation 119
6.4.1 The INSERT Statement 120
6.4.2 The DELETE Statement 120
6.4.3 The SELECT Statement 121
6.4.4 The UPDATE Statement 122
6.4.5 The UPLEVEL Statement 123
6.5 Soundness 124
6.5.1 Case 1: In the INSERT Operation 125
6.5.2 Case 2: In the DELETE Operation 125
6.5.3 Case 3: In the UPDATE Operation 126
6.5.4 Case 4: In the UPLEVEL Operation 126
 C o n t en t s ix

6.6 Completeness 126

6.7 Security 128
6.8 Summary 131
C h a p t e r 7 C o n c u r r e n cy C o n t r o l in M u lt i l e v e l
R e l at i o n a l D ata b a s e s 133
7.1 Introduction 133
7.2 Related Work 136
7.3 Enhanced Secure Multiversion Concurrency Control
Model 138
7.4 Performance Evaluation 139
7.4.1 Workload Model 140
7.4.2 System Model 140
7.4.3 Experiments and Results 141
7.5 Correctness of the Enhanced Secure Multiversion
Concurrency Control Model 143
7.5.1 Proof of Correctness 144
7.6 Summary 146
C h a p t e r 8 Th e I n s ta n c e - B a s e d M u lt i l e v e l S e c u r i t y
Model 147
8.1 Introduction 147
8.2 The Instance-Based Multilevel Security Model
(IBMSM) 150
8.2.1 Definition 1: The Property View 151
8.2.2 Definition 2: The Class View 151
8.2.3 Definition 3: The Instance View at
Classification Level Lj 151
8.3 The advant address of IBMSM 152
8.4 The Select Operation Procedure of the IBMSM 152
8.5 Insert Operation Procedure of the IBMSM 154
8.6 The Update Operation Procedure of the IBMSM 154
8.7 The Delete Operation Procedure of the IBMSM 157
8.8 Comparative Study for Polyinstantiation Models 157
8.9 Summary 159
C h a p t e r 9 Th e S o u r c e C o d e 161
9.1 Introduction 161
9.2 Screen Shots of the Prototype 161
9.3 Source Code of the Microsoft SQL Server 163
9.3.1 Source Code of the Data Security
Classification Level Tables 164
9.3.2 Source Code of the User Security
Classification Levels 166
9.3.3 Source Code of the Modifications to the
Base Table 169
9.3.4 Source Code of the View for Each Model of
the Multilevel Relational Database Models 174
x C o n t en t s

9.4 Source Code of the Microsoft Visual Studio C# 185

9.4.1 Source Code of the Classes 185
9.4.2 Source Code of the Login Form 199
9.4.3 Source Code of the Queries Form 206
9.4.4 Source Code of the Query Form 232
9.4.5 Source Code of the Concurrency
Control Form 259

References 269
Preface

In this book we try to look at encryption-based multilevel database

security through the eyes of database security researchers. Multilevel
security for relational databases is an interesting information secu-
rity topic. Most of the security models available for databases today
­protect them from outside, unauthorized users. A multilevel secure
database provides internal security in relationship with the user’s
type of access to the database. A multilevel secure database system
has been proposed to address the increased security needs of database
systems. Researchers are in need of new algorithms in this area with
their software implementation.
We summarize the main contributions of this book as follows:
1. This book is devoted to the issue of multilevel security in the
relational database.
2. Multilevel security for relational database models is c­ onsidered
in this book, with a comparison between them using different
evaluation metrics.
3. Modifications are presented to an existing multilevel security
model in the relational database either to speed or to enhance
performance.

xi
x ii P refac e

4. Formal analysis for data manipulation operations in m

­ ultilevel
security database models and mathematical proofs of sound-
ness, completeness, and security are studied.
5. Simulation experiments are presented for validation of the
discussed algorithms and modifications and also for investi-
gating the performance of multilevel database models.
6. The C# and Microsoft SQL server source codes for most of
the simulation experiments in this book are included at the
end of the book.
Finally, we hope that this book will be helpful for database and infor-
mation security.
About the Authors

Osama S. Faragallah received B.Sc.

(Hons.), M.Sc., and Ph.D. degrees in
computer science and engineering from
Menoufia University, Menouf, Egypt,
in 1997, 2002, and 2007, respectively.
He is currently ­ associate ­professor in
the Department of Computer Science
and Engineering, Faculty of Electronic
Engineering, Menoufia University. He
was a demonstrator from 1997 to 2002 and
has been assistant l­ecturer from 2002 to
2007. Since 2007, he has been a m ­ ember
of the teaching staff of the Department of Computer Science and
Engineering at Menoufia University. He is the co-author of about
100 papers in international journals, conference proceedings, and two
textbooks. His current research interests include network security,
cryptography, internet security, multimedia security, image encryp-
tion, watermarking, steganography, data hiding, medical image pro-
cessing, and chaos theory.

x iii
xiv A b o u t t he Au t h o rs

El-Sayed M. El-Rabaie was born in Sires

Elian, Egypt in 1953. He received a B.Sc.
degree (Hons.) in radio communications
from Tanta University, Tanta, Egypt in 1976,
an M.Sc. degree in communication systems
from Menoufia University, Menouf, Egypt
in 1981, and a Ph.D. degree in microwave
device engineering from Queen’s University
of Belfast, Belfast, U.K. in 1986. Until 1989,
Dr. El-Rabaie was a postdoctoral fellow in
the Department of Electronic Engineering,
Queen’s University of Belfast. He was invited to become a research fel-
low in the College of Engineering and Technology, Northern Arizona
University, Flagstaff in 1992, and a visiting professor at the Ecole
Polytechnique de Montreal, Montreal, QC, Canada in 1994. He has
authored and co-authored more than 180 papers and 18 textbooks. He
has been awarded the Salah Amer Award of Electronics in 1993 and the
Best (CAD) Researcher from Menoufia University in 1995. He acts as a
reviewer and member of the editorial board for several scientific journals.
Professor El-Rabaie was the head of the Electronic and Communication
Engineering Department at Menoufia University, and later, the Vice
dean of Postgraduate Studies and Research. Dr.  El-Rabaie’s research
interests include CAD of nonlinear microwave circuits, nanotechnol-
ogy, digital communication systems, and digital image processing. He is
a member of the National Electronic and Communication Engineering
Promotion Committee and a reviewer of quality assurance and accredi-
tation of Egyptian higher education.

Fathi E. Abd El-Samie received his B.Sc.

(Hons.), M.Sc., and Ph.D. degrees from
Menoufia University, Menouf, Egypt in
1998, 2001, and 2005, respectively. Since
2005, he has been a member of the teach-
ing staff in the Department of Electronics
and Electrical Communications, Faculty
of Electronic Engineering, Menoufia
University. He is currently a researcher
at KACST-TIC in radio frequency and
 A b o u t t he Au t h o rs xv

photonics for the e-Society (RFTONICs). He is a co-author of about

200 papers in international conference proceedings and j­ournals and
4 textbooks. His current research interests include image ­enhancement,
image restoration, image interpolation, super-­resolution reconstruc-
tion of images, data hiding, multimedia communications, medical
image processing, optical signal processing, and digital communica-
tions. In 2008, Dr. Abd El-Samie was the recipient of the Most Cited
Paper Award from the journal Digital Signal Processing.

Ahmed I. Sallam was born in Tanta, Al

Gharbia, Egypt in 1982. He received a B.Sc.
degree (Hons.) in computer science and engi-
neering from Al Azhar University, Faculty
of Engineering in 2005 and an M.Sc. degree
in computer science and engineering from
Menoufia University, Faculty of Electronic
Engineering, Egypt in 2012. He is a senior
software engineer at Qarun Petroleum
Company. His research interests include
database, database security, cryptography,
multimedia security, and image encryption.

Hala S. El-Sayed received her B.Sc.(Hons.),

M.Sc., and Ph.D. degrees in electrical engi-
neering from Menoufia University, Shebin
El-kom, Egypt in 2000, 2004, and 2010,
respectively. She is currently assistant
­professor in the Department of Electrical
Engineering, Faculty of Engineering,
Menoufia University. She was a demon-
strator from 2002 to 2004 and an assistant
lecturer from 2004 to 2010. Since 2010, she
has been a member of the teaching staff in
the Department of Electrical Engineering,
Faculty of Engineering, Menoufia University. Her research interests are
database security, network security, data hiding, image encryption, sig-
nal processing, wireless sensor network, robotics, secure building auto-
mation systems, and biometrics.
 1
C on cep ts of
D atabase S ecurit y

1.1  Database Concepts

A database system is a computerized system whose overall p ­ urpose

is to store and organize the data in a way that can be accessed, man-
aged, and modified on demand. A database system becomes an
important part of information management systems that enhances
the ability of organizations to manage their important data in an
easy way. A database system has many benefits that are described as
follows:
• Reducing the amount of data redundancy by ensuring that
the data are stored in one location and can be accessible to all
authorized users
• Improving data access to users through use of host and query
languages
• Enhancing data security
• Decreasing data entry, storage, and retrieval costs
• Allowing more flexibility for manipulating data
• Presenting greater data integrity and independence from
applications programs
The interaction between the user, other applications, and the
database itself can be performed through a software system called
a database management system (DBMS) [1], which is specially
designed to help the user to capture and analyze the stored data.
The general purpose of the relational database management system
is to be used as a tool to define, create, and manage the relational
database.

1
2 Securit y f o r Rel ati o n a l Data ba se s

Databases are classified according to their organizational approach.

The most common approach is the relational database [2]. In rela-
tional databases, all data are stored in a collection of relations.
A relation contains a group of rows that have the same attributes.
A row represents an object and information about that object. A rela-
tion is defined as a table, which is organized into rows (tuples) and
columns (attributes). All the data in the same attribute have the same
domain and stratify the same constraints. A domain presents the pos-
sible values for an attribute in the relation and the constraints make
some restrictions on the domain of an attribute.
In the relational database, a relation cannot contain duplicate tuples
because that would create ambiguities in retrieval.
In the relational database, to ensure uniqueness, each relation
should have an attribute (or a set of attributes), called the primary key,
that uniquely identifies every tuple of the relation [3]. A primary key is
called a simple key if it is a single attribute and it is called a composite
key if it is made up of several attributes.
In the relational database, a foreign key is an attribute (or collection of
attributes) in one relation that uniquely identifies a tuple of another rela-
tion. In other words, a foreign key is an attribute or a group of attributes
used to establish and enforce a link between the data in two relations.
A relational database consisting of independent and unrelated rela-
tions serves little purpose. The power of a relational database lies in
the relationship that can be defined between relations. The most cru-
cial aspect in designing a relational database is to identify the rela-
tionships among relations [4]. The types of relationship include:

• One to many: The primary key relation contains only one

tuple that relates to no, one, or many tuples in the related
relation.
• Many to many: Each tuple in both relations can relate to any
number of tuples (or no tuples) in the other relation. Many-
to-many relationships require a third relation, known as an
associate or linking relation, because relational systems can-
not directly accommodate the relationship.
• One to one: Both relations can have only one tuple on either
side of the relationship. Each primary key value relates to only
one (or no) tuple in the related relation.
 C o n c e p t s o f Data ba se Securit y 3

In the relational database, a stored procedure is an executable

code that is stored in the relational database. Stored procedures
group common operations, like inserting a tuple into a relation or
encapsulating complex business logic and calculations. Stored pro-
cedures are more performance than writing application code, for the
following reasons:
• There is no communication between the relational database
and other external applications.
• There is no need to compile and execute the stored procedure
for each instance, as the stored procedure is compiled once.
In the relational database, structured query language (SQL) is the
standard computer language for managing data in the r­ elational data-
base [5]. All relational database management systems, like Oracle,
Informix, and SQL Server, use SQL as a basic database ­language.
The SQL operation for manipulating the relation is described as
follows:

• Select operation: This operation is used to get groups of tuples

from the relation database. The SQL command for the select
operation is described as follows:

SELECT [A1,A2,...,An]
FROM R
WHERE P

where R is a relation, A1,A2,...,A n are the attributes from

relation R, and P is the condition of the select statement that
defines the tuples to be retrieved.
• Insert operation: This operation is used to insert tuples in
the relation. The SQL command for the insert operation is
described as follows:

INSERT
INTO R [A1,A2,...,An]
VALUES [a1,a2,...,an]

where R is a relation, A1,A2,...,A n are the attributes from

relation R, and a1,a2,...,an are values from domains of
A1,A2,...,A n that will be inserted.
4 Securit y f o r Rel ati o n a l Data ba se s

• Update operation: This operation is used to modify tuples in

the relation. The SQL command for the update operation is
described as follows:

UPDATE R
SET [A1=a1,A2=a2,...,An=an]
WHERE P

where R is a relation, A1,A2,...,A n are attributes from relation

R, a1,a2,...,an are values from domains of A1,A2,...,A n
that will be updated, and P is the condition of the update
statement that defines tuples that are to be updated.
• Delete operation: This operation is used to delete tuples from
the relation. The SQL command for the delete operation is
described as follows:

DELETE
FROM R
WHERE P

where R is a relation and P is the condition of the delete state-

ment that defines tuples that are to be deleted.
The internal mechanisms of SQL statement processing in the rela-
tional database management system (RDBMS) are presented in the
following five steps:
• The RDBMS parses the SQL statement by dividing it into
individual words and validating the statement syntax.
• The statement is then checked by the RDBMS against the
information schema. In addition, it ensures the user privileges
to execute the statement.
• The next step is the optimization of the SQL statement. The
query optimization process is defined as finding the efficient
way to execute the SQL statement.
• The next step is the generation of the execution plan for the
SQL statement based on the optimization process performed
during the previous step.
• The set of binary instructions created in the previous step is
executed by the RDBMS.
 C o n c e p t s o f Data ba se Securit y 5

1.2  Relational Database Security Concepts

In recent years, the need for securing relational databases has been
increased because of increased database attacks. Most companies
and organizations store their sensitive data in their own relational
databases. In recent years, attackers have been able to target large
relational databases that belong to large companies or large banks.
In the past, relational database attacks were common, but were fewer
than attacks on networks. Now, due to the increasing access of rela-
tional databases by many people, the chances of relational database
attacks have increased. The reason for these attacks is to obtain
money by getting sensitive information like credit card numbers or
Social Security numbers. Thus, it is important to protect relational
databases against these risks, and this is where database security
comes into place.
Relational database security can be defined as a system that
protects the confidentiality, integrity, and availability of the
­
­database [6]. Unauthorized access to a relational database indicates
a loss of confidentiality, unauthorized modification to the available
data indicates a loss of integrity, and lack of access to relational data-
base services indicates a loss of availability. Loss of one or more of
these basic facets will have a bad impact on the security of the rela-
tional database.
The protection of the confidentiality, integrity, and availabil-
ity of  the relational database will be illustrated in more detail as
follows:
• Confidentiality can be defined as a process for preventing
unauthorized access to the sensitive data that is stored in the
relational database. It can be ensured by applying encryption
to the data stored in the relational database. Encryption is a
process in which the information is encrypted in a way that
only authorized users can manage. The different levels for
encryption are described as follows:
• Data in transit means that an attacker can get access to the
sensitive information by observing the network between
the sender and the receiver.
• Data at rest means that an attacker can attack the infor-
mation stored in the relational database.
6 Securit y f o r Rel ati o n a l Data ba se s

There are many algorithms for encryption, such as data encryption

standards (DES), triple DES, and advanced encryption standards
(AES).
• Integrity can be defined as a process for preventing unauthor-
ized alteration to the sensitive data stored in the relational
database. The integrity of data is not only whether the data
is correct, but also whether it can be trusted and relied upon.
Database integrity ensures the accuracy and the consistency
of the data entered into the relational database.
• Availability can be defined as a process for preventing loss of
access to relational database services. Databases must have no
unplanned downtime.
In relational databases, many layers of security can be used to
ensure database security [7]. The security layers can be classified into
the following:
• Authentication can be defined as the concept of verifying the
identity of a user that needs to access the relational database.
Each user should identify himself before having access to data
stored in the relational database system. Authentication may
happen at different levels; for example, authentication can
be performed by the relational database itself or allow other
external methods to authenticate users.
• Access controls (authorization) can be defined as setting rules
that define whether the user has access to the data in the rela-
tional database. Authorization rules manage the modification
of data in the relational database. Access controls are proce-
dures that are defined to manage authorizations of the data in
the relational database.
• Integrity can be defined as a group of rules that present the
correct state of the relational database during the database
modification.
• Auditing can be defined as keeping track of all security rel-
evant actions issued by a user.
In this book, the main focus is directed toward aspects related to
access controls. An access control mechanism ensures data confiden-
tiality. Whenever a subject tries to access a data object, the access
 C o n c e p t s o f Data ba se Securit y 7

control mechanism checks the rights of the user against a set of

authorizations, usually stated by some security administrator. Access
control ensures that all direct accesses to database objects occur only
according to the rules governed by protection policies. There are two
different ways to enforce access control: discretionary access control
and mandatory access control.

1.3  Access Control in Relational Databases

Preventing unauthorized access to the relational database is the main

goal in implementing a secure database management system. Most of
the database users need only a specific permission on some parts in
the relational database to perform their jobs. Allowing them access
to the whole database is undesirable. So, a security policy should be
developed effectively to enable a group of users to access only required
parts of the database. Once the security policy is developed, it should
be enforced to achieve the level of security required. Three main
approaches in DBMS for access control are discretionary access con-
trol, mandatory access control, and role-based access control.

1.3.1  Discretionary Access Control

Discretionary access control (DAC) is based on granting and revok-

ing privileges for the usage of system objects (elations, views, columns,
etc.) [8]. The privileges are granted to (or revoked from) every subject
(user, account, program) separately. Discretionary access control poli-
cies allow access rights to be propagated from one subject to another.
This is called discretionary in the sense that the owner of data has
complete discretion regarding granting/revoking access privileges to
his data.
In the DAC, granting/revoking privileges can be performed by
the database administrator (DBA) [9]. The DBA has the following
responsibilities:
• Creating accounts for users that want to log on to the rela-
tional database system
• Granting/revoking privileges for users that want to access the
relational database system
8 Securit y f o r Rel ati o n a l Data ba se s

• Monitoring the relational database performance

• Managing the backup and recovery procedures of the rela-
tional database
The types of DAC privileges are described as follows:

• The account privilege: Each user holds privileges that are

independent of the relations in the database. For example,
the DBA grants/revokes privileges to a user to CREATE
TABLE, CREATE VIEW, DROP, and ALTER.
• The relation privilege: The DBA can specify the privilege to
modify each individual relation in the relational database.
For example, the DBA grants/revokes privileges to a user to
SELECT/MODIFY/REFERENCE privilege on specific
relation R. Discretionary access controls can be granted to
many objects in the relational database system, such as the
database, group of relations, one relation, set of the attributes
of one relation, and group of tuples of one relation.

Making a discretionary access controls decision based on the

content of data is called data dependent access control [10,11]. For
example, some users cannot see salaries that are over than $100,000.
The two approaches for implementing access controls in the relational
databases are described as follows:

• View-based access control: A relation is the physical loca-

tion in the relational database that stores the data in the
relational database. A view is the logical set of the stored
query on the data. Unlike the physical table in the relational
database, a view is a logical table computed from data in the
relational database dynamically when access to that view is
requested.
• Query modification: A query that is written by a user is
altered to include the limitation determined by the user’s
privileges. For example, the DBA grants user A to select only
the employees that are in the material department from the
relation of employees by the following grant statement:

GRANT SELECT ON Employees TO A

WHERE Department = ‘material’
 C o n c e p t s o f Data ba se Securit y 9

When user A needs to select all records from the employee’s

relation, his query will be changed and his privileges will
be added as follows:

SELECT * FROM Employees; Will be changed to:

SELECT * FROM Employees
WHERE Department = ‘material’;

In SQL, granting is performed by means of the GRANT statement,

which has the following general format:

GRANT privileges
[ON relation]
TO users
[WITH GRANT OPTION]

For example:

GRANT SELECT
ON Employees
TO A

In SQL, revoking is performed by means of the REVOKE state-

ment, which has the following general format:

REVOKE privileges
[ON relation]
FROM users

For example:

REVOKE SELECT
ON Employees
FROM A

DAC suffers from some drawbacks when applied to the relational

database:

• Enforcement of the security policy: DAC depends on the

concept of ownership of the data. In DAC, the user who
10 Securit y f o r Rel ati o n a l Data ba se s

creates the object in the relational database is the owner of

this object and can grant access to other users on this object.
This has the disadvantage that the enterprise cannot man-
age and enforce its security requirements without includ-
ing all the users that create all the objects in the relational
database.
• Cascading authorization: For example, consider three users:
U1, U2, and U3. User U2 has the privilege on object O from
U1 and grants this privilege to U3. Later, U1 grants privilege
to U3 on the same object O, but U2 revokes privilege from
privilege U3 for some reason. The effect of these operations is
that U3 still has the access privilege (from U1) to access object
O although U2 revoked privilege.
• Trojan horse attacks: A Trojan horse can be used to grant a
certain privilege of a user on an object to another user without
knowing any information about the user.
• Update problems: In DAC, view-based protection is a l­ogical
query that has no physical data in the relational  ­database.
The disadvantage of view-based protection is that not all data
can be updated through certain views.

1.3.2  Mandatory Access Control

While DAC is concerned with ensuring the privilege to access data in

the relational database, mandatory access control (MAC) is in addi-
tion ensuring the flow of data in the relational database system. MAC
depends on the security level associated with each object in the rela-
tional database and each user. A security level on an object is defined
as a security classification, while the security level on a user is defined
as a security clearance. MAC is defined as multilevel security (MLS);
because of each user and each object, one of the multiple security
­levels can be assigned.
A complete understanding of MLS will not happen without
understanding its origins [12]. The U.S. military has a historical
isolated database that contains its sensitive information. The sensi-
tive data are classified into different security levels and must be
processed on dedicated systems that do not provide access to users
 C o n c e p t s o f Data ba se Securit y 11

outside the intended security level. The main limitations can be

described as follows:

• Redundant databases: To store data in the relational database

into different security levels, a different database should be
created for each security level.
• Redundant workstations: There is a need to have different
workstations to get each type of datum.
• High cost of IT infrastructure: There is a risk in sharing the
network resources.
• Inefficiency: Users need to get privileges on several relational
database systems to perform their duties.

Multilevel security was the solution. MLS allows the data in different
security classification levels to be accessed by users that have different
security clearance levels.
The Bell and LaPadula model was the basic model that i­ntroduced
the concept of MLS [13]. This model depends on definitions of objects
and subjects. An object like relation, a tuple, or an attribute is a passive
entity. A subject like user or program is an active process that needs to
have a privilege on objects. Every object is assigned to a security level
(classification), and every subject is assigned to a security level (clear-
ance). Security levels are defined as labels. A label contains two compo-
nents: a hierarchical component and a group of unordered categories.
The hierarchical component presents the security levels of the data.
For example, a company might define the security levels of its sensitive
data as top secret, secret, confidential, or unclassified. The unordered
categories are used to define the sensitivity of the leveled data.
Multilevel security is based on the Bell and LaPadula model
and formalized by two rules. LaPadula rules are described as
follows [14]:

• The simple property (no read up): A subject is allowed to read

an object if the subject’s security clearance level is greater than
or equal to the object’s security classification level.
• The star property (no write down): A subject is allowed to
write to an object if the object’s security classification level is
greater than or equal to the subject’s security clearance level.
12 Securit y f o r Rel ati o n a l Data ba se s

The star property allows a lower security level subject to write data
to a higher security level object. This can result in overwriting and
therefore modifying of higher security level objects by lower security
level subjects. Thus, MLS enforces a stronger star property to restrict
each subject to write at his own security level:
• Strong star property: A subject is allowed to write to an object
if the subject’s security clearance level is equal to the object’s
security classification level.

1.3.3  Role-Based Access Control

The main motivation behind role-based access control (RBAC) is the

necessity to simulate the structure of the natural security policies of
the organization. RBAC is based on the roles that users have. Roles
are similar to those of the user groups in access controls.
In RBAC, a role is defined as a group of actions and duties belonging
to a specific activity [15]. The role may present a user’s job (e.g., buyer),
or it may define an action that the user should do (e.g., order material).
Instead of defining all the permissions to each one of the users that
performs the same task, permissions on objects can be defined for roles.
The user that is assigned to a role can perform all actions that the role is
authorized to do. The components of RBAC can be described as follows:

• Role–permission relationships: This component manages

granting/revoking permission to a specific role.
• User–role relationships: This component defines how to assign
users to a specific role.
• Role–role relationships: This component defines how to make
a role a member of another role.

RBAC has three security principles:

• Least privilege: RBAC allows a user to access objects with the
least privilege required for the specific task that is needed to
be performed. This minimizes the Trojan horses attack.
• Separation of duties: RBAC ensures that no user has enough
privileges to misuse the system on his own.
• Data abstraction: This is supported by means of abstract priv-
ileges such as credit and debit for an account.
 C o n c e p t s o f Data ba se Securit y 13

In RBAC, database administrators can manage access at a level of

abstraction that is identical to the way that organizations perform their
business. This is achieved by organizing users’ tasks through the imple-
mentation of roles, role hierarchies, relationships, and constraints.
In role-based access control, roles can have overlapping duties and
privileges, so users assigned many roles may need to do common tasks.
Some general tasks may be done by all users. In this situation, there is
no need to repeat these common tasks for each role created. Role hier-
archies can be performed to present the real structure of an enterprise.
RBAC has two types of role hierarchies:
• General hierarchical RBAC is based on the concept of mul-
tiple inheritances that present the ability to obtain permission
inheritance from more than one role and to inherit user mem-
bership from more than one role.
• Limited hierarchical RBAC is limited to a single descendant.
Limited role hierarchies do not support multiple inheritances.

1.4  Work Objectives

In the digital world nowadays, database security has become increas-

ingly important since the database is the primary repository of infor-
mation for organizations and governments. More and more research
has been developed in database security to protect the data from pos-
sible unauthorized instructions. Most of the security models available
for databases today protect them from outside and unauthorized users.
Multilevel security for relational databases provides internal secu-
rity in relationship with the user’s access to the relational database.
Relational database multilevel security systems have been proposed
to address the increased security needs of relational database systems.
Although multilevel concepts were originally developed to support
confidentiality in military systems, there are now many commercial
systems that use multilevel security policies.
Although many models have been developed to support multilevel
security in the relational database, there are many problems in imple-
menting multilevel security policies. These problems included complexity
in designing multilevel security for the relational database and increas-
ing the database size according to the classification level columns added
to the original database to support multilevel security in the database.
14 Securit y f o r Rel ati o n a l Data ba se s

This book will introduce the concept of multilevel security in the

relational database, will present a comparative study for previous
models that support multilevel security policies in the relational data-
base, and will show the weakness and the strength of each model.
Also, in this book a prototype will be implemented to be used as
a research tool for a performance evaluation of multilevel security for
relational database (MLS/DBMS) models.
This book will give a complete view of an encryption-based mul-
tilevel security database model, which is a combination of multilevel
security for the relational database and encryption system by encrypt-
ing each record with an encryption key according to its security class
level. This model is characterized by three achievements:
• Utilizing an encryption system as a second security layer over
the multilevel security layer for the database
• Reducing the multilevel database size
• Improving the response time of data retrieval from the mul-
tilevel database
The goal of these three achievements is to increase robustness
against database attacks and enhance the performance of data manip-
ulating operations such as select, insert, update, and delete in the mul-
tilevel database. The effectiveness of an encryption-based multilevel
security database model is verified through the mathematical proof of
the soundness of, completeness of, and security for multilevel security
for relational database system.
The encryption-based multilevel security database model achieves
good quality because it satisfies integrity properties such as entity
integrity, polyinstantiation integrity, data borrowing integrity,
­foreign key integrity, and referential integrity of the multilevel data-
base. Also, this book will illustrate the C# and Microsoft SQL server
source codes for the implementation of the encryption-based multi-
level security database model.
Concurrency control is used in relational databases to manage the
concurrent execution of operations by different subjects on the same
data object. This book will explain the concept of concurrency con-
trol and will define its impacts on multilevel security for relational
databases. It will create a survey for studying the secure concurrency
control protocols that are proposed in multilevel security for relational
 C o n c e p t s o f Data ba se Securit y 15

databases and will implement a prototype to be used to perform a

series of experiments to measure the performance cost for applying
the concurrency control in multilevel relational databases.
This book will also define the implementation of the data manip-
ulation operations for the instance-based multilevel security model
(IBMSM) since the IBMSM proposes two layers: the instance layer
and the class layer.

1.5  Book Organization

• In Chapter 2, the basic concept of multilevel relational data-

base security will be discussed. This chapter will explain the
models that support multilevel database security and will
introduce a comparative study between the multilevel data-
base security models.
• In Chapter 3, the implementation of multilevel relational
database security models will be illustrated and the perfor-
mance study will be instrumented to compare the multilevel
secure database (MLS/DBMS) models.
• In Chapter 4, an overview of the encryption algorithms that
are applied will be presented.
• In Chapter 5, the encryption-based multilevel security data-
base model will be described and the implementation of a
working prototype to be used as a research tool for studying
principles and mechanisms of the model will be explored.
• In Chapter 6, the formal model for the data manipula-
tion operations in the encryption-based multilevel security
­database model will be presented and the mathematical proofs
of soundness, completeness, and security will be proved.
• In Chapter 7, the concept of concurrency control in multilevel
security for relational databases will be introduced.
• In Chapter 8, the implementation of the data manipulation
operations for the instance-based multilevel security model
(IBMSM) will be defined.
• In Chapter 9, the C# and Microsoft SQL server source codes
for the implementation of multilevel relational database secu-
rity models will be presented.
 2
B asi c C on cep t of
M ultile v el D atabase
S ecurit y

2.1 Introduction

Mandatory access control (MAC) is a method of restricting

­unauthorized users from accessing objects that contain some sensi-
tive information. An implementation of MAC is multilevel security
(MLS), which has been developed mainly for computer and data-
base systems at highly sensitive government organizations such as
the intelligence community or the U.S. Department of Defense.
In multilevel security, each datum is defined as an object and has a
security class level (classification), and each user is defined as a subject
and has a security class level (clearance). The class level of an object or
a subject A is called a label and is denoted as L (A). The access con-
trol in multilevel security is based on the Bell–LaPadula model [16],
which has the following properties:
• The simple security property: A user, s, is allowed a read access
to an object, o, only if L (s) is higher than or identical to L (o).
• The *-property: A user, s, is allowed a write access to an
object, o, only if L (s) is identical to or lower than L (o).
• The strong * property: A user, s, is allowed a write access to an
object, o, only if L (s) is identical to L (o).
The goal of the simple security property is to prevent a subject with
low clearance from accessing a higher object (that is, no read-up),
while the goal of the *-property, as shown in Figure 2.1, is to prevent
a subject with a high clearance from writing data to a subject that is
cleared at a lower level (that is, no write-down).

17
18 Securit y f o r Rel ati o n a l Data ba se s

Subject Read High Security

A
(High level) Level Object

Subject Read Low Security

B
(Low level) Write Level Object

Figure 2.1  Illegal information flow in multilevel secure data model.

2.2  Multilevel Database Relations

A relational database consists of a relation schema and a ­relation

instance. The relation schema can be defined as the structure of the
relational database that consists of the relation’s name, the name
of each attribute (or column), and the domain of each attribute.
A relation schema is denoted as R(A1;...; A n), where each Ai is an
­attribute in the relational schema. An instance of a relation can be
defined as a set of  tuples (rows) in which each tuple has the same
number of attributes as the relation schema. A relation instance is
denoted as r(a1;...; an).
In the multilevel relational database, each data attribute in the
schema is associated with a security classification attribute called
the classification attribute [17]. Also, the multilevel relational database
schema contains an additional attribute, called tuple ­classification,
that identifies the security classification of each tuple. The multi-
level relation database schema can be denoted as R(A1; C1;...; A n;
Cn; TC), where each Ai is a data attribute, each Ci is a classification
­attribute for Ai, and TC is the tuple-class attribute. The primary data
attribute is denoted as PK and its corresponding classification attri-
bute can be denoted as CPK .
For simplicity, the multilevel security hierarchy has four levels of
increasing sensitivity. These levels, from lowest to highest, are unclas-
sified (U), confidential (C), secret (S), and top secret (TS). Data in
relational multilevel database security are labeled with their own
security classification. Users who need to access data should have the
appropriate security classification level.
 Multil e v el Data ba se Securit y 19

Table 2.1  Employee Relation in Multilevel Form

EMPLOYEE DEPARTMENT SALARY TC
Ahmed U Accounting U 7,000 U U
Ahmed U Sales S 7,000 U S
Ahmed C IT C 10,000 C C
Mohamed TS Telecom TS 5,000 TS TS

Table 2.2  Employee Relation Instance for a C User

EMPLOYEE DEPARTMENT SALARY TC
Ahmed U Accounting U 7,000 U U
Ahmed C IT C 10,000 C C

Table  2.1 shows a multilevel relation employee, which has three

data attributes: employee (employee name; the primary key), depart-
ment (department), and salary (salary). In addition to data attributes,
it has the tuple class attribute TC. Instead, the security class of each
attribute is shown to the right of its data value. According to the
simple security property of the Bell–LaPadula model, a multilevel
relation should be differently viewed by different users, depending on
their clearances. For instance, a user with L clearance will see the
filtered relation instance employee, as shown in Table 2.2, while a TS
user will see the entire relation of Table 2.1.

2.3 Polyinstantiation

The covert channel represents the problem of the possibility that a

lower level user can predict some unauthorized information from
a higher security level [18]. Assume that the database contains an
employee named Ahmed (with security level C) and that another user
(with security level U) decides to insert a tuple that contains Ahmed
as the name of the employee. If that insert is rejected, a U level user
can know that there is an employee named Ahmed that exists in the
multilevel relational database on some higher security level. A poly-
instantiation integrity property can solve the covert channel problem
that would be opened “by default” every time the lower level user tries
to insert a tuple with the primary key attribute that already exists in
the database on some higher security level.
20 Securit y f o r Rel ati o n a l Data ba se s

In the multilevel relational database, the relation can be polyin-

stantiated when it contains two or more tuples with the same primary
key values. Polyinstantiation occurs in the following two situations:
• Invisible polyinstantiation can occur when a user with a low
security level inserts data in an attribute that already contains
data with a higher security level.
• Visible polyinstantiation can occur when a user with a high
security level inserts data in an attribute that already contains
data at a lower security level.

2.3.1  Invisible Polyinstantiation

The invisible polyinstantiation (polylow) can occur when a user at a

low level of security needs to insert a new tuple that contains the same
primary key as in an existing tuple with a high security level [19].
In  the invisible polyinstantiation, the multilevel relational database
security has three choices:
• Informing the user that the new tuple exists at a higher secu-
rity level and therefore the insertion of the new tuple will
be rejected: This choice leads to the covert channel problem
because the user with a low security level gets unauthorized
information at a high level of security.
• Replacing the existing tuple at a high security level with the
new tuple being inserted with a low security level: This choice
allows the user with a low security level to overwrite data not
visible to him and thus break the data integrity.
• Inserting the new tuple with a low security level without
modifying the existing tuple at the high security level: This
choice leads to the polyinstantiation of the tuple because there
are two tuples in the relation with the same primary key but
in different security levels.
For example, consider the following scenario:
• A user with an S security level updates the salary to be 10,000
in Table 2.3. U user sees no change in the relation, as shown in
Table 2.3, but S user sees the relation after an update, as shown
in Table 2.4.
 Multil e v el Data ba se Securit y 21

Table 2.3  Employee Relation in MLS Form

EMPLOYEE DEPARTMENT SALARY
Ahmed U Accounting U Null U

Table 2.4  S User View for Employee Relation

after Updating the Salary to 10,000 by S User
EMPLOYEE DEPARTMENT SALARY
Ahmed U Accounting U 10,000 S

Table 2.5  U User View for Employee Relation

after Updating the Salary to 7,000 by U User
EMPLOYEE DEPARTMENT SALARY
Ahmed U Accounting U 7,000 U

Table 2.6  S User View for Employee Relation

after Updating the Salary to 7,000 by U User
EMPLOYEE DEPARTMENT SALARY
Ahmed U Accounting U 7,000 U
Ahmed U Accounting U 10,000 S

• Next, a U user updates the salary to be 7,000. The m

­ odification
cannot be rejected because this leads to the covert channel
problem.
• Thus, there are two options left: The first option is that the
salary attribute can be overwritten in place at the cost of
destroying secret data. This results in breaking the data integ-
rity, as shown in Table 2.5. The second option is the invisible
polyinstantiation, which will modify the relation in Table 2.4
to the relations in Table 2.6.

2.3.2  Visible Polyinstantiation

The visible polyinstantiation (polyhigh) can occur when a user at a

high level of security needs to insert a new tuple that contains the
same primary key as in an existing tuple with a low security level [20].
22 Securit y f o r Rel ati o n a l Data ba se s

In visible polyinstantiation, the multilevel relational database security

has three choices:
• Notifying the user that the new tuple exists at a lower secu-
rity level and therefore the insertion of the new tuple will
be rejected: This choice leads to the denial of service prob-
lem because the new tuple that needs to be inserted by the
user with high security is rejected by a user in the low level of
security.
• Replacing the existing tuple at a high security level with the
new tuple being inserted with a low security level: This choice
leads to the covert channel problem because the user with a
low security level gets unauthorized information at a high
level of security.
• Inserting the new tuple with a low security level without
modifying the existing tuple at the high security level: This
choice leads to the polyinstantiation of the tuple because there
are two tuples in the relation with the same primary key but
in different security levels.

2.3.3  Types of Polyinstantiation

There are two different types of polyinstantiation [21]:

• Entity polyinstantiation: In the multilevel relational database,
the entity polyinstantiation can occur when a relation con-
tains more than one tuple with the same primary key val-
ues, but with different access class values for the primary key.
As  shown in Table  2.7, there are two tuples with the same
primary key (Ahmed) but with two different classes.
• Attribute polyinstantiation: In the multilevel relational data-
base, the attribute polyinstantiation can occur when a relation
contains two or more tuples with an identical primary key
and its security level values, but with different values for one

Table 2.7  Entity Polyinstantiation

EMPLOYEE DEPARTMENT SALARY
Ahmed U Accounting U 7,000 U
Ahmed S Sales S 10,000 S
 Multil e v el Data ba se Securit y 23

or more remaining attributes. As shown in Table 2.8, there

are two tuples with the same primary key (Ahmed) and the
same classes (U), but with different classes in the next two
attributes (Department, Salary).

2.3.4  Architectural Considerations in Supporting Polyinstantiation

There are two different architectures of polyinstantiation:

• No MAC privileges architecture: As shown in Figure  2.2,
the no MAC privileges (NMP) architecture has separated the
relational database into smaller relational databases. This sep-
aration depends on the security level of each relational data-
base. Also, the relational database management system has
divided the process into a smaller process that can access all
databases with data at or below its level. This architecture has
bad data retrieval performance because a user will get the data
from multiple single-level database fragments [22].
• Trusted subject architecture: As shown in Figure 2.3, the trusted
subject architecture has a single database to be used in saving
data at multiple security levels, and the database management
system is trusted to guard against illegal information flows [23].
Table 2.8  Attribute Polyinstantiation
EMPLOYEE DEPARTMENT SALARY
Ahmed U Accounting U 7,000 U
Ahmed U Sales S 10,000 S

DBMS High DBMS Low

User High Low User
Process Process

System Operating Trusted

Database High Database Low

Fragment Fragment

Figure 2.2  No MAC privileges architecture.

24 Securit y f o r Rel ati o n a l Data ba se s

User High Trusted DBM Low User

Trusted Operating System

Multilevel
Database

Figure 2.3  Trusted subject architecture.

Table 2.9  Comparison between Polyinstantiation Architectures

CRITERIA MODEL POLYINSTANTIATION TRUSTED DBMS DATABASE FILES PERFORMANCE
No MAC Implicitly Does not Multiple of single Bad data
privileges demand trust database files retrieval
architecture in DBMS performance
Trusted subject Explicitly Demands trust Single database Improved data
architecture in DBMS is used to save retrieval
data at multiple performance
security levels

Table 2.9 gives a comparison between the previous two approaches to

illustrate the advantages and disadvantages of each approach.

2.4  Multilevel Database Security Models

There are many multilevel relational database security models—for

example, SeaView and those proposed by Sandhu–Jajodia, Smith–
Winslett, etc. This section will present an overview of these models
and identify the strengths and the weaknesses of each model.

2.4.1  SeaView Model

In the secure data views (SeaView) model, security levels are assigned
to each data element in the attributes of the tuples in the relation, as
shown in Table 2.7. In the SeaView model, data are stored in a set of
single-level fragments and the multilevel relations are implemented as
views over these single-level relations [24].
 Multil e v el Data ba se Securit y 25

There are two algorithms that are used in the implementation of

the SeaView model:
• The decomposition algorithm divides the multilevel relation
into single-level fragments.
• The recovery algorithm reconstructs the original multilevel
relation from the fragments.
In the SeaView model, the decomposition of the multilevel relations
into single-level ones is performed by applying two different types of
fragmentation: horizontal and vertical. Thus, the multilevel relation in
Table 2.8 will be stored as five single-level fragments (one primary key
group relation and four attribute group relations), as shown in Table 2.10.
The SeaView model has many problems due to the decomposition
and recovery algorithms. These problems will be mentioned as follows:
• Repeated joins: Due to the vertical fragmentations that
are  used in the SeaView model, the query that involves
­multiple attributes will use a lot of repeated left outer joins
between the several single-level relations to get the result.

Table 2.10  SeaView Decomposition of

Table 2.8 into Five Single-Level Base Relations
A

EMPLOYEE
Ahmed U
B

EMPLOYEE DEPARTMENT
Ahmed U Accounting U
C

EMPLOYEE SALARY
Ahmed U 7,000 U
D

EMPLOYEE DEPARTMENT
Ahmed U Sales S

E
EMPLOYEE SALARY
Ahmed U 10,000 S
26 Securit y f o r Rel ati o n a l Data ba se s

• Spurious tuples: When the SeaView recovery algorithm is

applied to the single-level relations, additional tuples will be
inserted into the original relation. These additional tuples
are called spurious tuples and are a result of repeated joins
between single-level relations.
• Incompleteness: The SeaView decomposition algorithm puts
limitations on the capability of the database. Several relation
instances that have realistic and useful interpretations in real
life cannot be realized in the SeaView model.
• Left outer joins: The SeaView recovery algorithm is based on
the left outer join of relations. It is well known that join is a
high-cost operation and should be avoided as much as possible.

2.4.2  Jajodia–Sandhu Model

The Jajodia–Sandhu model is derived from the SeaView model.

It modifies the algorithm that decomposes a multilevel relation into
single-level fragments and it also modifies the recovery algorithm
that reconstructs the original multilevel relation [25].
In the Jajodia–Sandhu model, the decomposition algorithm uses
only horizontal fragmentation since no vertical fragmentations are
required. This results in improving the recovery algorithm in the
Jajodia–Sandhu model over the recovery algorithm in the SeaView
model because it is possible to reconstruct the multilevel relation
without having to perform join operations; only union operations are
required to reconstruct the multilevel relation.
For example, the relation in Table  2.8 will be decomposed into
two single-level fragments, as shown in Table  2.11. This provides

Table 2.11  Jajodia and Sandhu Decomposition

of Table 2.8 into Two Single-Level Base Relations
A

EMPLOYEE DEPARTMENT SALARY TC

Ahmed U Accounting U 7,000 U U

EMPLOYEE DEPARTMENT SALARY TC

Ahmed U Sales S 10,000 S S
 Multil e v el Data ba se Securit y 27

the simplicity of tuple level labeling, combined with the flexibility of

­element-level labeling.
There are two major problems in the Jajodia–Sandhu model [26]:
• Semantic ambiguity: Suppose that there are two tuples in the
relations with security levels U and S and there is no tuple
with security level TS. If a user with security level TS needs
to get information from the relation, he cannot decide which
is the correct information because the values from the U tuple
and the S tuple in the relation will be retrieved in the result
of the query.
• Operational incompleteness: Suppose that there are two
incomparable security levels, M1 and M2, whose least upper
bound is the security level S and greatest lower bound is the
security level U. There is no way for a user at security level S
to insert tuples that contain attributes with security levels at
U, M1, and M2.

2.4.3  Smith–Winslett Model

In the Smith–Winslett model, the multilevel relational database is

seen as a set of ordinary relational databases where all the databases
share the same schema. This model does not support security at the
level of each single attribute. The security level can be assigned only to
the primary key attributes and the tuples as a whole [27].
The multilevel relational scheme is given as R(APK, CPK, A1...,
An,TC), where Apk is denoted as the primary key data attribute, Cpk
is the primary key classification attribute that contains the security
level of the primary key data attribute, A1...An is denoted as the data
attributes, and TC is denoted as the tuple classification attribute that
­contains the security level of the tuple.
An example relation is given in Table 2.12, where a user can see the
tuples from his own security level and the tuples from all lower secu-
rity levels. A user accepts the tuples from his own security level only.

Table 2.12  Smith–Winslett Model

EMPLOYEE DEPARTMENT SALARY TC
Ahmed U Accounting 7,000 U
Ahmed S Sales 10,000 S
28 Securit y f o r Rel ati o n a l Data ba se s

According to these rules, an update and read access are defined.

A database modification (insert, delete, and update) from a user can
only alter data at the user’s security level. A query from a user at secu-
rity level L can access data from exactly those databases whose level is
not higher than the level L.
In this model, a semantics based on the concept of belief has been
added. The Smith–Winslett model is also known as the belief-based
semantics model and also introduced the concept of a base tuple.
The base tuple is the lowest security level of database tuple where the
existence of an entity is asserted. As such, the update procedure elimi-
nates the problems present in the Jajodia–Sandhu model, but restricts
the scope of an update to a single entity.

2.4.4  MLR Model

The multilevel relation (MLR) model presents the concept of data-­

borrow integrity, which ensures upward information flow. Modifications
to the data at a lower security level can be automatically propagated to
higher security levels that need to borrow those data [28].
This model is concerned with eliminating the semantic ambiguity
problem in the Jajodia–Sandhu model. A user with a security level can
accept data that consist of two parts: data that have the same secu-
rity level and data that are borrowed from lower security level users.
The data a subject can see are those accepted by subjects at the data’s
level or at levels below that.
The multilevel relational scheme is given as R(APK,CPK,A1,
C1,...,A n,Cn,TC), where Apk is denoted as the primary key data attri-
bute, Cpk is the primary key classification attribute that contains the
security level of the primary key data attribute, A1 ... A n is denoted as
the data attributes, C1...Cn is denoted as the data classification attri-
butes that contain the security level of the primary key data attributes,
and TC is denoted as the tuple classification attribute that contains
the security level of the tuple.
In Table 2.13 we can see that a user with S security level has used
the UPLEVEL command to indicate that he believes the first tuple
and insert the second tuple with S security level. However, there is no
way for the user with high-level security to define his belief or disbe-
lief in the tuple.
 Multil e v el Data ba se Securit y 29

Table 2.13  MLR Model

EMPLOYEE DEPARTMENT SALARY TC
Ahmed U Accounting U 7,000 U U
Ahmed U Accounting U 7,000 U S
Mohamed U Sales U 10,000 U U

2.4.5  Belief-Consistent Multilevel Secure Data Model

In the belief-consistent multilevel secure (BCMLS) data model, each

attribute is associated to another security level attribute [29]. The secu-
rity level attribute is a security label that has one or more letters and
each letter defines a security level. Each security level letter in the label
should be greater than the security level to its left letter. The first letter
defines the security level at which the value of the attribute was entered
and is called the primary security level of that attribute. Information
that has a security level equal to the primary security level of the label
is believed to be true by users. The letters that follow the first letter of
the label are called secondary levels and they define the security levels
for users that believe the information, and this belief can be either
true or false. No symbol (−) before the letters means that there are
secondary levels where the information is believed to be true. If there
is a symbol (−) before the letters, this means that there are secondary
levels where the information is believed to be false. A lower level tuple
can be interpreted by a higher level user as true or false. The false tuple
can be interpreted as a cover story tuple or mirage tuple.
If a lower level tuple presents the same entity as other higher secu-
rity level tuples, the lower security level tuple is defined by a higher
security level user as a false tuple that defines a cover story tuple.
If a false tuple does not correspond to any real-world entity in the
belief of a higher security level user, such a tuple defines a mirage
tuple for the higher level user.
Information that is labeled would be defined as true by users
with U and C security levels and as false by users on the S security
level. The  BCMLS model defines the primary security level as the
level where the tuple was originally inserted into the database and
this tuple is called a base tuple. In Table 2.14, the UC-S label indi-
cates U and C beliefs of true in the information and S belief of false
in the same information. The user sees and believes the contents of
30 Securit y f o r Rel ati o n a l Data ba se s

Table 2.14  Belief-Consistent Multilevel Secure

Relational Data Model
EMPLOYEE DEPARTMENT SALARY TC
Ahmed U Accounting U 7,000 U U
Mohamed UC-S Sales UC-S 10,000 UC-S UC-S

the database at his own security level and also can access the contents
of the database at lower levels. The user also has access to the beliefs
of users at lower levels. Users can define their beliefs through the new
verify mechanism. The users at each security level can decide what
information is accepted. The great advantage of the BCMLS model is
the fact that the accepted information does not need to be replicated
or borrowed.

2.5  Performance Study

This section describes the performance study of relational multilevel

database models—SeaView, Jajodia–Sandhu, Smith–Winslett, MLR,
and belief-consistent models—and illustrates the impact of varying
the size and structure of the relational multilevel database on the per-
formance of these models.
The machine that is used for the implementation of the perfor-
mance study consists of CPU speed of 2.2 GHz, physical RAM size
of 3 GB, and hard disk size of 320 GB. The software that is used in
the implementation is Microsoft SQL server 2008 R2 and the experi-
ments’ measurements were captured at the machine using a moni-
toring tool provided by the Microsoft SQL server. The experiments
measure the impact of changing the number of tuples, the number of
attributes, and the number of security levels on the performance of
the relational multilevel database models. These experiments define
the CPU response time (in seconds) as metric. For each query, the
monitoring tool observes the time that is taken for the system to give
the result of the query.

2.5.1  Experimental Database Structure

An experimental database, the timesheet database, consisting of four

relations, was created and populated to facilitate the performance
study. The employee relation provides information about employees,
 Multil e v el Data ba se Securit y 31

the departure relation is used to store the departure notice of each

employee when he leaves the site of the work, the timesheet relation
is used to store the timesheet of each employee every day, and the
annual rights relation is used to store the rights of each employee
every year.

2.5.2  Impact of Varying the Number of Tuples

This experiment was designed to determine if the cost of p ­ rocessing

varying numbers of tuples has an impact on the performance of
the multilevel database models. We chose this experiment because
the size of a database is, in part, based on the number of its tuples
(records), and the number of tuples processed during each t­ ransaction
could determine how long it takes to return a response to a user
(Figure 2.4).

2.5.3  Impact of Varying the Number of Attributes

This experiment was designed to determine if the cost of processing

varying numbers of attributes has an impact on the performance of
the multilevel database models (Figure 2.5).

8
7
6
Response Time (s)

5
4
3
2
1
0
0 500 1000 1500 2000
Number of Tuples
SeaView Jajodia-Sandhu Smith-Winslett
MLR Belief-Consistent

Figure 2.4  The impact of varying the number of tuples on the performance of a multilevel
database.
32 Securit y f o r Rel ati o n a l Data ba se s

6
Response Time (s)

0
2 3 4 5 6
Number of Attributes
SeaView Jajodia-Sandhu Smith-Winslett
MLR Belief-Consistent

Figure 2.5  The impact of varying the number of attributes on the performance of a multilevel
database.

2.5.4  Impact of Varying the Number of Security Levels

This experiment was designed to determine if the cost of processing

varying numbers of security levels has an impact on the performance
of the multilevel database models (Figure 2.6).

2.5.5  Analysis of Experimental Results

From the previous experimental results, the performance of the

Smith–Winslett model is the best because it does not support s­ ecurity
classification at the level of each single attribute; the access classes can
be assigned only to key attributes and to tuples as a whole. The MLR
model offers less performance than the Smith–Winslett model because
it supports classification at the level of each single attribute. The
belief-consistent model offers less performance than the MLR model
because it supports a combination of classification levels for each single
­attribute to enable the user to assert his beliefs of lower level users’
information. The Jajodia–Sandhu model has performed badly because
of the impact of union operation between single-level relations in the
recovery algorithm. The SeaView model performs very badly because
of the impact of join operation between vertical, single-level relations
 Multil e v el Data ba se Securit y 33

2.5

2
Response Time (s)

1.5

0.5

0
2 3 4 5 6
Number of Classification Levels
SeaView Jajodia-Sandhu Smith-Winslett
MLR Belief-Consistent

Figure 2.6  The impact of varying the number of classification levels on the performance of a
multilevel database.

and union operation between horizontal, s­ingle-level relations in the

recovery algorithm.

2.6 Summary

This chapter introduced a survey of relational database security and

focused on the mandatory access control models. Then this chapter gave
a survey about relational multilevel database security ­management sys-
tems, explained the use of polyinstantiation in relational databases with
multilevel security, and defined how the polyinstantiation can occur
and the types of polyinstantiation. Also, this chapter ­presented the most
common models for multilevel secure RDBMS (relational ­database
management systems) and made a comparative study to explain the
strength and weakness of each model. According to this comparative
study, the MLR data model is a simple, unambiguous, and powerful
model for implementing multilevel secure RDBMS.
 3
I mplementati on of MLS/
DBMS M o d els

3.1 Introduction

The goal of multilevel security (MLS) for a relational database is to

prevent the unauthorized access of the data by preventing any user from
accessing any data to which he has no access. A lot of multilevel security
database management system (DBMS) models have been proposed to
apply the concept of multilevel security for the relational database.
This chapter will illustrate the implementation of the multilevel
security database management systems (MLS/DBMS) models. Also,
this chapter will provide the flow charts that explain the procedure of
implementing data manipulation language (DML) operations such
as SELECT, INSERT, UPDATE, and DELETE for each model of
the MLS/DBMS models.

3.2  SeaView Model

3.2.1  Selected Operation Procedure

The SQL command for the selected operation is described as follows:

SELECT [A1,A2,...,An]
FROM R
WHERE P

where R is a multilevel security relation, [A1,A2,...,An] are the

attributes of the relation R, and P is the condition of the select state-
ment that defines the tuples to be retrieved. If a user with a security
class level L executes a command to select tuples from an MLS rela-
tion R, the selection operation is implemented as follows [30]:
• Step 1: get the security class level of the user that runs the
select operation.

35
36 Securit y f o r Rel ati o n a l Data ba se s

• Step 2: make a logical view over the stored single security level
relations by performing join between vertical single security
class level relations and union between horizontal single-level
relations.
• Step 3: get all tuples from the logical view that have security
levels below or equal to the security class level of the subject
that runs the selection operation.
Figure 3.1 illustrates the flow chart for the selection operation in the
SeaView model.

3.2.2  Insert Operation Procedure

The SQL statement for the insert operation is described as follows:

INSERT
INTO R [A1,A2,...,An]
VALUES [a1,a2,...,an]

Get user class

Get logical view for stored single-level

relations by union and join operation

Get first row from logical view

No
Get next row Row class <= user class

Yes

Display Row

End

Figure 3.1  Flow chart for selection operation in the SeaView model.
 Imp l em en tati o n o f M LS / D BM S M o d el s 37

where R is an MLS relation, A1,A2,...,An are the attributes from

R, and a1,a2,...,an are values from domains of A1,A2,...,An.
If a subject with the security class level L runs a command to insert a
tuple in an MLS relation R, the insertion operation is implemented
as follows [30]:
• Step 1: get the security level of the subject that runs the insert
operation.
• Step 2: if the attribute is included in the attributes list in the
insert statement, this attribute will be set to its value from the
values list in the insert statement.
• Step 3: the security level of all attributes will be equal to the
security level of the subject that runs the insert operation.
• Step 4: insert into single-level relations, with the security level
equal to the security level of the user, values that are included
in the values list of the insert statement and that correspond
to the attributes of these single-level relations.
Figure  3.2 illustrates the flow chart for the insert operation in the
SeaView model.

Get user class L(user)

Set i = 1

Ai ∈ R [Ai]*
i=i+1
No Yes

Ai = null Ai = ai

Ci = L(user)

Execute the insert statement

End

Figure 3.2  Flow chart for insertion operation in SeaView and Jajodia–Sandhu models.
38 Securit y f o r Rel ati o n a l Data ba se s

3.2.3  Update Operation Procedure

The SQL statement for the update operation is described as follows:

UPDATE R
SET [A1 = a1, A2 = a2,...,An = an]
WHERE P

where R is an MLS relation, A1,A2,...,An are attributes from R,

a1,a2,...,an are values from domains of A1,A2,...,An, and P is
an update condition that defines the tuples needed to be updated.
If a subject with the security class level L runs a command to update
an MLS relation R, for all t ∈ R, if t satisfies P, the update operation is
implemented as follows [30]:

• Step 1: get the security level of the subject that runs the update
operation.
• Step 2: get all tuples that satisfy update condition P in the
update statement and have a security level equal to or below
the security level of the user.
• Step 3: for each tuple in the tuples in step 2, if the security
level of a primary key is equal to the security level of the user,
the tuple in the single-level relation that contains the attri-
butes in the set clause will be updated.
• Step 4: for each tuple in the tuples in step 2, if the security level
of a primary key is lower than the security level of the user, the
tuple in the single-level relation that contains the attributes in
the set clause will be polyinstantiated at the security level of the
user.
Figure 3.3 illustrates the flow chart for the update operation in the
SeaView model.

3.2.4  Delete Operation Procedure

The SQL statement for the delete operation is described as follows:

DELETE
FROM R
WHERE P
 Imp l em en tati o n o f M LS / D BM S M o d el s 39

Get user class L(user)

Set i = 1

Get t(Ai) that satisfy P

CPK = L(user)
i=i+1
Yes No

Update t(Ai) CPK = L(user)

Yes No

Polyinstantiate t(Ai)

End

Figure 3.3  Flow chart for update operation in SeaView and Jajodia–Sandhu models.

where R is an MLS relation and P is a delete condition that defines

the tuples that are to be deleted. If a subject with the security class
level L runs a command to delete tuples from MLS relation R,
for all t ∈ R, if t satisfies P, the delete operation is implemented as
­follows [30]:

• Step 1: get the security level of the subject that runs the
delete operation.
• Step 2: delete all tuples from single-level relations that satisfy
delete condition P in the delete statement and have a security
level equal to the security level of the user.
Figure  3.4 illustrates the flow chart for the delete operation in the
SeaView model.
40 Securit y f o r Rel ati o n a l Data ba se s

Get user class L(user)

Set i = 1

Get t(Ai) that satisfy P

i=i+1

No
CPK = L(user)

Yes

Delete t(Ai)

End

Figure 3.4  Flow chart for delete operation in SeaView and Jajodia–Sandhu models.

3.3  Jajodia–Sandhu Model

3.3.1  Select Operation Procedure

The SQL statement for the select operation is described as follows:

SELECT [A1,A2,...,An]
FROM R
WHERE P

where R is an MLS relation, [A1,A2,...,An] are the attributes from

R, and P is the select condition that defines tuples to be retrieved.
If a subject with the security class level L runs a command to select
tuples from an MLS relation R, the selection operation is imple-
mented as follows [31]:
• Step 1: get the security level of the subject that runs the select
operation.
• Step 2: make a logical view over the stored single-level rela-
tions that perform the union operation between horizontal
single-level relations.
 Imp l em en tati o n o f M LS / D BM S M o d el s 41

• Step 3: get all tuples, from the logical view, that have a secu-
rity level below or equal to the security level of the subject that
runs the select operation.
Figure 3.5 illustrates the flow chart for a selection operation in the
Jajodia–Sandhu model.

3.3.2  Insert Operation Procedure

The SQL statement for the insert operation is described as follows:

INSERT
INTO R [A1,A2,...,An]
VALUES [a1,a2,...,an]

where R is an MLS relation, A1,A2,...,An are the attributes from R,

and a1,a2,...,an are values from domains of A1,A2,...,An.

Get user class

Get logical view for stored single-level

relations by union operation

Get first row from logical view

No
Get next row Row class <= user class

Yes

Display Row

End

Figure 3.5  Flow chart for selection operation in Jajodia–Sandhu model.

42 Securit y f o r Rel ati o n a l Data ba se s

If a subject with the security class level L runs a command to insert

a tuple into an MLS relation R, the insertion operation is imple-
mented as follows [31]:

• Step 1: get the security level of the subject that runs the insert
operation.
• Step 2: if the attribute is included in the attribute list in the
insert statement, this attribute will be set to its value from the
values list in the insert statement.
• Step 3: the security level of all attributes will be equal to the
security level of the subject that runs the insert operation.
• Step 4: insert into the single-level relation, with the security
level equal to the security level of the user, values that are
included in the values list of the insert statement and corre-
spond to the attributes of these single-level relations.

Figure 3.2 illustrates the flow chart for the insertion operation in the
Jajodia–Sandhu model.

3.3.3  Update Operation Procedure

The SQL statement for the update operation is described as follows:

UPDATE R
SET [A1 = a1,A2 = a2,...,An = an]
WHERE P

where R is an MLS relation, A1,A2,...,An are attributes from R,

a1,a2,...,an are values from domains of A1,A2,...,An, and P is
an update condition that defines the tuples that are to be updated.
If a subject with the security class level L runs a command to update
an MLS relation R, for all t ∈ R, if t satisfies P, the update operation is
implemented as follows [31]:

• Step 1: get the security level of the subject that runs the update
operation.
• Step 2: get all tuples that satisfy update condition P in the
update statement and have security levels equal to or below
the security level of the user.
 Imp l em en tati o n o f M LS / D BM S M o d el s 43

• Step 3: for each tuple in the tuples in step 2, if the security

level of the primary key is equal to the security level of the
user, the tuple in the single level will be updated.
• Step 4: for each tuple in the tuples in step 2, if the security
level of the primary key is lower than the security level of the
user, the tuple in the single level will be polyinstantiated at
the security level of the user.
Figure 3.3 illustrates the flow chart for the update operation in the
Jajodia–Sandhu model.

3.3.4  Delete Operation Procedure

The SQL statement for the delete operation is described as follows:

DELETE
FROM R
WHERE P

where R is an MLS relation and P is a delete condition that defines

the tuples that are to be deleted.
If a subject with the security class level L runs a command to delete
tuples from an MLS relation R, for all t ∈ R, if t satisfies P, the delete
operation is implemented as follows [31]:
• Step 1: get the security level of the subject that runs the delete
operation.
• Step 2: delete all tuples that satisfy delete condition P in the
delete statement and have a security level equal to the security
level of the user.
Figure  3.4 illustrates the flow chart for the delete operation in the
Jajodia–Sandhu model.

3.4  Smith–Winslett Model

3.4.1  Select Operation Procedure

The SQL statement for the selected operation is described as follows:

SELECT [A1,A2,...,An]
FROM R
WHERE P
44 Securit y f o r Rel ati o n a l Data ba se s

Get user class L(user)

Set i = 1

Get ti that satisfy P

i=i+1

No
ti [TC]= L(user)

Yes

Display ti

End

Figure 3.6  Flow chart for select operation in Smith–Winslett and MLR models.

where R is an MLS relation, [A1,A2,...,An] are the attributes from

R, and P is the select condition that defines the tuples to be retrieved.
If a subject with the security class level L runs a command to select
tuples from an MLS relation R, the selection operation is imple-
mented as follows [32]:
• Step 1: get the security level of the subject that runs the selected
operation.
• Step 2: get all tuples that have a security level below or equal to
the security level of the subject that runs the selected operation.
Figure 3.6 illustrates the flow chart for a selection operation in the
Smith–Winslett model.

3.4.2  Insert Operation Procedure

The SQL statement for the insert operation is described as follows:

INSERT
INTO R [A1,A2,...,An]
VALUES [a1,a2,...,an]
 Imp l em en tati o n o f M LS / D BM S M o d el s 45

where R is an MLS relation, A1,A2,...,An are the attributes from R,

and a1,a2,...,an are values from domains of A1,A2,...,An. If a
subject with the security class level L runs a command to insert a
tuple into an MLS relation R, the insertion operation is implemented
as follows [32]:
• Step 1: get the security level of the subject that runs the insert
operation.
• Step 2: if the attribute is included in the attributes list in the
insert statement, this attribute will be set to its value from the
values list of the insert statement.
• Step 3: the security level of the primary key will be equal to
the security level of the subject that runs the insert operation.
• Step 4: insert the new tuple into the multilevel relation.
Figure 3.7 illustrates the flow chart for the insertion operation in the
Smith–Winslett model.

Get user class L(user)

Set i = 1

Ai ∈ R [Ai]*
i=i+1
No Yes

Ai = null Ai = ai

CPK = L(user)

Insert the row

End

Figure 3.7  Flow chart for insertion operation in Smith–Winslett model.

46 Securit y f o r Rel ati o n a l Data ba se s

3.4.3  Update Operation Procedure

The SQL statement for the update operation is described as follows:

UPDATE R
SET [A1 = a1,A2 = a2,...,An = an]
WHERE P

where R is an MLS relation, A1,A2,...,An are attributes from R,

a1,a2,...,an are values from domains of A1,A2,...,An, and P is
an update condition that defines the tuples that are to be updated.
If a subject with the security class level L runs a command to update
an MLS relation R, for all t ∈ R, if t satisfies P, the update operation is
implemented as follows [32]:
• Step 1: get the security level of the subject that runs the update
operation.
• Step 2: update all tuples that satisfy update condition P in the
update statement and have a security level equal to the secu-
rity level of the user.
Figure 3.8 illustrates the flow chart for the update operation in the
Smith–Winslett model.

3.4.4  Delete Operation Procedure

The SQL statement for the delete operation is described as follows:

DELETE
FROM R
WHERE P

where R is an MLS relation and P is a delete condition that defines

the tuples that are to be deleted.
If a subject with the security class level L runs a command to delete
tuples from MLS relation R, for all t ∈ R, if t satisfies P, the delete
operation is implemented as follows [32]:
• Step 1: get the security level of the subject that runs the delete
operation.
• Step 2: delete all tuples that satisfy delete condition P in the
delete statement and have a security level equal to the security
level of the user.
 Imp l em en tati o n o f M LS / D BM S M o d el s 47

Get user class L(user)

Set i = 1

Get ti that satisfy P

i=i+1

No
ti [TC]= L(user)

Yes

Update ti

End

Figure 3.8  Flow chart for update operation in Smith–Winslett model.

Figure  3.9 illustrates the flow chart for the delete operation in the
Smith–Winslett model.

3.5  Multilevel Relational (MLR) Model

3.5.1  Select Operation Procedure

The SQL statement for the select operation is described as follows:

SELECT [A1,A2,...,An]
FROM R
WHERE P

where R is an MLS relation, [A1,A2,...,An] are the attributes from

R, and P is the select condition that defines the tuples to be retrieved.
If a subject with the security class level L runs a command to select
48 Securit y f o r Rel ati o n a l Data ba se s

Get user class L(user)

Set i = 1

Get ti that satisfy P

i=i+1

No
ti [TC]= L(user)

Yes

Delete ti

End

Figure 3.9  Flow chart for delete operation in Smith–Winslett model.

tuples from an MLS relation R, the selection operation is implemented

as follows [33]:
• Step 1: get the security level of the subject that runs the select
operation.
• Step 2: get all tuples that have a security level below or equal
to the security level of the subject that runs the select opera-
tion and that satisfy selection condition P.
Figure 3.6 illustrates the flow chart for the selection operation in the
MLR model.

3.5.2  Insert Operation Procedure

The SQL statement for the insert operation is described as follows:

INSERT
INTO R [A1,A2,...,An]
VALUES [a1,a2,...,an]
 Imp l em en tati o n o f M LS / D BM S M o d el s 49

where R is an MLS relation, A1,A2,...,An are the attributes from

R, and a1,a2,...,an are values from domains of A1,A2,...,An.
If a subject with the security class level L runs a command to insert a
tuple into an MLS relation R, the insertion operation is implemented
as follows [33]:
• Step 1: get the security level of the subject that runs the insert
operation.
• Step 2: if the attribute is included in the attributes list in the
insert statement, this attribute will be set to its value from
the values list in the insert statement; otherwise, the value of
this attribute will be null.
• Step 3: the security level of all attributes will be equal to the
security level of the subject that runs the insert operation.
• Step 4: insert a new tuple with the attribute’s values and its
security level into the multilevel relation.
Figure 3.10 illustrates the flow chart for the insertion operation in the
MLR model.

Get user class L(user)

Set i = 1

Ai ∈ R [Ai]*
i=i+1
No Yes

Ai = null Ai = ai

Ci = L(user)

Insert the row

End

Figure 3.10  Flow chart for insertion operation in MLR and belief-consistent models.
50 Securit y f o r Rel ati o n a l Data ba se s

3.5.3  Update Operation Procedure

The SQL statement for the update operation is described as follows:

UPDATE R
SET [A1 = a1,A2 = a2,...,An = an]
WHERE P

where R is an MLS relation, A1,A2,...,An are attributes from R,

a1,a2,...,an are values from domains of A1,A2,...,An, and P is
an update condition that defines the tuples that are to be updated. If a
subject with the security class level L runs a command to update an
MLS relation R, for all t ∈ R, if t satisfies P, the update operation is
implemented as follows [33]:

• Step 1: get the security level of the subject that runs the update
operation.
• Step 2: if no attribute of the primary key is in the SET clause,
update all tuples in multilevel relations that satisfy the update
condition P in the update statement and have a security level
equal to the security level of the user. Also, all borrowed
tuples by higher level users that satisfy update condition P in
the update statement will be updated.
• Step 3: if some attribute of the primary key is in the SET
clause, update all tuples in multilevel relations that satisfy
update condition P in the update statement and have a secu-
rity level equal to the security level of the user. Delete all
borrowed tuples by higher level users that satisfy update con-
dition P in the update statement.

Figure 3.11 illustrates the flow chart for the update operation in the
MLR model.

3.5.4  Delete Operation Procedure

The SQL statement for the delete operation is described as follows:

DELETE
FROM R
WHERE P
 Imp l em en tati o n o f M LS / D BM S M o d el s 51

Get user class L(user)

Set i = 1

ti [PK] ∈ [Ai]*
No Yes

i=i+1 Update ti ti [TC] ≥ L(user)

Yes No

Update t´i

Delete ti

End

Figure 3.11  Flow chart for update operation in an MLR model.

where R is an MLS relation and P is a delete condition that defines the

tuples that are to be deleted. If a subject with the security class level L
runs a command to delete tuples from MLS relation R, for all t ∈ R,
if t satisfies P, the delete operation is implemented as follows [33]:
• Step 1: get the security level of the subject that runs the delete
operation.
• Step 2: delete all tuples from multilevel relations that satisfy
delete condition P in the delete statement and have a security
level equal to the security level of the user.
• Step 3: if there is a tuple that satisfies the delete condition P
in the delete statement and is borrowed by a high-level user,
the high-level user will be notified by exceptions or warnings
to delete this borrowed tuple.
Figure 3.12 illustrates the flow chart for the delete operation in the
MLR model.
52 Securit y f o r Rel ati o n a l Data ba se s

Get user class L(user)

Set i = 1

ti [TC] = L(user)
Yes No

i=i+1 Delete ti
ti [TC] ≻ L(user) and
ti [CPK] = L(user)

Yes No

Mark to be deleted
by high user

End

Figure 3.12  Flow chart for delete operation in an MLR model.

3.5.5  Uplevel Operation Procedure

The SQL statement for the uplevel operation is described as follows:

UPLEVEL R
GET [A1,A2,...,An] FROM [C1,C2,...,Cn]
WHERE P

where R is an MLS relation, A1,A2,...,An are the attributes from R,

C1,C2,...,Cn are the classification level of A1,A2,...,An, and P
is an uplevel condition that defines the tuples that are to be uplev-
eled. A user on the security level L issues an UPLEVEL command
to indicate that he believes the tuples in the lower level. If a subject
with the security class level L runs a command to uplevel tuples from
 Imp l em en tati o n o f M LS / D BM S M o d el s 53

MLS relation R: for all t ∈ R, if t satisfies P, the uplevel operation is

­implemented as follows [33]:
• Step 1: get the security level of the subject that runs the
uplevel operation.
• Step 2: get all tuples from the multilevel relation that satisfy
uplevel condition P in the uplevel statement and have a tuple
security level lower than or equal to the security level of the user.
• Step 3: for each tuple t′ in the tuples in step 2, a user tuple
t is constructed as follows. The primary key of tuple t and
its security level are equal to the primary key of the tuple
t′ and its class level. For each nonprimary key attribute in
the tuple t′ attribute, if the attribute is in a GET clause, the
­attribute of tuple t and its security level will be equal to this
attribute of the tuple t′ and its class level. If the attribute is
not in the GET clause, the attribute of tuple t will be null and
its security level will be equal to the security level of the user.
• Step 4: if there is a tuple with a primary key and tuple class
equal to the primary key and tuple class of the user tuple t, this
tuple will be replaced by the user tuple. If there is no tuple,
the user tuple will be inserted into the multilevel relation.
Figure 3.13 illustrates the flow chart for the uplevel operation in the
MLR model.

3.6  Belief-Consistent Multilevel Secure Relational Data Model

3.6.1  Basic Procedures for Operations

3.6.1.1 Xview (Label) Procedure  This procedure returns the visible

part of the security label for the user who executes it [34].
• Step 1: get the label as input parameter for the procedure.
• Step 2: break the label into parts.
• Step 3: get the security level of the subject that runs the procedure.
• Step 4: set the counter equal to 1.
• Step 5: while (counter ≤ user level), pack the new label with
parts that the user can see.
• Step 6: increment the counter by 1.
• Step 7: return the new label.
54 Securit y f o r Rel ati o n a l Data ba se s

Get user class L(user)

Set i = 1

ti [TC] ≤ L(user)
No Yes

i=i+1

t[PK] = ti [PK],
t[CPK] = ti [CPK]

Set j = 1

ti[Aj] ∈ [Ai]*
Yes No j=j+1

t[Aj] = ti [Ai], t[Aj] = null,

t[Cj] = ti [Cj] t[Cj] = L(user)

t[PK] = t´[PK] and

t[CPK] = t´[CPK] and
Yes t[TC] = t´[TC] No

Tuple t’ will be Tuple t will be

replaced by t inserted

End

Figure 3.13  Flow chart for uplevel operation in an MLR model.

 Imp l em en tati o n o f M LS / D BM S M o d el s 55

Figure 3.14 illustrates the flow chart for the Xview (label) procedure
in the belief-consistent model.

3.6.1.2  Pl (Label) Procedure  This procedure returns the primary level

of the security label [34]—for example, L = ucs, Pl (L) = u.
• Step 1: get the label as input parameter for the procedure.
• Step 2: break the label into parts.
• Step 3: return the first part that has a belief value equal to true.
Figure 3.15 illustrates the flow chart for the Pl (label) procedure in the
belief-consistent model.

Get the label as input

parameter for the procedure

Break label into parts

Get user class L(user)

Set i = 1

i=i+1 I ≤ L(user)
Yes No

Pack new lable with parts

that user can see

Return new label

End

Figure 3.14  Flow chart for Xview (label) procedure in a belief-consistent model.
56 Securit y f o r Rel ati o n a l Data ba se s

Get the label as input

parameter for the procedure

Break label into parts

Return the first part that has

a belief value equal to true

End

Figure 3.15  Flow chart for Pl (label) procedure in a belief-consistent model.

Get the label as input

parameter for the procedure

Break label into parts

Exclude primary level

Return the rest of the label

End

Figure 3.16  Flow chart for Sl (label) procedure in a belief-consistent model.

3.6.1.3 Sl (Label) Procedure  This procedure returns the secondary

level of the security label [34]—for example, L = ucs, Sl(L) = cs.
• Step 1: get the label as input parameter for the procedure.
• Step 2: break the label into parts.
• Step 3: exclude the primary level.
• Step 4: return the rest.
Figure 3.16 illustrates the flow chart for the Sl (label) procedure in the
belief-consistent model.
 Imp l em en tati o n o f M LS / D BM S M o d el s 57

3.6.1.4  Ib (Label) Procedure  This procedure returns the belief of a

user from the security level L about information labeled by the label
L [34]—for example, L = ucs, Ib (S, L) = s.
• Step 1: divide the security class levels into parts.
• Step 2: get the security level of the subject that runs the procedure.
• Step 3: set the counter equal to 1.
• Step 4: while (counter ≠ user – level), the return value will be
equal to mod (L, number of class levels) and L will be equal
to L/number of class levels.
• Step 5: increment the counter by 1.
• Step 6: return value.
Figure 3.17 illustrates the flow chart for the Ib (label) procedure in the
belief-consistent model.

3.6.2  Select Operation Procedure

The SQL statement for the select operation is described as follows:

SELECT [A1,A2,...,An]
FROM R
WHERE P

where R is an MLS relation, [A1,A2,...,An] are the attributes from R,

and P is the select condition that defines the tuples to be retrieved. If a
­subject with the security class level L runs a command to select tuples from
an MLS relation R, the selection operation is implemented as follows [35]:
• Step 1: get all tuples that have an Xview (tuple class) not equal
to zero and satisfy selection condition P.
• Step 2: for each attribute in the attributes of each tuple in the
tuples in step 1, get Xview (attribute class).
Figure 3.18 illustrates the flow chart for the selected operation in the
belief-consistent model.

3.6.3  Insert Operation Procedure

The SQL statement for the insert operation is described as follows:

INSERT
INTO R [A1,A2,...,An]
VALUES’ [a1,a2,...,an]
58 Securit y f o r Rel ati o n a l Data ba se s

Get the label as input

parameter for the procedure

Break label into parts

Get user class L(user)

Set i = 1

i=i+1 i ≤ L (user)

Yes No

The return value = mod (L,

number of class levels)

Label = Label/number of
class levels

Return the value

End

Figure 3.17  Flow chart for Ib (label) procedure in a belief-consistent model.

where R is an MLS relation, A1,A2,...,An are the attributes from R,

and a1,a2,...,an are values from domains of A1,A2,...,An.
If a subject with the security class level L runs a command to insert a
tuple in an MLS relation R, the insertion operation is implemented
as follows [35]:
• Step 1: get the security level of the subject that runs the select
operation.
• Step 2: if the attribute is included in the attributes list in the
insert statement, this attribute will be set to its value from
 Imp l em en tati o n o f M LS / D BM S M o d el s 59

Set i = 1

i=i+1 Xview(ti[TC]) ≠ 0

Yes No

Set j = 1

j=j+1

ti[Aj] = Xview( ti[Aj] )

End

Figure 3.18  Flow chart for select operation in the belief-consistent model.

the values list in the insert statement; else the value of this
attribute will be null.
• Step 3: the security level of all attributes will be equal to the
security level of the subject that runs the insert operation.
• Step 4: insert a new tuple with attribute values and a security
level into the multilevel relation.
Figure  3.10 illustrates the flow chart for insertion operation in the
belief-consistent model.

3.6.4  Verify Operation Procedure

The SQL statement for the verify operation is described as follows:

VERIFY (TRUE/FALSE) R
WHERE P

where R is an MLS relation and P is an update condition that defines

the tuples that are to be verified. In the belief-consistent MLS model,
users are able to define their beliefs and disbeliefs specifically through
the verify operation [35]:
• Step 1: get the security level of the subject that runs the select
operation.
60 Securit y f o r Rel ati o n a l Data ba se s

• Step 2: for each attribute in the attributes of tuple t, break its

security level into parts.
• Step 3: for each security level part in parts in step 2, if this
part of the security level is equal to the security level of the
user, it will be asserted by user beliefs.
• Step 4: pack the new attribute class level.
• Step 5: return the attribute class level.
Figure 3.19 illustrates the flow chart for the verify operation in the
belief-consistent model.

3.6.5  Update Operation Procedure

The SQL statement for the update operation is described as follows:

UPDATE R
SET [A1 = a1,A2 = a2,...,An = an]
WHERE P

where R is an MLS relation, A1,A2,...,An are attributes from  R,

a1,a2,...,an are values from domains of A1,A2,...,An, and
P is an update condition that defines the tuples that are to be
updated. If a subject with the security class level L runs a command
to update an MLS relation R for all t ∈ R, the update operation is
implemented as f­ ollows [35]:
• Step 1: get the security class level of the subject that runs the
update operation.
• Step 2: if Pl (t [tuple class]) is equal to the security class level
of the subject L, tuple t will be updated.
• Step 3: if Pl (t [tuple class]) is lower than the security level of
the user, ib(security level of user, t [tuple class]) = ­security level
of the user. A new tuple t′ based on tuple t will be inserted on
the level equal to the security level of the user. The attribute
values of tuple t will not be changed.
• Step 4: if Pl (t [tuple class]) is lower than the security level of
the user, Ib (security level of user, t [tuple class]) = 0. If existing
tuples ti from R have ti [primary key] = t[primary key] and Pl
(ti [primary key]) = Pl(t[primary key]) and Pl (ti [tuple class])
< the security level of the user, the user will choose a tuple,
t′, and a new tuple, t″, based on t′ will be inserted on the user
 Imp l em en tati o n o f M LS / D BM S M o d el s 61

Get user class L(user)

Set i = 1

L(user) ≥ Pl(ti [TC])

No Yes

i=i+1 Set j = 1

Break ti [Ai] into parts

Set K = 1

j=j+1
Ck = L(user)
No Yes

K=K+1 Ck will be asserted by

user beliefs

Create new class level

for ti[Aj]

Verify t for the user

End

Figure 3.19  Flow chart for verify operation in the belief-consistent model.

level, while the attribute values of t′ itself will not change. If no

tuples ti from R that have ti [primary key] = t[primary key] and
Pl (ti [primary key]) = Pl(t[primary key]) and Pl (ti [tuple class])
< the security level of the user exist, a new tuple, t″, based on
tuple t will be inserted on a level equal to the security level of the
user, while the attribute values of tuple t will not be changed.

Figure 3.20 illustrates the flow chart for the update operation in the
belief-consistent model.
62 Securit y f o r Rel ati o n a l Data ba se s

Get user class L(user)

Set i = 1

Pl(ti [TC]) = L(user)

Yes No

i=i+1 Pl(ti [TC]) < L(user) and

lb(C(user), ti [TC]) = L(user)
No Yes
ti will be updated

Set j = 1

j=j+1

tj[PK] = ti[PK] and

No
Pl(tj[PK]) = Pl(ti[PK]) and
Pl(ti [TC]) < L(user)
Yes

Insert tj in Array[tj]

Count (Array[tj]) = 0
Yes No
Choose tj

Insert t' based ti

End

Figure 3.20  Flow chart for update operation in the belief-consistent model.

3.6.6  Delete Operation Procedure

The SQL statement for the delete operation is described as follows:

DELETE
FROM R
WHERE P
where R is an MLS relation and P is a delete condition that defines
the tuples that are to be deleted. If a subject with the security class
 Imp l em en tati o n o f M LS / D BM S M o d el s 63

level L runs a command to delete tuples from MLS relation R: for all
t ∈ R, if t satisfies P and Pl is equal to the security class level of the
user L, the delete operation is implemented as follows [35]:
• Step 1: get the security level of the subject that runs the delete
operation.
• Step 2: if Sl (Xview(Tuple Class)) is NULL, the tuple will be
deleted.
• Step 3: if Sl (Xview(Tuple Class)) is not NULL, unverify the
tuple for the current user and set the flag for higher level users.
• Step 4: unverify all tuples with the same primary key and its
security level as the deleted tuple having Ib(tc) = l (belief: false).
Figure 3.21 illustrates the flow chart for the delete operation in the
belief-consistent model.

Get user class L(user)

Set i = 1

Pl(ti [TC]) = L(user) and

Sl(Xview(ti [TC])) = Null
Yes No

Unverify ti for current user

Detele ti

Set flag for higher level users

Set j = 1

i=i+1 j=j+l

tj [PK, CPK] = ti [PK, CPK] and No

Ib(tj [TC]) = 1

Yes

Unverify tj for current user

End

Figure 3.21  Flow chart for delete operation in the belief-consistent model.
64 Securit y f o r Rel ati o n a l Data ba se s

Table 3.1  Comparative Study for Multilevel Database Models

RESTRICTION
OF THE
PROBLEM PROLIFERATION SEMANTIC SCOPE OF AN DISBELIEF
MODEL PROBLEM AMBIGUITY UPDATE IN A TUPLE SIMPLICITY
SeaView Not solved Not solved Solved Not solved Very simple
Jajodia–Sandhu Solved Not solved Solved Not solved Simple
Smith–Winslett Solved Solved Not solved Not solved Simple
MLR Solved Solved Solved Not solved Complex
BCMLS Solved Solved Solved Solved Very Complex

3.7  Comparative Study for Multilevel Database Models

Table 3.1 illustrates the strengths and weaknesses of each model of

the multilevel security database models.

3.8 Summary

Many multilevel relational models have been proposed; different

models offer different advantages. In this chapter, we explained the
implementation of DML operations such as SELECT, INSERT,
UPDATE, and DELETE for each model of the multilevel secure
database models. From the implementation procedures we found that
MLR is secure, unambiguous, and powerful because it provides mul-
tilevel relations with element-level labeling as a natural extension of
the traditional relational data model. MLR introduces several new
concepts (notably, data-borrow integrity and the UPLEVEL state-
ment) and significantly redefines existing concepts (polyinstantiation
and referential integrity as well as data manipulation operations).
 4
Fundamentals of
I nformati on E n cryp ti on

4.1 Introduction

Nowadays, information has a good value in our world, so information

should be secured. Computer networks made a revolution in informa-
tion usage possible. An authorized user can exchange the information
from a distance using computer networks. To secure the information,
we need to be able to hide it from unauthorized access, which is called
confidentiality; protect it from unauthorized modification, which is
called integrity; and make it available to an authorized entity, which
is called availability [36].
This chapter gives the main basics of the design of cryptographic
algorithms. A review of the various issues found when selecting,
designing, and measuring a cryptographic algorithm is presented.
Diffusion-based cipher algorithms, along with their modes of opera-
tion, are covered in this chapter. Chaotic encryption with a Baker
map is also discussed.

4.2  Basic Concepts of Cryptography

4.2.1  Goals of Cryptography

Cryptography should accomplish the following four goals [37,38]:

• Confidentiality
• Data integrity
• Authentication
• Nonrepudiation

65
66 Securit y f o r Rel ati o n a l Data ba se s

Confidentiality protects the information from unauthorized

access. An unauthorized party is called an adversary, which
should not have the ability to access the network.
Data integrity ensures that the information has not been modi-
fied in an unauthorized way. If the data are modified, all par-
ties through the network can detect this modification.
Authentication methods are classified into two categories: entity
authentication and message authentication. Entity authenti-
cation is the process that one party uses to ensure the identity
of the second party in the communication protocol. Message
authentication is the term used with data origin authentica-
tion. It provides that the data received is the original message
source.
Nonrepudiation means that the receiver can prove that he
receives the original information as the sender sends it.
Knowing the techniques that are used to break an existing cryp-
tography is called cryptanalysis. Because the cryptography depends
on the cryptanalysis, users refer to cryptology as a joint study of
­cryptography and cryptanalysis.

4.2.2  Principles of Encryption

The basic idea of encryption is to modify the message in such a way that
only a legal recipient can reconstruct its content [37,38]. A ­discrete-valued
cryptosystem can be characterized by:

• A set of possible plaintexts, P

• A set of possible ciphertexts, C
• A set of possible cipher keys, K
• A set of possible encryption and decryption transformations,
E and D

An encryption system is also called a cipher, or a cryptosystem.

The message for encryption is called plaintext, and the encrypted
message is called ciphertext. Denote the plaintext and the ciphertext
by P and C, respectively. The encryption procedure of a cipher can
be described as
C = E K e ( P ) (4.1)
 F un da m en ta l s o f In f o rm ati o n En c ry p ti o n 67

Ke Kd

Plaintext Ciphertext Recovered

Encryption Decryption
Public channel

Figure 4.1  General encryption and decryption of a cipher.

where Ke is the encryption key and E is the encryption function.

Similarly, the decryption procedure is defined as

P = DK d (C ) (4.2)

where Kd is the decryption key and D is the decryption function.

The security of a cipher should only rely on the decryption key, Kd ,
since an adversary can recover the plaintext from the observed cipher-
text once he gets Kd . Figure 4.1 shows a block diagram for encryp-
tion/decryption of a cipher.

4.3  Classification of Encryption Algorithms

Encryption algorithms are classified in various ways: according to

their structures of the algorithms, according to keys, or according to
their percentage of encrypted data [39,40].

4.3.1  Classification according to Encryption Structure

Encryption algorithms are classified as block ciphers and stream

ciphers.
A block cipher is a kind of symmetric-key encryption algorithm that
converts a fixed-length block of plaintext data to a block of ciphertext
data of the same length. The fixed length is called the block size.
For several block ciphers, the block size is 64 or 128 bits. The larger
the block size is, the more secure is the cipher, but the more complex
are the encryption and decryption algorithms and devices. Modern
block ciphers have the following features [41]:

1. Variable key size

2. Mixed arithmetic operations, which can provide nonlinearity
3. Data-dependent rotations and key-dependent rotations
68 Securit y f o r Rel ati o n a l Data ba se s

4. Lengthy key schedule algorithm

5. Variable plaintext/ciphertext block sizes and variable numbers
of rounds
Block ciphers can be characterized by:
1. Block size: The greater security is, the larger are the block sizes.
2. Key size: Larger key sizes mean greater security.
3. Number of rounds: Multiple rounds increase security.
4. Encryption modes: These define how messages larger than
the block size are encrypted.
Unlike block ciphers that operate on large blocks of data, stream
ciphers typically operate on smaller units of plaintext, usually bits.
So, stream ciphers can be designed to be exceptionally fast—much
faster than a typical block cipher. Generally, a stream cipher gener-
ates a sequence of bits as a key (called key stream) using a pseudo
­random number generator (PRNG) that expands a short secret key
(e.g., 128  bits) into a long string (key stream; e.g., 10 6 bits), and
the encryption is accomplished by combining the key stream with
the  plaintext. Usually, the bitwise XOR operation is chosen to
­perform ciphering, basically for its simplicity [42,43]. Stream ciphers
have the following properties [44]:
1. They do not have perfect security.
2. Security depends on the properties of the PRNG.
3. The PRNG must be unpredictable; given a consecutive
sequence of output bits, the next bit must be hard to predict.
4. Typical stream ciphers are very fast.

4.3.2  Classification according to Keys

According to keys, there are two kinds of ciphers following the

­relationship of Ke and Kd. When Ke = Kd , the cipher is called a
private-key cipher or a symmetric cipher. For private-key ciphers, the
encryption/decryption key must be transmitted from the sender to
the receiver via a separate secret channel. When Ke ≠ Kd , the cipher
is called a public-key cipher or an asymmetric cipher. For public-
key ciphers, the encryption key, Ke, is published and the decryption
key, Kd, is kept private, and no additional secret channel is needed
 F un da m en ta l s o f In f o rm ati o n En c ry p ti o n 69

for key transfer. In conventional encryption, as shown in Figure 4.2,

the sender encrypts the data (plaintext) using the encryption key and
the receiver decrypts the encrypted data (ciphertext) into the origi-
nal data (plaintext) using the decryption key. In symmetric encryp-
tion, encryption and decryption keys are identical. Figure 4.3 shows
the public key encryption (asymmetric encryption) in which the
encryption and decryption keys are different. Public key cryptogra-
phy solves the problem of conventional cryptosystems by distributing
the key  [45,46]. Table  4.1 shows a comparison between symmetric
encryption and asymmetric encryption.
There are two types of cryptosystems:
• Symmetric (private) key cryptosystems
• Asymmetric (public) key cryptosystems

Sender Transmission Receiver

Xe Kd
Message Message
Source destination
Cryptanalyst
X (Attacks) X
Encryption Decryption
Algorithm Y Y Algorithm

K
K
Secret Secure
Key Channel

Figure 4.2  Model of symmetric encryption.

Cryptanalyst X

The source A The destination B

Message X Y X
Encrypt Decrypt Destination
source

Kd
Ke

Key pair
source

Figure 4.3  Asymmetric-key encryption.

70 Securit y f o r Rel ati o n a l Data ba se s

Table 4.1  Comparison between Symmetric Encryption and Asymmetric Encryption

CONVENTIONAL ENCRYPTION (SYMMETRIC PUBLIC-KEY ENCRYPTION (ASYMMETRIC
ENCRYPTION) ENCRYPTION)
Requirements to work: Requirements to work:
• Use the same algorithm with the same • One encryption and decryption algorithm is
key for the encryption and the used for encryption and decryption and two
decryption process. keys, one for encryption and one for decryption.
• The algorithm and the key should be • The sender and receiver should have one of
shared by the sender and receiver. the two keys.
Requirements for security: Requirements for security:
• The key should be secret. • The key should be secret.
• It must be impossible to decrypt the • It must be impossible to decrypt the message
message if no information is available. if no information is available.
• Discovering the algorithm and • Discovering the algorithm and samples of the
samples of the ciphertext should be ciphertext should be insufficient to determine
insufficient to determine the key. the key.

Most people have chosen to call the first group simply symmetric
key cryptosystems, and the popular name for the second group is just
­public key cryptosystems.

4.3.3  Classification according to Percentage of Encrypted Data

The encryption algorithm can be divided into full encryption and

partial encryption according to the percentage of the data encrypted.

4.4 Cryptanalysis

Cryptanalysis is the art of decrypting an encrypted message without

knowing the decryption key [47–50]. Some of the most important
ones, for a system implementer, are described next, and they are sum-
marized in Table 4.2:
In a ciphertext-only attack, the adversary has access only to some
encrypted messages.
A brute-force attack is a kind of ciphertext-only attack. It is based
on a key search and well-designed cryptosystems should be
computationally infeasible to attack.
In a known-plaintext attack, an adversary has some information
about the plaintext and the corresponding given ciphertext.
This may be helpful to determine the decryption key.
 F un da m en ta l s o f In f o rm ati o n En c ry p ti o n 71

Table 4.2  Types of Attacks on Encrypted Information

TYPE OF ATTACK PREREQUISITES FOR THE CRYPTANALYST
Ciphertext only • The algorithm of encryption
• Ciphertext to be decrypted
Known plaintext • The algorithm of encryption
• Ciphertext to be decrypted
• Plaintext message and ciphertext generated
with the secret key
Chosen ciphertext • The algorithm of encryption
• Ciphertext to be decrypted
• Ciphertext chosen by the cryptanalyst with
its plaintext generated with the decryption
algorithm and the decryption key
Chosen plaintext • Encryption algorithm
• Ciphertext to be decoded
• Plaintext chosen by the cryptanalyst with
its ciphertext generated with the encryption
algorithm and the encryption key

4.5  Conventional Symmetric Block Ciphers

This section gives a brief overview of the construction of some popular

conventional encryption algorithms. Each of the following encryption
algorithms is a symmetric block cipher algorithm. Symmetric means
that the key used for encryption and decryption is the same, while
block means that the data (information) to be encrypted is divided
into blocks of equal length [51,52].

4.5.1  Data Encryption Standard (DES)

The DES is the most well-known symmetric key block cipher and it
has enjoyed widespread use internationally [53].
The DES is a block cipher, which encrypts data in 64-bit blocks.
A 64-bit block of the plaintext comes at one end of the algorithm and
a 64-bit block of ciphertext goes out at the other end of the ­algorithm.
The same algorithm and the same key with 56 bits are used in the
encryption and decryption processes except for minor differences in
the key schedule. The key is a 64-bit number. In every 8 bits, 1 bit
(the least significant bit) is used for parity checking and can be ignored.
The DES is based on four basic operations: expansion, permutation,
XOR, and substitution. The data to be encrypted are first divided into
72 Securit y f o r Rel ati o n a l Data ba se s

32 1 2 3 4 5 6 7 8 9 10 11 12 32

48 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 48

Figure 4.4  Expansion process.

64-bit blocks and fed into an initial permutation (IP) stage, in which
each block is divided into two sub-blocks, each with 32-bit length.
The right sub-block is fed into a Feistel function (f-function), which
is depicted in Figure 4.4. It operates on half a block (32 bits) at a time
and contains four stages as shown in Figure 4.5.
1. Expansion. The half-block with 32 bits is expanded to 48 bits,
using the permutation of the expansion, defined as E in the
diagram, by duplicating half of the bits. The output contains
eight 6-bit [8 × 6 = 48 bits] pieces, each consisting of a copy of
four corresponding input bits and a copy of the immediately
adjacent bit from each of the input pieces to either side.
2. Key mixing. A subkey is combined with the result of the first
step using an XOR operation. A key schedule mechanism is
used to derive 16 subkeys with 48 bits from the main key.
3. Substitution. First the block is divided into eight 6-bit pieces
and, after that, processed by the substitution boxes (S-boxes).
The six input bits of each one of the eight S-boxes are replaced
with four output bits using a nonlinear transformation, pro-
vided in the form of a look-up table. The S-boxes present the
basis of the security of the DES. Without them, the cipher
would be breakable.
4. Permutation. The 32 S-boxes’ outputs will be rearranged using
a fixed permutation. The P-box is designed so that, after expan-
sion, each group of S-box output bits is spread across six differ-
ent S-boxes in the next round.

4.5.2  Double DES

The way to improve security of the block cipher algorithm is to encrypt

every block twice using two different keys. The first step is to encrypt
 F un da m en ta l s o f In f o rm ati o n En c ry p ti o n 73

Plaintext 64 bits
IP

F
For 16 rounds

FP
Ciphertext 64 bits

Half block (32 bits) Sub-key (48 bits) f-function.

S S S S S S S S

Figure 4.5  The DES algorithm and f-function.

a block using the first encryption key and then encrypt the resulting
ciphertext with the second encryption key. The decryption is a process
conducted in reverse.
The resulting ciphertext block should be very difficult to be
decrypted. Instead of 256 attempts, it requires 2128 attempts to find the
key and 2112 attempts to break the encryption. In 1981, Merkle and
Hellman declared the “meet-in-the-middle attack,” which proved the
74 Securit y f o r Rel ati o n a l Data ba se s

weakness of the double DES algorithm [54]. The meet-in-the-middle

attack requires that the attacker have both a known piece of plain-
text and its corresponding ciphertext. The attack needs to store 256
results when trying to discover a datum that has been encrypted with
the double DES. Merkle and Hellman presented a time–­memory
trade-off, which could break this double-encryption scheme in 256+1
­encryptions, rather than 2112 encryptions.

4.5.3  Triple DES

The dangers of the Merkle–Hellman attack (meet-in-the-middle

attack) can be overcome by conducting three block encryption opera-
tions. This method is called triple DES and is performed by execut-
ing the DES three times, producing an effective key size of 168 bits.
In the triple DES, each 64-bit block of data is encrypted three times
with the DES algorithm.
The triple DES is performed as follows:
1. Use key 1 for encryption.
2. Use key 2 for decryption.
3. Use key 3 for encryption.
To decrypt, reverse the steps:
1. Use key 3 for decryption.
2. Use key 2 for encryption.
3. Use key 1 for decryption.
For several applications, both keys 1 and 3 can be the same without
creating a significant vulnerability. The choice among single, ­double,
and triple DES is a trade-off between performance and security
requirements [55].

4.5.4  International Data Encryption Algorithm (IDEA)

The IDEA cipher was first presented by Lai and Massey in 1990 under
the name of proposed encryption standard (PES). After Biham and
Shamir presented differential cryptanalysis, the authors named it the
improved proposed encryption standard (IPES). The IPES name was
changed to international data encryption algorithm (IDEA) in 1992.
 F un da m en ta l s o f In f o rm ati o n En c ry p ti o n 75

The algorithm was intended as a replacement of the DES. IDEA is

a block cipher that depends on 64-bit plaintext blocks. The  key is
128 bits long. There are eight identical rounds, and the encryption
and decryption algorithms are the same. The design behind the algo-
rithm is based on mixing operations from different algebraic groups.
Three algebraic groups—XOR, addition modulo, and multiplication
modulo—are mixed in this algorithm [56,57]. All of these operations
operate on 16-bit sub-blocks.

4.5.5 Blowfish

The blowfish algorithm is a 64-bit block cipher using a variable-

length key. It was designed in 1993 by Schaneier [58]. The ­algorithm
contains two parts: key expansion and data encryption. Key expansion
divides a key of 448 bits into different subkey arrays of 4168 bytes. Data
encryption contains a function iterated for 16 rounds. Each round
contains a key-dependent permutation and a key- and data-dependent
substitution. All operations are additions and XORs on 32-bit words.
The additional operations are four indexed array data lookups per
round. The keys should be computed before any data encryption or
decryption process.

4.5.6  RC5 Algorithm

The iterated block RC5 was introduced by Rivest, Shamir, and Adleman
in 1994 [58]. The main feature of the RC5 is the heavy use of data-
dependent rotations. RC5 has a variable word size, w, a variable ­number
of rounds, r, and a variable secret key with b bytes. It is represented as
RC5 w/r/b. The nominal value of w is 32 bits, and RC5 encrypts blocks
of two words. The RC5 is composed of encryption, decryption, and key
expansion. The expanded key contains t = 2 × (r + 1) words. The primi-
tive operations of the RC5 are illustrated in Table 4.3. Generally, RC5
is a fast symmetric block cipher that is suitable for hardware and soft-
ware implementations with low memory requirements. It provides high
security when good parameters are chosen.

4.5.6.1  RC5 Encryption Algorithm  We assume that the input block is

given in two w-bit registers, A and B, and we also assume that key
76 Securit y f o r Rel ati o n a l Data ba se s

Table 4.3  Primitive Operations of RC5

a+b Integer addition modulo 2w
a–b Integer subtraction modulo 2w
a⊕b Bitwise XOR of w-bit words
a*b Integer multiplication modulo 2w
a <<< b Rotate the w-bit word a to the left by the amount
given by the least significant lg w bits of b
a >>> b Rotate the w-bit word a to the right by the amount
given by the least significant lg w bits of b

Ai–1 Bi–1

<<< <<<

+ S2i
+ S2i+1

Ai Bi

Figure 4.6  RC5w/r/b symmetric block cipher diagram.

expansion has already been performed so that S[0], S[1], …, S[t – 1]

have been computed. The steps of the encryption algorithm can be
summarized as follows:
A = A+S [0];
B = B+S [1];
For i = 1 to r do
A = ((A ⊕ B) <<< B) +S [2i];
B = ((B ⊕ A) <<< A) +S [2i+1];
End

In each round of RC5, both registers A and B are updated as shown

in Figure 4.6.

4.5.6.2  RC5 Decryption Algorithm  The decryption step can be sum-

marized as follows:
For i = r downto 1 do
B = ((B - S [2i+1]) >>> A) ⊕ A;
A = ((A - S [2]) >>> B) ⊕ B;
 F un da m en ta l s o f In f o rm ati o n En c ry p ti o n 77

End
B = B-S [1];
A = A-S [0];

4.5.6.3  RC5 Key Expansion  Key expansion expands the user’s secret
key, K, to fill the expanded key array S, which makes S similar to an
array of t = 2(r + 1) random binary words. Two magic constants, Pw
and Qw, are used in this process. These constants are defined as

( )
Pw = Odd ( e − 2 ) 2w (4.3)

( )
Qw = Odd ( φ − 1) 2w (4.4)

where
e = 2.718281828459....(base of natural logarithms)
ϕ = 1.618033988749....(golden ratio)
and Odd(x) is the odd integer nearest to x
For w = 16 and 32, these constants are given in hexadecimals:
P 16 = b7e1; Q16 = 9e37

P 32 = b7e15163; Q 32 = 9e3779b9

The expansion begins by copying the secret key K[0…b – 1] into an

array L[0…c – 1] that has c = ⎡b/u⎤ words, where u = w/8 is the num-
ber of bytes per word. u consecutive key bytes of K are used to fill up
each successive word in L in a low-order to high-order byte manner.
All unfilled byte positions of L are zeroed.
To initialize the array S, we follow these steps:

S [0] = Pw;
For i = 1 to t-1 do
S [i] = S [i-1] + Qw;
End

The last step is to mix the user secret key in three passes over the
arrays S and L as follows:

i = j = 0;
A = B = 0;
Do 3*max (t, c) times:
78 Securit y f o r Rel ati o n a l Data ba se s

A = S [i] = (S [i] +A+B) <<<3;

B = L[j] = (L[j] + A+ B) <<< (A+B);
i = (i+1) mod (t);
j = (j+1) mod (c);

4.5.7  RC6 Algorithm

The RC6 block cipher is a modified version of RC5, which uses four
working registers instead of two, as well as integer multiplication as an
additional primitive operation. The integer multiplication process greatly
enhances the diffusion achieved per round, which leads to greater secu-
rity, fewer rounds, and increased throughput. The key schedule of RC6-
w/r/b is similar to the key schedule of RC5-w/r/b. The only difference
is that for RC6-w/r/b, more words are derived from the user-supplied
key for use during encryption and decryption. The user supplies a key
of b bytes, where 0 ≤ b ≤ 255. From this key, 2r + 4 words (w bits each)
are derived and stored in the array S[0, …, 2r + 3]. This array is used in
both encryption and decryption [59]. Generally, RC6 consists of two
Feistel networks whose data are mixed via data-dependent rotations.
The operations in a single round of RC6 contain two applications of the
squaring function f (x) = x (2x + 1) mod 232, two fixed 32-bit rotations,
two data-dependent 32-bit rotations, two XORs, and two additions
modulo 232. The steps of RC6 encryption and decryption are summa-
rized next and the block diagrams or RC6 encryption and decryption
are shown in Figures 4.7 and 4.8, respectively.

4.5.7.1  RC6 Encryption Algorithm  Input: Four w-bit plaintext values

are stored in registers A, B, C, and D.
Number r of rounds
w-bit round keys S[0…, 2r + 3]
Output: Four w-bit ciphertext values are stored in registers A, B,
C, and D.
Procedure:

B = B + S [0];
D = D + S [1];
For i = 1 to r do
{t = (B × (2B + 1)) <<< lg w;
u = (D × (2D + 1)) <<< lg w;
 F un da m en ta l s o f In f o rm ati o n En c ry p ti o n 79

A B C D

+ S[0] + S[1]

<<< f <<< f

lg w lg w
<<<

<<<

Repeat for r rounds

+ S[2i] + S[2i+1]

+ S[2r+2] + S[2r+3]

A B C D

Figure 4.7  Encryption with RC6w/r/b algorithm.

A = ((A ⊕ t) <<< u) + S [2i];

C = ((C ⊕ u) <<< t) + S [2i + 1];
(A, B, C, D) = (B, C, D, A);}
End
A = A + S [2r + 2];
C = C + S [2r + 3];

4.5.7.2  RC6 Decryption Algorithm  Input: Four w-bit ciphertext values

are stored in registers A, B, C, and D.
Number of rounds r
w-bit round keys S[0, …, 2r + 3]
80 Securit y f o r Rel ati o n a l Data ba se s

A B C D

– S[2r+2] – S[2r+3]

– S[2i] – S[2i+1]

Repeat for r rounds

>>>

>>>

<<< f <<< f

lg w lg w

– S[0] – S[1]

A B C D

Figure 4.8  Decryption with RC6w/r/b .

Output: Four w-bit plaintext values are stored in registers A, B,

C, and D.
Procedure:

C = C − S [2r + 3];
A = A − S [2r + 2];
for i = r downto 1 do
{(A, B, C, D) = (D, A, B, C);
u = (D × (2D + 1)) <<< lg w;
t = (B × (2B + 1)) <<< lg w;
C = ((C − S[2i + 1]) >>> t) ⊕ u;
A = ((A − S[2i]) >>> u) ⊕ t;}
End
D = D − S [1];
B = B − S [0];
 F un da m en ta l s o f In f o rm ati o n En c ry p ti o n 81

4.5.8  The Advanced Encryption Standard (AES)

The AES is based on the Rijndael algorithm, which is an iterated

block cipher algorithm with a variable block size and a variable key
size. The block size and the key size can be independently 128, 192, or
256 bits. The intermediate resulting ciphertext is called a state and it
is in the form of a rectangular array of four rows and a number of col-
umns equal to the block size divided by 32. The cipher key is similarly
a rectangular array with four rows and a number of columns equal to
the key size divided by 32. The number of rounds performed on the
intermediate state is related to the key size. For key sizes of 128, 192,
and 256 bits, the number of rounds is 10, 12, and 14, respectively.
Each round consists of a fixed sequence of transformations, except the
first and the last round [36,37].
The AES consists of rounds. Any round, except the final one, con-
sists of subBytes, ShiftRows, MixColumns, and AddRoundKey oper-
ations. In the final round, no MixColumns operation is performed.
In the subBytes step, a linear substitution for each byte is performed
according to Figure 4.9. Each byte in the array is updated using an
8-bit S-box, which provides the nonlinearity in the cipher system.
The S-box is derived from the multiplicative inverse over the finite
Galois field GF(28), known to have good nonlinearity properties.
To  avoid attacks based on simple algebraic properties, the S-box is
chosen to avoid any fixed points and also any opposite fixed points [37].
The ShiftRows is based on the rows of the state. It shifts the bytes
in each row. For the AES, the first row is left unchanged. Each
byte of the second row is shifted a single byte to the left. The third

b1 b2 b3 b4 d1 d2 d3 d4

b5 b6 b7 b8 SubBytes d5 d6 d7 d8

b9 b10 b11 b12 d9 d10 d11 d12

b13 b14 b15 b16 d13 d14 d15 d16

Figure 4.9  SubBytes step.

82 Securit y f o r Rel ati o n a l Data ba se s

and the  fourth rows are shifted by offsets of two and three bytes,
respectively. For the block of size 128 bits and 192 bits, the shifting
pattern is the same [40].
In the case of the 256-bit blocks, the first row is unchanged and
the shifting for second, third, and fourth rows is 1 byte, 3 bytes, and
4 bytes, respectively, as shown in Figure 4.10.
In the MixColumns step, the four bytes of each column of the
state are combined using an invertible linear transformation. The
MixColumns function takes four bytes as input and outputs four
bytes, where each input byte affects all the four output bytes. With
ShiftRows, MixColumns provides diffusion in the cipher system.
Each column is treated as a polynomial over GF(28) and is then multi-
plied with a fixed polynomial c(x) = 3x3 + x2 + x + 2. The MixColumns
step can also be viewed as a multiplication by a particular matrix, as
shown in Figure 4.11 [36,37].
In the AddRoundKey step, the subkey is combined with the state.
For each round, a subkey is derived from the main key using the
algorithm key schedule. Each subkey has the same size as the state.

b1 b2 b3 b4 b1 b2 b3 b4

b5 b6 b7 b8 ShiftRows b6 b7 b8 b5

b9 b10 b11 b12 b10 b11 b12 b9

b13 b14 b15 b16 b14 b15 b16 b13

Figure 4.10  ShiftRows step.

b1 b2 b3 b4 d1 d2 d3 d4

b5 b6 b7 b8 MixColumns d5 d6 d7 d8

b9 b10 b11 b12 d9 d10 d11 d12

b13 b14 b15 b16 d13 d14 d15 d16

C(x)

Figure 4.11  MixColumns step.

 F un da m en ta l s o f In f o rm ati o n En c ry p ti o n 83

b1 b2 b3 b4 d1 d2 d3 d4

b5 b6 b7 b8 AddRoundKey d5 d6 d7 d8

b9 b10 b11 b12 d9 d10 d11 d12

b13 b14 b15 b16 d13 d14 d15 d16

C(x)

k1 k2 k3 k4

k5 k6 k7 k8

k9 k10 k11 k12

k13 k14 k15 k16

Figure 4.12  AddRoundKey step.

The subkey is added by combining each byte of the state with the
corresponding byte of the subkey using a bitwise XOR [36,37].
The AddRoundKey step is shown in Figure 4.12. We will apply the
AES with a fixed block size of 128 bits and a key size of 128 bits.

4.6  Modes of Operation

Block ciphers can be run in different modes of operation, allowing users

to choose appropriate modes to meet the requirements of their appli-
cations. Using a certain mode in the encryption process restricts the
decryption process to using the same mode. In this section, we discuss
different possible ways in which block codes can be utilized to imple-
ment a cryptosystem. The possible block cipher modes of operation that
we treat are identified by the acronyms ECB, CBC, CFB, and OFB.
In each case, we assume that we have a block cipher of block length n,
with enciphering map, EK, and deciphering map, DK, for each key K.

4.6.1  The ECB Mode

ECB is the simplest mode of operation for encryption algorithms

where the data sequence is divided into blocks of equal sizes and
84 Securit y f o r Rel ati o n a l Data ba se s

Plaintext Plaintext Plaintext

Key Encryption Algorithm Key Encryption Algorithm Key Encryption Algorithm

Ciphertex Ciphertex Ciphertex

t t t

Figure 4.13  Using a block cipher in the ECB mode.

each block is encrypted, separately, with the same encryption key.

As ­illustrated in Figure  4.13, the plaintext is divided into blocks
(P 1, P 2, P 3,… .) of size n bits, which are encrypted to ciphertext blocks
(C1, C2, C3,… .). The encryption algorithm is

Cj = EK (Pj ) (4.5)

and the decryption algorithm is

Pj = DK (C j ) (4.6)

where j = 1, 2, 3, …, EK is the encryption map with the key K, and DK

is the decryption map with the same key K.
The ECB mode has several advantages. There is no need to encrypt
a file progressively; the middle blocks can be encrypted first, then
the blocks at the end, and finally the blocks at the beginning. This is
important for encrypted files that are accessed randomly, like a data-
base. If a database is encrypted in the ECB mode, then any record can
be added, deleted, encrypted, or decrypted independently, assuming
that a record consists of independent encryption blocks.
The disadvantage of this mode is that identical plaintext blocks
are encrypted to identical ciphertext blocks; it does not hide data
patterns. The advantage is that error propagation is limited to a
single block. The disadvantage of ECB mode appears well in image
encryption if we have an image with large areas of the same color or
repeated patterns so that there are many blocks of the same plaintext.
This may reveal much information about the original image from the
encrypted image. This disadvantage is treated in CBC, CFB, and
OFB modes. So, all with those kinds of images are better than the
ECB mode.
 F un da m en ta l s o f In f o rm ati o n En c ry p ti o n 85

4.6.2  The CBC Mode

The CBC mode uses an IV of size equal to the size of each block of
pixels. In this mode, each block of plaintext is XORed with the previ-
ous ciphertext block before being encrypted. This way, each ciphertext
block is dependent on all plaintext blocks up to that point. In decryp-
tion, the same XOR operation is repeated so that its effect is cancelled.
This mechanism is shown in Figure 4.14.
The main disadvantage of the CBC mode is that an error in (or attack
upon) one ciphertext block impacts two plaintext blocks upon decryp-
tion. On the other hand, if we have an image that has blocks of the
same input data, these blocks are encrypted to totally different cipher-
text data. So, the CBC mode is a better approach in encrypting images
in the spatial domain, especially when these images contain large areas
of the same activity. In the CBC mode, the encryption algorithm is
Cj = EK (Cj−1 ⊕ Pj) (4.7)
and the decryption algorithm is
Pj = DK (Cj ) ⊕ Cj−1, j = 1, 2, 3, … (4.8)

C 0 = IV (4.9)

4.6.3  The CFB Mode

In contrast to the CBC mode, the CFB mode begins by encrypt-

ing the IV, and then an XOR operation is performed between the

P1 P2 P3

C0 = IV

Key EK Key EK Key EK

C1 C2 C3

Figure 4.14  Using a block cipher in the CBC mode.

86 Securit y f o r Rel ati o n a l Data ba se s

C0 = IV EK I1 EK I2 EK I3

P1 P2 P3

C1 C2 C3

Figure 4.15  Using a block cipher in the CFB mode.

bits of the encrypted IV and the corresponding bits of the first block
of the image. The result is the encrypted version of the first block.
For the encryption of each of the next plaintext blocks, the previous
ciphertext block is encrypted and the output is XORed with the cur-
rent plaintext block to create the current ciphertext block. The XOR
operation conceals plaintext patterns.
Common to the CBC mode, changing the IV to the same plaintext
block results in different outputs. Though the IV need not be secret,
some applications would see this as desirable [36,37]. Figure  4.15
shows the CFB mode. The encryption algorithm is

Cj = Pj ⊕ Ij (4.10)

and the decryption algorithm is

Pj = Cj ⊕ Ij (4.11)

Ij = EK (Cj−1 ),  j = 1, 2, 3, … (4.12)

C 0 = IV (4.13)

4.6.4  The OFB Mode

This mode is similar to the CFB mode. It begins by encrypting

the  IV. The bits of the encrypted IV are XORed with the corre-
sponding bits of the first plaintext block to get the corresponding
ciphertext block. Also, the output of the encryption algorithm is
used as an input to the next encryption step instead of the IV. This
process continues until the last block. Changing the IV for the same
 F un da m en ta l s o f In f o rm ati o n En c ry p ti o n 87

I0 = IV EK I1 EK I2 EK I3

P1 P2 P3

C1 C2 C3

Figure 4.16  Using a block cipher in the OFB mode.

plaintext block results in different ciphertext blocks. Figure  4.16

shows the OFB mode. The encryption algorithm is
Cj = Pj ⊕ Ij (4.14)
and the decryption algorithm is
Pj = Cj ⊕ Ij (4.15)

Ij = EK (I j−1 ),   j = 1, 2, 3, … (4.16)

I0 = IV (4.17)
 5
E n cryp ti on -B ased
M ultile v el M o d el
for DBMS

5.1 Introduction

This chapter presents the concept of the encryption-based multi-

level model for relational database management systems (DBMS).
This model is a combination of the multilevel relation model and
an encryption system. The encryption system is used to encrypt
each tuple (row) in the relation (table) with an encryption key that
depends on the security level of the tuple (tuple classification).
The ­encryption-based ­multilevel security (MLS) model is character-
ized by three achievements:
1. Utilizing an encryption system as an additional security layer
over the multilevel security layer for the relational database
2. Reducing the multilevel database size
3. Improving the response time of data retrieval from the multi-
level database
Also, this chapter summarizes the efforts of implementing a work-
ing multilevel relational database security prototype. This prototype
is used as a research tool for studying principles and mechanisms of
the encryption-based multilevel model and other multilevel relational
database security models (SeaView, Jajodia–Sandhu, Smith–Winslett,
multilevel relational [MLR], and belief-consistent models) [60].
The prototype that is implemented is used to make various experiments
to determine the relative performance of the multilevel ­relational
database security models and the performance cost for applying the
encryption system in multilevel relational database security.

89
90 Securit y f o r Rel ati o n a l Data ba se s

5.2  The Encryption-Based Multilevel Database Model

In the encryption-based multilevel database model, a symmetric

key is created for each unique security level and used to encrypt or
decrypt the data in the multilevel relational database. This key is
defined automatically by the model during the creation of the security
level. The user can use the keys that are defined to the security levels
lower than or equal to his security level. A multilevel relation scheme
is denoted by R(EC1(A1),EC2(A2), … ,ECn(A n),TC), where each Ai is a
data attribute over domain Di, each Ci is a classification attribute for
Ai, and ECi(Ai) is the encryption function for Ai by the key accord-
ing to the classification security level Ci.
In this model, the classification attributes for the multilevel rela-
tional database are removed and each attribute is encrypted by using
the encryption key that corresponds to the tuple security classification
level (tuple level encryption).
This removing of the classification attributes from the multilevel
database results in reducing the multilevel relational database size.
Tables 5.1 and 5.2 illustrate an example showing how the data are
stored in the MLR model and in the proposed encryption-based mul-
tilevel model. In the proposed model, adding the encryption system
to the MLR model led to solving the problems in the MLR model
by removing the classification attributes from the multilevel database
and then reducing the multilevel database size and making the data-
base administration easier.
The encryption algorithm is supported in several commercial
database management systems like DB2 (IBM) and ORACLE.
In DB2 (IBM) [61], encryption has been performed by implement-
ing SQL functions and stored procedures that help to encrypt and
decrypt the data. The user will supply the encryption key to be used
in encrypting the data during the insertion into the relational data-
base. When the data are retrieved, the same password should be
supplied to decrypt the data. In ORACLE [62], transparent data
encryption helps to encrypt the sensitive data stored in relations in
the database. Only the user who has access to the encrypted data
can decrypt it.
Table  5.3 shows a comparison between the encryption-based
­multilevel database model and the commercial database systems like
 Multil e v el M o d el f o r D BM S 91

Table 5.1  Multilevel Relational Database

EMPLOYEE C-EMPLOYEE DEPARTMENT C-DEPARTMENT SALARY C-SALARY TC
Ahmed U Accounting U 7,000 U U
Ahmed S Accounting S 7,000 S S
Mohamed TS Sales TS 10,000 TS TS

Table 5.2  Encryption-Based Multilevel Relational Database

EMPLOYEE DEPARTMENT SALARY TC
☒☒趉丽䎹㨫坰☒ ☒☒趉丽䎹㨫坰☒ ☒☒趉丽䎹㨫坰☒ U
鐀☒佂肰壾☒☒ 鐀☒佂肰壾☒☒ 鐀☒佂肰壾☒☒ S
㘀ㆨ爳䕩嶊瑳ꍫ☒ 㘀ㆨ爳䕩嶊瑳ꍫ☒ 㘀ㆨ爳䕩嶊瑳ꍫ☒ TS

Table 5.3  Comparison between Encryption-Based Multilevel Database Model and Commercial

Database Systems such as DB2 (IBM) and ORACLE
ENCRYPTION-
BASED MULTILEVEL DB2 ENCRYPTED ORACLE TRANSPARENT
MODEL/CRITERIA DATABASE FIELDS DATA ENCRYPTION
Encryption in Supported Not supported Not supported
multilevel security
Encryption type Row-based Column-based Column-based
encryption (one encryption (one encryption (one
password per row) password per column) password per column)
Encryption key Key is managed by Key provided by the Key provided by the user
database engine user at runtime at runtime

DB2 (IBM) and ORACLE that support encryption in their database

­management systems.
The symmetric encryption keys are stored as a hidden property for
the security classification levels of the multilevel database security.
The database administrator cannot read the encryption keys. He can
only read the security classification levels of the multilevel database
security.
In the encryption-based multilevel database model, caching has
an impact that should be taken into consideration as a plain text.
The impact of the caching is due to storing the decrypted data during
the transaction execution in the memory, which is a problem.
92 Securit y f o r Rel ati o n a l Data ba se s

The encryption-based multilevel database model solves the problem

of caching as follows:

• It causes the part of the memory that holds the decrypted data
to be blocked so that it can be accessed only from the database
engine instance.
• It supports multilevel security to the data so that the user
can see only the data in his level and a lower security level.
Supporting multilevel security in this model overcomes the
problem of caching because it generates a security layer that
manages the data access in the memory.

The encryption-based multilevel database model offers several major

contributions to the field:

• Adding an encryption system as an additional security layer

over the multilevel security layer for the database, which pro-
vides a high level of security and robustness against database
attacks
• Reducing the multilevel database size by removing the classi-
fication attributes and encrypting the tuples by the encryption
key according to its security level
• Reducing the complexity of design of the multilevel database
security because the database designer does not need to create
additional columns for attribute classification.

5.3 Manipulation

The data manipulation statements in the encryption-based multilevel

database model are INSERT, DELETE, SELECT, UPDATE, and
UPLEVEL [63].

5.3.1  The INSERT Statement

The INSERT statement executed by a user with security level L has

the following general form:

INSERT INTO R [A1,A2,...,An]

VALUES [a1,a2,...,an]
 Multil e v el M o d el f o r D BM S 93

where R is the relation name and [A1,A2,...,An] are the attribute

names. Each INSERT data manipulation can insert, at most, one tuple
into the relation R. The inserted tuple, t, is constructed as follows:
For all attributes in a database relation:
• If there is an attribute Ai in the attribute list of the INTO
clause, the data value ai will be encrypted by an encryption
key according to Ci, the security class level of the subject who
executes the insert statement.
• If Ai is not in the attribute list of the INTO clause, set the
data value to null.
• The tuple class will be set to the class level of the subject who
executes the insert statement.
Figure 5.1 illustrates the flow chart for the insertion operation in the
encryption-based multilevel database model.

5.3.2  The DELETE Statement

The DELETE statement executed by a user with security class level

L has the following general form:
DELETE FROM R
WHERE P

where R is the relation name, assuming relation R has attributes

[A1,A2, ...,A n]; r is the database relation instance; and P is a pred-
icate expression that may include conditions involving classification
attributes.
Only tuples t ∈ r with t[TC] = L are decrypted by key, according to
the security classification level of the user who executes the DELETE
statement.
For those tuples t ∈ r that satisfy the P predicate expression, r is
changed as follows:
• Create a temporary tuple for the decrypted data to store the
deleted tuple during the execution of the DELETE statement.
• The tuple that satisfies the predicate expression will be deleted.
• If there is a borrowed tuple in the high-security level that has
an attribute that depends on the attribute in the deleted tuple,
the value of this attribute will be set to null.
94 Securit y f o r Rel ati o n a l Data ba se s

Get user class L(user)

Set i = 1

i=i+1 Ai ∈ R [Ai]*

No Yes

Ai = null
Ci = L(user)

K = KCi

Ai = E (K, ai)

TC = L (user)

Insert the row

End

Figure 5.1  Flow chart for insertion operation in the encryption-based multilevel database model.
(A. Rask, D. Rubin, and B. Neumann. 2005. Implementing row- and cell-level security in classi-
fied databases using SQL server. Available at http://technet.microsoft.com/en-us/library/cc966395.
aspx; accessed April 2011.)

Figure  5.2 illustrates the flow chart for the delete operation in the
encryption-based multilevel database model.

5.3.3  The SELECT Statement

The SELECT statement executed by a user with security class level L

has the following general form:
SELECT [A1,A2,...,An] FROM R
WHERE P
 Multil e v el M o d el f o r D BM S 95

Ci = L(user)

K = KCi

Set i = 1

Yes
ti[TC] = L(user)
No

i=i+1 ti = D (K, E (K, ti))

ti[TC] ≻ L(user)

Yes No
ti satisfy P

Yes

Mark to be deleted
Detele ti
No by high user

End

Figure 5.2  Flow chart for the delete operation in the encryption-based multilevel database
model. (Y. Elovici et al. 2004. Proceedings of International Conference SDM, 28–40.)

where R is the relation name; [A1,A2,...,A n] are the attribute names;

and P is a predicate expression that may include conditions involving
the security classification attributes. Only those tuples t ∈ r that have
t[TC] ≤ L will be decrypted by key according to the classification level
of the subject that executes the SELECT statement and will be taken
into the calculation of P.
For those tuples t ∈ r that satisfy the P predicate expression:
• If a decrypted tuple satisfies the predicate expression, this
tuple will be included in the result of the SELECT statement.
Figure  5.3 illustrates the flow chart for the select operation in the
encryption-based multilevel database model.
96 Securit y f o r Rel ati o n a l Data ba se s

Ci = L(user)

K = KCi

Set i = 1

i=i+1

ti[TC] = L(user)
No
Yes

ti = D (K, E (K, ti))

No
ti satisfy P

Yes

Display ti

End

Figure 5.3  Flow chart for the select operation in the encryption-based multilevel database
model. (X.-D. Zuo, F.-M. Liu, and C.-B. Ma. 2007. Proceedings of the Sixth International Conference on
Machine Learning and Cybernetics, Hong Kong, 2158–2163.)

5.3.4  The UPDATE Statement

The UPDATE statement executed by a subject with security class

level L has the following general form:
UPDATE R SET [A1 = a1, A2 = a2,...,An = an]
WHERE P

where R is the relation name; [A1,A2,...,An] are the attribute names;

and P is a predicate expression that may include conditions involv-
ing classification attributes. Only tuples t ∈ r with t[TC] = L will be
decrypted by key according to the classification level of the subject that
executes the select statement and will be taken into the calculation of P.
For decrypted tuples t ∈ r that satisfies the predicate P, r is updated
as follows:
• Create a temporary tuple for decrypted data to store the deleted
tuple during the execution of the DELETE statement.
 Multil e v el M o d el f o r D BM S 97

• If there are no attributes of the primary key in the SET clause,

for attributes in the SET clause:
• Encrypt the attribute value and update the tuple.
• If there is a tuple that has an attribute that depends on the
attribute in the updated tuple, the value of this attribute will
be encrypted and updated.
• If there are attributes of the primary key in the SET clause:
• Encrypt the attribute value and update the tuple.
• If the primary key class is equal to the class of the subject
that executes the UPDATE statement, all tuples that have
the same primary key will be deleted.
Figure 5.4 illustrates the flow chart for the update operation in the
encryption-based multilevel database model.

5.3.5  The UPLEVEL Statement

The UPLEVEL statement executed by a user with security class level

L has the following general form:

UPLEVEL R GET [A1,A2,...,A n] FROM [C1,C2,...,Cn]

WHERE P

where R is the relation name; A1,A2,...,A n are data  attribute

names; C1,C2,...,Cn are values of classification levels for
A1,A2,...,A n, respectively; and P is a predicate expression that
may include conditions involving the classification attributes and
tuple-class a­ ttributes, in addition to the usual data attributes. Only
tuples t ∈ r with t[TC] ≤ L will be decrypted by key according to
the classification level of the tuple Key[TC] and will be taken into
the calculation of P.
For decrypted tuples that have at least one tuple t′ ∈ r that satisfies
the predicate P, an L-tuple, t, is constructed as follows:
• Create a temporary tuple for decrypted data to store the deleted
tuple during the execution of the UPLEVEL statement.
• If Ai is in the GET clause, encrypt the data in the tuple with
class equal to the security class level in the FROM clause.
• If Ai is not in the GET clause, set the data value to null.
98 Securit y f o r Rel ati o n a l Data ba se s

Ci = L(user)

K = KCi

Set i = 1

i=i+1 ti[TC] = L(user)

No
Yes

ti = D (K, E (K, ti))

No
ti satisfy P

Yes

ti [PK] ∈ [Ai]*
No Yes

Update ti ti[TC] ≥ L(user)

Yes No
Update t’i

Display t’i

End

Figure 5.4  Flow chart for the update operation in the encryption-based multilevel database
model. (N. Kaur, R. Singh, and H. S. Saini. 2009. Proceedings of IEEE International Advance Computing
Conference (IACC 2009) Patiala, India, 1400–1404.)

After tuple t is constructed, the following procedure will be applied:

• If there is a tuple that has a primary key equal to the primary
key of the constructed tuple and its security class level is equal to
the security class level of the user who executes the UPLEVEL
statement, this tuple will be replaced by the constructed tuple;
otherwise, the tuple will be added to the relation.
Figure 5.5 illustrates the flow chart for the uplevel operation in the
encryption-based multilevel database model.
 Multil e v el M o d el f o r D BM S 99

Ci = L(user)

K = KCi

Set i = 1

ti = D (K, E (K, ti))

ti [TC] ≤ L(user)
No Yes

i=i+1

Set j = 1

ti[Aj] ∈ [Ai]*
Yes No j=j+1

t[Aj] = E (K, ti[Aj]) t[Aj] = null

t[PK] = t´[PK] and

t[TC] = t´[TC]
Yes No

Tuple t´ will be Tuple t will be

replaced by t inserted

End

Figure 5.5  Flow chart for the uplevel operation in the encryption-based multilevel database
model. (R. Haraty and N. Bekaii. 2006. Journal of Computer Science 2 (1): 19–28.)
10 0 Securit y f o r Rel ati o n a l Data ba se s

5.4  Performance Study

This section describes the performance study of multilevel relational

database security models such as SeaView, Jajodia–Sandhu, Smith–
Winslett, MLR, and belief-consistent models and the encryption-based
multilevel database and illustrates the impact of changing the size and
schema of the relational database on the performance of these models.
The machine that is used for the implementation consists of CPU
speed of 2.2 GHz, physical RAM size of 3 GB, and hard disk size of
320 GB. The software used in the implementation is a Microsoft SQL
server 2008 R2 and the experiments’ measurements were captured at the
machine using a monitoring tool provided by the Microsoft SQL server.
Also, a prototype is implemented to determine the impact of the
encryption algorithms on a multilevel database and to find the suitable
algorithm to be used in the new encryption system. From Figure 5.6, we
observe that the suitable encryption algorithm is the AES_128 algorithm
that supports encryption with good performance and is cost effective.

5.4.1  Experimental Database Structure

The timesheet database consists of four relations and was created and
populated to facilitate our performance study. Timesheet ­system rela-
tions used in the implementation are described as follows:
• The employee relation provides information about employees:
• Employee(EMPID, Code, Name, Department, Type,
Contract, Shift, Religion, Job, Position, Address, City).
• The departure relation is used to store the departure notice of
each employee when he leaves the site of the work:
• Departure(EMPID, DepartureDate, ReturnDate,
DepartureType)
• The timesheet relation is used to store the timesheet of each
employee every day:
• TimeSheet(EMPID, Date, TimeSheet, OverTime,
Remarks)
• The annual rights relation is used to store the rights of each
employee every year:
• AnnualRights(EMPID, Year, Description, Inc, ADays,
GDays)
 Multil e v el M o d el f o r D BM S 101

1.40

1.30

1.20

1.10
Response Time (m)

1.00

0.90

0.80

0.70

0.60

0.50
0 0.5 1 1.5 2
Number of Tuples Millions

AES_256 AES_192 AES_128

TRIPLE_DES RC5 RC6

Figure 5.6  The impact of changing the number of tuples on the performance of the encryption
algorithms in a multilevel database in the selection query. (P. Dave. 2008. Available at http://dotnet-
slackers.com/articles/sql/IntroductionToSQLServerEncryptionAndSymmetricKeyEncryptionTutorial.
aspx, accessed May 2011.)

Figure 5.7 shows the ER diagram for the timesheet system used in

the implementation of the prototype to facilitate our performance
study.
The experiments investigate the impact of changing the number of
tuples, the number of attributes, and the number of security ­levels on
the performance of the relational multilevel database models. These
experiments use the CPU response time (in minutes) as a metric. For
each query, the monitoring tool observes the time that the system
takes to retrieve the result of the user query.
The queries were run several times and take the average response
time for executing the query. Also, we distribute the number of the
tuples of the relation in the database to be equal for all the security
classification levels.
We assume that the base value for the number of tuples is 1,000,000,
the base number of attributes is three, and the base number of security
levels is four.
10 2 Securit y f o r Rel ati o n a l Data ba se s

Figure 5.7  The ER diagram for the timesheet system used in the implementation.

5.4.2  SELECT Query

The following experiments define the impact of changing the number

of tuples, the number of attributes, and the number of security levels on
the performance of the multilevel relational database security ­models
and the encryption-based multilevel database model when execut-
ing the selection query. The overhead of the decryption is included
in the evaluation of the performance of the multilevel data retrieval.
The where clause in the SELECT query is taken into consideration
when we evaluate the performance of the multilevel database security
 Multil e v el M o d el f o r D BM S 10 3

models and the encryption-based multilevel database model when

executing the selection query.
The SELECT statement that is used in the following experiments
is described as follows:

Select * from Employee where department = ‘Sales.’

5.4.2.1  Impact of Varying the Number of Tuples  This e­ xperiment is used

to measure the impact of changing the n ­ umber of tuples on the
­performance of the multilevel relational ­database models. The num-
ber of tuples is varied to 100,000, 500,000, 1,000,000, 1,500,000
and 2,000,000. Fix the number of attributes at three; fix the
number of security levels at four. From Figure  5.8 the response
times grow for all models as the number of tuples is increased.

50
Number of attributes = 3
45 Number of security levels = 4

40

35
Response Time (minutes)

30

25

20

15

10

0
0 0.5 1 1.5 2
Number of Tuples Millions
SeaView Jajodia-Sandhu Smith-Winslett
MLR Belief-Consistent MLS-Encryption

Figure 5.8  Impact of changing the number of tuples in the selection query. (M. Garuba. 2003.
PhD thesis, Department of Mathematics, Royal Holloway, University of London, Egham, Surrey.
Available at http://digirep.rhul.ac.uk/items/f076f347-2036-6bd0-98c8-e1d2dc9cf4ab/1/, accessed
April 2011.)
10 4 Securit y f o r Rel ati o n a l Data ba se s

Also,  supporting encryption in the encryption-based multilevel

database model  improves the p ­ erformance of the multilevel rela-
tional database because database size is decreased due to removing
the extra attributes used for the class levels.

5.4.2.2  Impact of Varying the Number of Attributes  This experiment is

used to measure the impact of changing the number of attributes
on the performance of the multilevel relational database models.
The number of attributes varies from two to three, four, five, and six.
Fix the number of tuples at 1,000,000; fix the number of security
levels at four. From Figure 5.9 the response times grow for all models
as the number of attributes is increased. Also, supporting encryption
in the encryption-based multilevel database model improves the per-
formance of the multilevel relational database because the database
size is decreased due to removing the extra attributes used for the
class levels.

45
Number of tuples = million
Number of security levels = 4
40

35
Response Time (minutes)

30

25

20

15

10

0
2 3 4 5 6
Number of Attributes
SeaView Jajodia-Sandhu Smith-Winslett
MLR Belief-Consistent MLS-Encryption

Figure 5.9  Impact of changing the number of attributes in the selection query. (M. Garuba,
E. Appiah, and L. Burge. 2004. Proceedings of the International Conference on Information Technology:
Coding and Computing (ITCC’04), 566–570.)
 Multil e v el M o d el f o r D BM S 10 5

40
Number of attributes = 3
Number of tuples = million
35

30
Response Time (minutes)

25

20

15

10

0
2 3 4 5 6
Number of Classification Levels
SeaView Jajodia-Sandhu Smith-Winslett
MLR Belief-Consistent MLS-Encryption

Figure 5.10  Impact of changing the number of security levels in the selection query. (Z. Rashid,
A. Basit, and Z. Anwar. 2010. Proceedings of 6th International Conference on Emerging Technologies
(ICET), 337–342.)

5.4.2.3  Impact of Varying the Number of Security Levels  This ­experiment

is used to measure the impact of changing the numbers of secu-
rity levels on the performance of the multilevel relational database
­models. The number of security levels varies from two to three, four,
five, and six. Fix the number of tuples at 1,000,000; fix the number
of attributes at four. From Figure 5.10 the response times grow for all
models as the number of security levels is increased. Also, support-
ing encryption in the encryption-based multilevel database model
improves the performance of a multilevel database because the data-
base size is decreased due to removing the extra attributes used for the
class levels.

5.4.3  JOIN Query

The following experiments define the impact of changing the number

of tuples, the number of attributes, and the number of security l­evels
on the performance of the multilevel relational database security
10 6 Securit y f o r Rel ati o n a l Data ba se s

models and the encryption-based multilevel database model when

executing the JOIN query. The overhead of the decryption is included
in the evaluation of the performance of the multilevel data retrieval.
The where clause in the JOIN query will be taken into consideration
when we evaluate the performance of the multilevel database security
models and the encryption-based multilevel database model when
executing the JOIN query. The JOIN operation involves two tables:
the employee table and the departure table. The JOIN statement that
is used in the following experiments is described as follows:

Select * from Employee join Departure

on E
mployee.Name = Departure.Name where Employee.
department = ‘Sales’

5.4.3.1  Impact of Varying the Number of Tuples  The number of tuples

is varied from 100,000 to 500,000, 1,000,000, 1,500,000, and
2,000,000. Fix the number of attributes at three; fix the number of
security levels at four. From Figure  5.11 the response times grow

50 Number of attributes = 3
45 Number of security levels = 4

40
Response Time (minutes)

35

30

25

20

15

10

0
0 0.5 1 1.5 2
Number of Tuples Millions
SeaView Jajodia-Sandhu Smith-Winslett
MLR Belief-Consistent MLS-Encryption

Figure 5.11  Impact of changing the number of tuples in a join query. (V. M. Doshi et al. 1996.
Proceedings of IEEE Transactions on Knowledge and Data Engineering 8 (1): 46–55.)
 Multil e v el M o d el f o r D BM S 10 7

for all models as the number of tuples is increased. Also, s­ upporting

encryption in the encryption-based multilevel database model
­
improves the performance of a multilevel database because the data-
base size is decreased due to removing the extra attributes used for
the class levels.

5.4.3.2  Impact of Varying the Number of Attributes  The number of attri-

butes in each table is varied from two to three, four, five, and six.
Fix  the number of tuples at 1,000,000; fix the number of security
levels at four. From Figure 5.12 the response times grow for all m
­ odels
as the number of attributes is increased. Also, supporting encryp-
tion in the encryption-based multilevel database model improves
the performance of a multilevel database because the database size is
decreased due to removing the extra attributes used for the class levels.

5.4.3.3  Impact of Varying the Number of Security Levels  The number of

security levels is varied from two to three, four, five, and six. Fix the
number of tuples at 1,000,000; fix the number of attributes at  four.

50 Number of tuples = million

45 Number of security levels = 4

40
Response Time (minutes)

35

30

25

20

15

10

0
2 3 4 5 6
Number of Attributes
SeaView Jajodia-Sandhu Smith-Winslett
MLR Belief-Consistent MLS-Encryption

Figure 5.12  Impact of changing the number of attributes in a join query. (L. Pan. 2008.
Proceedings of International Symposium on Electronic Commerce and Security, 518–522.)
10 8 Securit y f o r Rel ati o n a l Data ba se s

50 Number of attributes = 3
45 Number of tuples = million

40
Response Time (minutes)

35

30

25

20

15

10

0
2 3 4 5 6
Number of Classification Levels
SeaView Jajodia-Sandhu Smith-Winslett
MLR Belief-Consistent MLS-Encryption

Figure 5.13  Impact of varying the number of security levels in a join query. (L. Pan. 2008.
Proceedings of International Symposium on Electronic Commerce and Security, 518–522.)

From Figure 5.13 the response times grow for all models as the n
­ umber
of the security levels is increased. Also, supporting encryption in the
encryption-based multilevel database model improves the performance
of a multilevel database because the database size is decreased due to
removing the extra attributes used for the class levels.

5.4.4  UPDATE Query

The number of the updated tuples is varied from 100,000 to 500,000,

750,000, and 1,000,000. Fix the number of attributes at three; fix the
number of security levels at four. From Figure 5.14 the response times
grow for all models as the number of tuples is increased. Also, sup-
porting encryption in the encryption-based multilevel database model
decreases the performance of a multilevel database because, during
the execution of the update statement, the encryption and decryption
mechanisms will be included together in the update procedure.
The where clause in the UPDATE query will be taken into consid-
eration when we evaluate the performance of the multilevel database
 Multil e v el M o d el f o r D BM S 10 9

14
Number of attributes = 3
Number of security levels = 4
12

10
Response Time (minutes)

0
0 0.25 0.5 0.75 1
Number of Tuples Millions
SeaView Jajodia-Sandhu Smith-Winslett
MLR Belief-Consistent MLS-Encryption

Figure 5.14  Impact of varying the number of tuples in an update query. (L. Pan. 2008. Proceedings
of International Symposium on Electronic Commerce and Security, 518–522.)

security models and the proposed encryption-based multilevel security

(MLS) model when executing the UPDATE query. The UPDATE
statement that is used in the following experiments is described as
follows:

Upd
ate Employee set salary = salary+100 where
department = ‘Sales’
­

5.5  Analysis of Experimental Results

The performance of the Smith–Winslett model is the best because it

does not support the security classification at the level of each single
attribute; the access classes can be assigned only to key attributes and
to tuples as a whole. The MLR model offers less performance than the
Smith–Winslett model because it supports the security classification
at the level of each single attribute. The belief-consistent model has
less performance than the MLR model because it supports a combi-
nation of the security classification levels for each single attribute to
enable the user to assert his beliefs of lower level users’ information.
110 Securit y f o r Rel ati o n a l Data ba se s

The Jajodia–Sandhu model has bad performance because of the impact

of union operation between single-level relations in the recovery algo-
rithm. The SeaView model has very bad performance because of the
impact of the JOIN operation between vertical single-level relations
and union operation between horizontal single-level relations in the
recovery algorithm.
From the experimental results in the previous section, the
­encryption-​based multilevel database model, which is a combination
of the MLR model and encryption algorithm, has performance b ­ etter
than the performance of the MLR model in retrieving data from the
multilevel database. This improvement in performance is due to the
reduction of the multilevel database size, removing the attributes clas-
sification columns, and encrypting the records by an encryption key
according to its security level. Also, by adding an encryption algorithm,
the overhead in the MLR model of checking the security class level
hierarchy for each data element when retrieving data is reduced. Instead
of checking the security class level hierarchy when getting data in the
encryption-based multilevel database model, the encryption keys belong
to the subject to encrypt each data element that is used when retriev-
ing data. The performance of the encryption-based multilevel database
model is less than the performance of the MLR model in updating
data because the overhead of supporting the encryption algorithm in
the update query is executed. Table 5.4 shows the reduction in database
size in the e­ ncryption-based multilevel database model compared to the
original MLR model and the other MLS models.

Table 5.4  Reduction in Database Size in Proposed Model Compared to Original MLR Model and
Other MLS Models
ENCRYPTION-
BELIEF- BASED
MODEL/ ORIGINAL JAJODIA– SMITH– CONSISTENT MULTILEVEL
CRITERIA MLR SEAVIEW SANDHU WINSLETT MLS DATABASE
Actual 106 129 116 98 110 91
database size
in megabytes
Reduction in Reduced Reduced Reduced Reduced Reduced by
database size by 15% by 30% by 22% by 8% 18%
in our proposed
model
 Multil e v el M o d el f o r D BM S 111

Table 5.5  Comparative Study between Encryption-Based Multilevel Database and Other

Multilevel Database Security Models
ENCRYPTION-
BELIEF- BASED
MODEL/ JAJODIA– SMITH– CONSISTENT MULTILEVEL
CRITERIA SEAVIEW SANDHU WINSLETT MLR MLS DATABASE
Performance 47 35 3 6 25 2
in minutes
Encryption Not Not Not Not Not Supported
supported supported supported supported supported

Table  5.5 gives a comparative study between the proposed

­encryption-based multilevel database model and the other m
­ ultilevel
database security models.

5.6 Summary

The encryption-based multilevel database model is implemented by

adding an encryption system as an additional layer of security over
the MLR model in multilevel relational database security. A working
multilevel secure database prototype was implemented in a Microsoft
SQL server database to measure the performance experiments that
were instrumented using the system. Also, this chapter measured the
impact of supporting encryption in the multilevel relational database;
the overhead of the encryption of data insertion and decryption of
data retrieval are included in the performance study.
Supporting encryption in multilevel relational databases improves
the performance of the retrieving of data in the SELECT and JOIN
queries. This improvement in the performance due to the relational
database size is decreased because the extra attributes used for the
class levels are replaced by supporting the encryption in the multilevel
relational database. Also, the multilevel relational database design is
easier because there is no change in the structure of the base table.
Supporting encryption in the multilevel relational database has a bad
performance because of the extra CPU processing results from sup-
porting the encryption algorithm in an MLS database. When sup-
porting the encryption algorithm in the UPDATE query is executed,
we decrypt the data, ensure the condition of the update statement,
execute the update statement, and encrypt the data again.
 6
F ormal A nalysis
for E n cryp ti on -
B ased M ultile v el
M od el for DBMS

6.1 Introduction

This chapter will present the formal analysis for data manipulation
language (DML) operations like SELECT, INSERT, UPDATE, and
DELETE for the encryption-based multilevel model for r­elational
database management systems. Also, this chapter will give the
­soundness, completeness, and the security mathematical proof for the
DML operations of the encryption-based multilevel database model.
The mathematical proofs show that the DML operations transform
any database in the correct state to another database in the correct
state, which indicates the power of the encryption-based multilevel
database model [75].
This model achieves good quality because it satisfies integrity
­properties such as entity integrity, polyinstantiation integrity, data
borrow integrity, foreign key integrity, and referential integrity of the
multilevel database.
The work presented in this chapter offers two major ­contributions
to the field:
• Redefining the mathematical model for the DML operations
for the encryption-based multilevel model
• Proving the soundness, completeness, and security of the
DML operations for the encryption-based multilevel model

113
114 Securit y f o r Rel ati o n a l Data ba se s

6.2  The Encryption-Based Multilevel Model for DBMS Definition

6.2.1  MLR Model Definition

Definition 6.2.1.1: A multilevel relational database scheme is defined

in the following form [76]:

• R(A1, C1, A2, C2, …, An, Cn, TC), where Ai is the attribute
that stores the data, Ci is the attribute that stores the secu-
rity c­ lassification level of the attribute Ai, and TC is the attri-
bute that stores the security classification level of the tuple.
The  domain of the value of the attribute Ci is defined by a
set {Li, …, Hi} where the Li is the lowest security classifica-
tion level and the Hi is the highest security classification level.
The domain of the TC is defined as U in=1 ({ Li ,... , H i }), where
U stands for the set of union.

Definition 6.2.1.2: The multilevel relational database instance is

defined in the following form [76]:
• r(A1, C1, A2, C2, …, An, Cn, TC), where r is a group of some
tuples that have the values (a1, c 1, a2, c 2, …, an, cn, tc), where
the value of ai ∈ Di and the value of ci ∈ {Li, …, Hi}, or a1
= null and ci ∈ {Li,  …,  Hi} U null, and tc ≥ lub {ci•ci ≠ null:
i = 1…,n}; lub stands for the least upper bound.

Definition 6.2.1.3: The relational database is a set of related rela-

tions and the database state is a set of all the relation instances of the
­relational database at a specific time [76].
• The instance r(A1, C1, A2, C2, …, An, Cn, TC) has some
­definitions that will be described as follows:
• The primary key A1 and its security classification level
attribute C1:
−− t[A1, C1] defines the tuple in the relation instance r
and also defines the security classification level of
the tuple.
−− t[C1] = c1 means that the tuple is inserted into the
­relational database by a user with c1 security classifica-
tion level.
 f o rm a l a n a lysis f o r D M L o p er ati o ns 115

• Tuple classification attribute (TC):

−− t[TC] = tc with t[C1] = c1 means a tuple t is inserted by
a user with tc security classification level. Tuple t can
only be displayed by users with security classification
level c′ ≥ tc. The tuple t can be modified by a user with
tc security classification level. t[TC] = t[C1] means that
tuple t is the base tuple and all tuples t′ ∈ r such that
t′[A1, C1] = t[A1, C1] depend on tuple t.
• Data Ai and its security classification level attribute
Ci(2 ≤ i ≤ n):
−− t[Ai, Ci] with t[Ci] = ci and t[TC] = tc[ci ≤ tc] defines
which data t[Ai] can be altered by users with tc secu-
rity classification level. t[Ai, Ci] can be modified by
users with tc or ci security classification levels. When
t[Ci] < t[TC], t[Ai] ≠ null is defined and a tuple that
is borrowed from the t′[Ai] of t′ that has t′[A1, C1] =
t[A1, C1] ∧ t′[TC] = t′[ci] = t[ci].
• Null value:
−− t[Ai,  Ci] = [null,  ci], [ci < tc] means that for each data
attribute Ai, there are users with tc security classification
levels that expect to borrow data owned by users with ci
security classification levels. Both t[Ai, Ci] = [null, null]
and t[Ai, Ci] = [null, tc] mean that there are no data avail-
able in the data attribute Ai. The [null, null] case applies
when tc ∉ {Li,…,Hi}; the [null, tc] case applies otherwise.

6.2.2  Encryption-Based Multilevel Model for DBMS Definition

The encryption-based multilevel model uses an encryption system

with secure certificates and keys. This model encrypts each tuple with
an encryption key according to its security classification level (tuple
classification).

Definition 6.2.2.1: A multilevel relational database scheme is defined

in the following form:
• R( EC1 ( A1 ), EC 2 ( A2 ),..., ECn ( An ),TC ), where Ai is the attribute
that stores the data, Ci is the attribute that stores the security
classification level of the attribute Ai, and TC is the attribute
116 Securit y f o r Rel ati o n a l Data ba se s

that stores the security classification level of the tuple. The

domain of the value of the attribute Ci is defined by a set
{Li,…Hi} where the Li is the lowest security classification level
and the Hi is the highest security classification level. ECi ( Ai )
is the encryption function of a data attribute. The domain of
the TC is defined as U in=1 ({ Li ,... , H i }), where U stands for the
set of union.

Definition 6.2.2.2: The multilevel relational database instance is

defined in the following form:

• r ( EC1 ( A1 ), EC 2 ( A2 ),..., ECn ( An ),TC ), where r is a group of some

tuples that have the form r ( Ec1 ( a1 ), Ec 2 ( a 2 ),...., Ecn ( an ), tc ) ,
where the value of ai ∈ Di and the value of ci ∈ {Li, …, Hi} or
ai = null and ci ∈ {Li, …, Hi} ⋃ null, and tc ≥ lub {ci • ci ≠ null:
i = 1…,n}; lub stands for the least upper bound.

Definition 6.2.2.3: The relational database is a set of related relations

and the database state is a set of all the relation instances of the rela-
tional database at a specific time.
The instance r ( EC1 ( A1 ), EC 2 ( A2 ),..., ECn ( An ),TC ) has some defini-
tions that will be described as follows:

• The primary key EC1 ( A1 ):

• t [ EC1 ( A1 )] defines the tuple in the relation instance r
and also defines the security classification level of the
tuple.
• Key ( EC1 ( A1 )) = c1 means that the tuple is inserted into the
relational database by a user with c1 security classification
level.
• Tuple-class attribute TC:
• t[TC] = tc with t[C1] = c 1 means that tuple t is inserted
by a user with tc security classification level. Tuple t can
only be displayed by users with security classification level
c′ ≥ tc. The tuple t can be modified by a user with tc secu-
rity classification level. t[TC] = t[C1] means that tuple t is
the base tuple and all tuples t′ ∈ r such that t′[A1, C1] =
t[A1, C1] depend on tuple t.
 f o rm a l a n a lysis f o r D M L o p er ati o ns 117

• Data attribute Ai and security classification level attribute

Ci(2 ≤ i ≤ n):
• t [ ECi ( Ai )] with Key (t [ ECi ( Ai )]) = ci defines that the data
t[A1] can be altered by users with tc security classifica-
tion level. t [ ECi ( Ai )] can be modified by users with tc or
ci security classification levels. When t[Ci] < t[TC], t[Ai] ≠
null is defined as a tuple borrowed from the t′[Ai] of t′ that
has t′[A1, C1] = t[A1, C1] ∧ t′[TC] = t′[ci] = t[ci].
• Null value:
• t[Ai, Ci] = [null, ci], (ci < tc) means that for each data attri-
bute Ai, there are users with tc security classification level
that expect to borrow data owned by users with ci secu-
rity classification level. Both t[Ai, Ci] = [null, null] and
t[Ai, Ci] = [null, tc] mean that there are no data available
in the data attribute Ai. The [null, null] case applies when
tc ∉ {Li, …, Hi}; the [null, tc] case applies otherwise.

6.3  Integrity Properties

6.3.1  Entity Integrity

In the entity integrity (EI) properties, a multilevel relational database

instance r satisfies the entity integrity if the following requirement
exists [77]:
For each tuple t ∈ r:
Ai ∈ AK ⇒ t[Ai] ≠ null;
Ai, Aj ∈ AK ⇒ t[Ci] = t[Cj];
and
Ai ∈ AK ⇒ t[Ci] ≥ t[C AK].
The first requirement ensures that no tuple t ∈ r has a null value for
any attribute in the primary key attributes AK. The second require-
ment ensures that all the primary key attributes AK should have the
same security classification level in the tuple t ∈ r. The third require-
ment states that the security classification level of the nonprimary key
attributes must be greater than or equal to the security classification
level of the primary key attributes.
118 Securit y f o r Rel ati o n a l Data ba se s

6.3.2  Polyinstantiation Integrity

In polyinstantiation integrity (PI), a multilevel relational database

instance r satisfies the polyinstantiation integrity if the following
requirement exists [78]:
For 1 ≤ i ≤ n:
A1, TC → Ci;
and
A1, C1, Ci → Ai;
This property ensures that the primary key attribute A1, in ­conjunction
with the security classification level attributes C1 and Ci, functionally
determines the value of the Ai attribute.

6.3.3  Data-Borrow Integrity

In data-borrow integrity (DBI), a multilevel relational database instance

r satisfies the data borrow if the following requirement exists [79]:
For 1 ≤ i ≤ n, all the nonprimary key attributes in tuple t ∈ r that
have data encrypted by key according to security classification levels
lower than the tuple classification level, there exists polyinstantiated
tuple t′ that has
t′[A1] = t[A1] ∧ t′[TC] = t′[ci] = t[ci] ∧ t′[Ai] = t[Ai].

6.3.4  Foreign Key Integrity

In foreign key integrity (FKI), let FK be a foreign key of the referenc-

ing relation R. A multilevel relational database instance r satisfies the
foreign key if the following requirement exists [79]:
For each tuple t ∈ r:
(∀Ai ∈ FK), t[Ai] ≠ null
and
Ai, Ai ∈ FK ⇒ t[Ci] = t[Ci]
The first requirement of this property ensures that no foreign key
attribute in the referencing relation has a null data value. The second
 f o rm a l a n a lysis f o r D M L o p er ati o ns 119

requirement ensures that all the foreign key attributes FK should have
the same security classification level in the tuple t ∈ r.

6.3.5  Referential Integrity

In referential integrity (RI), suppose that FK1 is defined for a foreign

key in the referencing relation R 1 that has a primary key AK1. Suppose
that R 2 is defined for the referenced relation that has a ­primary key
AK 2 [80]. Multilevel relational database instances r1, r2 satisfy the
­referential integrity if the following requirement exists:
For all
t 11 ∈ r 1
such that
t 11[FK1] ≠ null,
there exists
t 21 ∈ r 2
such that

t11 [ FK 1 ] = t 21 [ AK 2 ] ∧ t11 [TC ] = t 21 [TC ] ∧ t11 [C FK 1 ] ≥ t 21 [C AK 2 ] ,

and for all
t 11, t 12 ∈ r 1
and
t 21, t 22 ∈ r 2,
if
t11 [ AK 1 ] = t12 [ AK 1 ] ∧ t11 [TC ] = t 21 [TC ] ∧ t12 [TC ] = t 22 [TC ]
= t11 [C FK 1 ] = t12 [C FK 1 ] ∧ t11 [ FK 1 ] = t 21 [ AK 2 ]

= t 22 [ AK 2 ], then t 21 [ AK 2 ] = t 22 [ AK 2 ].

6.4 Manipulation

This section presents the data manipulation statements for the

­encryption-based multilevel database model.
12 0 Securit y f o r Rel ati o n a l Data ba se s

6.4.1  The INSERT Statement

The INSERT statement executed by a user with security level L (user)

has the following general form [81]:

INSERT INTO R [A1, A2, ...,An]

VALUES [a1, a2, ..., an]

R is the relation name and [A1, A 2, ..., A n] are the attribute names.
KCi is the symmetric encryption key associated to the s­ ecurity level of
the user. E(K, ai) is the encryption of data value ai by an encryption
key. Each INSERT data manipulation can insert, at most, one tuple
into the relation R. The inserted tuple t is constructed as follows:

For 1≤i≤n
If (Ai ∈ R[Ai]*)
{
Ci = L(user)
K = KCi
t[Ai] = E(K,ai)
}
Else
{
t[Ai] = null
}
t[TC] = L
i = i+1

Insert new tuple t into the multilevel relational database.

The insertion is permitted if the database state satisfies the entity
integrity, the foreign key integrity, and the referential integrity properties.

6.4.2  The DELETE Statement

The DELETE statement executed by a user with security class level

L has the following general form [82]:

DELETE FROM R
WHERE P

where R is the relation name, assuming that relation R has attributes

[A1,A2,...,An], r is the database relation instance, and P is a predicate
 f o rm a l a n a lysis f o r D M L o p er ati o ns 121

expression that may include conditions involving classification attri-

butes. ti(temp) is a temporary tuple for the decrypted data during the
execution of the delete statement. D(K,E(K,ti)) is the decryption of
the encrypted data value in the tuple ti by a symmetric encryption key.

Ci = L(user)
K = KCi
For 1≤i≤n
IF (ti[TC]= L(user)
{
ti(temp) = D(K, E(K, ti))
If (ti(temp) = p)
{
Delete ti
}
i = i +1
}
Else IF (ti[TC] ≻ L(user))
{
Mark to be deleted by high user.
i = i+1
}
Else
{
i = i+1
}

The DELETE statement is permitted if the database state satisfies the

entity integrity, the foreign key integrity, and the referential i­ntegrity
properties.

6.4.3  The SELECT Statement

The SELECT statement executed by a user with security class level L

has the following general form [82]:

SELECT [A1,A2,...,An] FROM R

WHERE P

where R is the relation name, [A1,A2,...,A n] are the attributes names,

and P is a predicate expression that may include conditions involving
the security classification attributes. ti(temp) is a temporary tuple for
12 2 Securit y f o r Rel ati o n a l Data ba se s

the decrypted data during the execution of the DELETE statement.

D(K,E(K,ti)) is the decryption of the encrypted data value in the
tuple ti by a symmetric encryption key.

Ci = L(user)
K = KCi
For 1≤i≤n
IF (ti[TC] = L(user))
{
ti(temp) = D(K,E(K,ti))
If (ti(temp) = p)
{
Display ti
}
i = i+1
}
Else
{
i = i+1
}

6.4.4  The UPDATE Statement

The UPDATE statement executed by a subject with security class

level L has the following general form [82]:

UPDATE R SET [A1=a1,A2=a2,...,An=an]

WHERE P

where R is the relation name, [A1,A 2,...,A n] are the attribute names,
and P is a predicate expression that may include conditions involving
classification attributes. ti(temp) is a temporary tuple for the decrypted
data during the execution of the delete statement. D(K,E(K,ti)) is
the decryption of the encrypted data value in the tuple ti by a sym-
metric encryption key.

Ci = L(user)
K = KCi
For 1≤i≤n
IF (ti[TC] = L(user))
{
ti(temp) = D(K, E(K, ti))
 f o rm a l a n a lysis f o r D M L o p er ati o ns 12 3

If (ti(temp) = p)
{
IF (ti[TC]≻L(user))
{
Mark to be deleted by high user.
i = i+1
}
Else
{
ti[Ai] = E(K, ai)
Update ti
}
i = i +1
}
Else
{
i = i+1
}

The UPDATE statement is permitted if the database state s­ atisfies

the entity integrity, the foreign key integrity, and the referential
­integrity properties.

6.4.5  The UPLEVEL Statement

The UPLEVEL statement executed by a user with security class level

L has the following general form [82]:

UPLEVEL R GET [A1, A2, ..., An] FROM [C1, C2, ..., Cn]
WHERE P

where R is the relation, A1,A 2,...,A n are the data ­ attributes,

C1,C2, ...,Cn are the security classification levels for A1, A 2, ..., A n,
and P is a predicate that may include conditions that define the tuples
that should be upleveled.

Ci = L(user)
K = KCi
For 1≤i≤n
IF (ti[TC] = L(user))
{
ti(temp) = D(K, E(K, ti))
12 4 Securit y f o r Rel ati o n a l Data ba se s

For 1≤j≤n
{
IF (ti(temp)[Aj]∈[Aj]*)
{
ti[Aj]=E(K,ti(temp)[Aj])
}
Else
{
ti[Aj]= null
}
j = j +1
}
Tuple t will be inserted
}
Else
{
i = i+1
}

The UPLEVEL statement is permitted if the database state satis-

fies the entity integrity, the foreign key integrity, and the referential
integrity properties.

6.5 Soundness

The soundness of the encryption-based multilevel database model will

be proven in this section. The following two definitions will clarify
the meaning of the soundness in the encryption-based multilevel
database model [83].

Definition 6.5.1: If all the multilevel relational instances satisfy the

integrity properties, the multilevel relational database will be in a
legal state.

Definition 6.5.2: If the sequences of the data manipulation ­operational

statements transform any legal database state to another legal ­database
state, the multilevel relational database will be sound.

To prove the soundness of the encryption-based multilevel ­database

model, four cases should be proven.
 f o rm a l a n a lysis f o r D M L o p er ati o ns 12 5

6.5.1  Case 1: In the INSERT Operation

The entity integrity, the foreign key integrity, and the referential
integrity properties should be satisfied in the INSERT operation.
Polyinstantiation integrity is satisfied because of the following:
• There is no polyinstantiated tuple t″ in the original relation
instance r with t ′′[ EC1 ( A1 )] = t [ EC1 ( A1 )] ∧ t ′′[TC ] = L, since
inserting the tuple t is permitted only if there is no t′ ∈ r such
that t'[A1] = t[A1] ∧ t'[TC] = L.
• There is no polyinstantiated tuple t″ in the original relation
instance r with t ′′[ EC1 ( A1 )] = t [ EC1 ( A1 )] ∧ t ′′[TC ] > L.
Data-borrow integrity is satisfied because of the following:
• There is no data attribute t[Ai](1 ≤ i ≤ n) in the tuple t with
t[Ci] < t[TC].

6.5.2  Case 2: In the DELETE Operation

The referential integrity properties should be satisfied in the DELETE

operation.
Entity integrity is satisfied because of the following:
• There is no tuple polyinstantiated tuple t″ in the original rela-
tion instance r with t ′′[ EC1 ( A1 )].
Polyinstantiation integrity is satisfied because of the following:
• There is no polyinstantiated tuple t′ in the original relation
instance r with t ′[ EC1 ( A1 )] = t [ EC1 ( A1 )] ∧ t′[TC] > L ∧ t′[Ci] =
L(2 ≤ i ≤ n).
• There is no polyinstantiated tuple t″ with t″[ EC1 ( A1 )] = t [ EC1 ( A1 )]
∧ t″[TC] < L ∧ t″[Ci] = L(2 ≤ i ≤ n).
Data-borrow integrity is satisfied because of the following:
• There is no polyinstantiated tuple t′ in the original relation
instance r with t ′[ EC1 ( A1 )] = t [ EC1 ( A1 )] ∧ t′[TC] > L ∧ t′[Ci] =
L(2 ≤ i ≤ n).
Foreign key integrity is satisfied because of the following:
• There is no polyinstantiated tuple t′ in the original r­elation
instance r with t ′[ EC1 ( A1 )] = t [ EC1 ( A1 )] ∧ t′[TC] > L ∧
t′[CFK] = L.
12 6 Securit y f o r Rel ati o n a l Data ba se s

6.5.3  Case 3: In the UPDATE Operation

The entity integrity, the foreign key integrity, and the referential
integrity properties should be satisfied in the UPDATE operation.
Polyinstantiation integrity is satisfied because of the following:
• There is no polyinstantiated tuple t′ in the original relation
instance r with t ′[ EC1 ( A1 )] = t [ EC1 ( A1 )]∧ t′[TC] > L ∧ t′[Ci] =
L(2 ≤ i ≤ n).
• There is no polyinstantiated tuple t″ with t″ [ EC1 ( A1 )] =
t [ EC1 ( A1 )] ∧ t″[TC] > L ∧ t″[Ci] = L(2 ≤ i ≤ n).
Data-borrow integrity is satisfied because of the following:
• There is no polyinstantiated tuple t′ in the original relation
instance r with t ′[ EC1 ( A1 )] = t [ EC1 ( A1 )] ∧ t′[TC] > L ∧ t′[Ci] =
L(2 ≤ i ≤ n).

6.5.4  Case 4: In the UPLEVEL Operation

The polyinstantiation integrity, the foreign key integrity, and the refer-
ential integrity properties should be satisfied in the UPDATE operation.
Entity integrity is satisfied because of the following:
• There is no tuple polyinstantiated tuple t′ in the original
­relation instance r with t ′[ EC1 ( A1 )] = t [ EC1 ( A1 )].
Data-borrow integrity is satisfied because of the following:
• There is no polyinstantiated tuple t′ in the original relation
instance r with t ′[ EC1 ( A1 )] = t [ EC1 ( A1 )] ∧ t′[TC] > L ∧ t′[Ci] =
L(2 ≤ i ≤ n).

6.6 Completeness

The completeness of the encryption-based multilevel database model

will be proven in this section. The following definitions will clarify
the meaning of the completeness in the encryption-based multilevel
database model [83].

Definition 6.6.1: If the sequences of the data manipulation operations

transform any legal database state to another legal database state, the
multilevel relational database will be complete.
 f o rm a l a n a lysis f o r D M L o p er ati o ns 12 7

Theorem 6.6.1: The encryption-based multilevel model is complete.

To prove the completeness of the encryption-based multilevel

model, the following lemmas should be proven.

Lemma 6.6.1: The sequences of the data manipulation operations

transform any legal database state to an empty database state.

Proof: In the DELETE operation, the following steps can be

performed:
• If the base tuple is deleted, any entity will be deleted totally.
In the DELETE operation, if the values of t [ EC1 ( A1 )] are
given in the WHERE clause, only the referencing tuples will
be deleted. This will ensure the referential integrity property.
• The empty database state can exist by deleting all entities in
all multilevel relational instances.

Lemma 6.6.2: The sequences of the data manipulation operation

transform any empty database to any legal database state.

Proof: In the INSERT operation, the following steps can be performed:

• The referencing tuples will be inserted before inserting the
referenced tuples.
• Each tuple is inserted by a user with a security classification
level equal to the tuple classification value as follows:
• The base tuple t is inserted by a user using an INSERT
­statement with all Ai that have t 1 [Ai] ≠ null listed in the
INTO clause, and t 1 [Ai] in the VALUES clause.

In the UPLEVEL operation, inserting any additional tuple tm is

done by the following step:
• All t m [ EC1 ( A1 )] with tm[Ci] < tm[TC] are included in the USE
clause of the UPLEVEL statement.

The legal database state can exist by using INSERT, UPLEVEL,

and UPDATE for inserting all entities in all multilevel relational
instances. This legal database state should satisfy the entity integrity,
12 8 Securit y f o r Rel ati o n a l Data ba se s

the polyinstantiation integrity, the foreign key integrity, the data-­

borrow integrity, and the referential integrity properties.

Proof of Theorem 6.6.1: From Lemmas 6.6.1 and 6.6.2, the sequences
of the data manipulation operational statements transform any legal
database state to another legal database state.

6.7 Security

Security is the basic issue of the encryption-based multilevel model

and is the advantage of this model over the traditional database
and the multilevel security database models. So, the security of the
encryption-based multilevel model is considered to be proved [83].
In this section, the following notation will be used:
S: all users with security classification levels
T: all tuples with security classification levels in a database state
Given any access level L,
SV(L): the group of the users with security classification
levels lower than or equal to L
SH(L): S – SV(L)
TV(L): the group of tuples with security classification
­levels lower than or equal to L
TH(L): T – TV(L)
It is known that, for any security classification level L,
S = SV(L) ∪ SH(L) and SV(L) ∩ SH(L) = φ, while T = TV(L) ∪ TH(L)
and TV(L) ∩ TH(L) = φ.
The following definitions will clarify the security requirement that
should be satisfied in the encryption-based multilevel database model.

Definition 6.7.1: A secure multilevel database model should ensure

that there is no interference when modifying the relations in the
multilevel database. For example, changing any input from user
S1 ∈ SH(L) cannot affect the output to any user S2 ∈ SV(L).

As shown in Figure 6.1, the input to the encryption-based ­multilevel

database model is a sequence of the data manipulation operational
statements (such as INSERT, DELETE, SELECT, UPDATE, and
 f o rm a l a n a lysis f o r D M L o p er ati o ns 12 9

Encryption-based multilevel model

Insert
Delete Encryption MLR
Success/
Select System Data
Failure

Figure 6.1  The interface of the encryption-based multilevel model.

UPLEVEL statements) from users with varying security ­classification

levels. The  outputs from the encryption-based multilevel database
model are the results retrieved by the users that include the following:
• Group of the retrieved tuples for the SELECT statement
• SUCCESS or FAILURE status for the INSERT, DELETE,
UPDATE, or UPLEVEL statements

Theorem 6.7.1: The encryption-based multilevel model is secure.

To prove this theorem, the following lemmas should be proven.

Lemma 6.7.1: For security classification level L, changing TH(L)

cannot affect the output to the user S ∈ SV(L).

Proof of Lemma 6.7.1: If a SELECT statement is executed by a user

that has security classification level L′, where S ∈ SV(L) (L′ ≤ L), no
tuples in TH(L′) will be taken into the calculation of P. Since L′ ≤ L
includes that TH(L′) ⊇ TH(L), modifying TH(L) cannot affect the
tuples’ output to S ∈ SV(L).

By the INSERT, DELETE, UPDATE, and UPLEVEL

operations for a user that has security classification level L′, where
S ∈ SV(L) (L′ ≤ L):
The INSERT operation executed by a user, s, could be rejected if:
• There is a tuple t′ ∈ r with t′[A1] = a1 ∧ t′[TC] = L′.
• The tuple t that is inserted violates the entity integrity, the
foreign key integrity, or the referential integrity properties.
The DELETE operation executed by a user, s, could be rejected if:
• The tuple with security classification level L that is deleted
is referenced by some tuples that have security classification
level L′ where (L′ ≤ L).
13 0 Securit y f o r Rel ati o n a l Data ba se s

The UPDATE operation executed by a user, s, could be rejected if:

• There is a tuple t′ ∈ r with t′[A1] = t[A1] ∧ t′[TC] = L′.
• The tuple t that is updated violates the entity integrity, foreign
key integrity, or referential integrity properties.
The UPLEVEL operation executed by a user, s, could be rejected if:
• There is a tuple t′ ∈ r with t′[A1] = t[A1] ∧ t′[C1] = t[C1] ∧
t′[TC] = L′.
• The tuple t that is updated violates the entity integrity, the
foreign key integrity, or the referential integrity properties.
Since t, t′ ∉ TH(L′) ⊇ TH(L), modifying TH(L) cannot affect the
S/F information output to S ∈ SV(L); therefore, modifying TH(L)
cannot affect the output to S ∈ SV(L).

Lemma 6.7.2: For security classification level L, deleting any input

from user S ∈ SH(L) cannot change TV(L).

Proof of Lemma 6.7.2: The user can change the database states by an
INSERT, DELETE, UPDATE, or UPLEVEL operation.

The INSERT operation is executed by a user, s, that has security

classification level L′, where S ∈ SH(L) (L′ > L) can only generate the
L′-tuple t′ since L′ > L, t′ ∉ T V(L).
The DELETE operation is executed by a user, s, that has security
classification level L′, where S ∈ SH(L) (L′ > L) can only delete L′-tuples
t′, and may change the polyinstantiation tuple t″ at levels L″(L″ > L′).
The UPDATE operation is executed by a user, s, that has security
classification level L′, where S ∈ SH(L) (L′ > L) can only change L′-tuples
t′ and may change the polyinstantiation tuple t″ at levels L″(L″ > L′).
The UPLEVEL operation is executed by a user, s, that has security
classification level L′, where S ∈ SH(L) (L′ > L) can only change L′-tuples
t′ and may change the polyinstantiation tuple t″ at levels L″(L″ > L′).
From the previous paragraphs, deleting any input from a subject
S ∈ SH(L) cannot change TV(L).

Proof of Theorem 6.7.1: From Lemma 6.7.1 and Lemma 6.7.2, for
any security classification level L, since S = SV(L) ∪ SH(L), SV(L) ∩
 f o rm a l a n a lysis f o r D M L o p er ati o ns 131

SH(L) = φ; while T = TV(L)  ∪  TH(L) and TV(L)  ∩  TH(L) =  φ,

deleting any input from user S1 ∈ SH(L) cannot affect the output to
S2 ∈ SH(L).

6.8 Summary

This chapter presented the concept of the encryption-based multilevel

database model, which improved the performance of the multilevel
relational database by decreasing the database size and enhancing
the response time for retrieving the data from the multilevel rela-
tional database. The mathematical forms for the data manipulation
operations such as SELECT, INSERT, UPDATE, and DELETE of
the multilevel relational database were refined to match the effect of
adding the encryption algorithm to the multilevel relational database
model. The mathematical proof of the soundness, the completeness,
and the security was introduced to demonstrate that the encryption-
based multilevel database model is robust against database attacks
and free from covert channel problems. The mathematical model for
multilevel integrity properties such as entity integrity, polyinstantia-
tion integrity, data borrow integrity, foreign key integrity, and refer-
ential integrity was introduced to characterize the verification of the
encryption-based multilevel database model.
 7
C on curren cy
C ontrol in M ultile v el
R el ati onal D atabases

7.1 Introduction

Most of the multilevel relational databases use the mandatory access

control mechanism that is based on the Bell–LaPadula model [84].
This model depends on the terms of the subjects and the data. The data
may be a relation, a tuple, or an attribute within a tuple. The sub-
ject is the active process that needs to access some data. Every datum
can be associated with a classification level (such as U = ­unclassified,
C = confidential, S = secret, and TS = top secret). Every subject also
is associated with a classification level (such as U = unclassified,
C = confidential, S = secret, and TS = top secret). Classification levels
are partially ordered. The access control in multilevel security is based
on the Bell–LaPadula model, which has the following properties:
• Simple security property: The subject can have a read access to
data only if his classification level is identical to or higher than
the classification level of the data.
• The *-property: The subject can have a write access to data
only if his classification level is identical to or lower than the
classification level of the data.
• The strong *-property: The subject can have a write access to
data only if his classification level is identical to the classifica-
tion level of the data.
In multilevel relational databases, concurrency control manages the
concurrent execution of data manipulation language operations (such
as SELECT, INSERT, UPDATE, and DELETE) that are per-
formed by different users on the same data at the same time [85]. There
are many concurrency control models that are implemented to produce

13 3
13 4 Securit y f o r Rel ati o n a l Data ba se s

serializable executions of the data manipulation language operations.

The most common concurrency control models are two-phase-­locking,
timestamp-ordering, and optimistic concurrency control models.
In the two-phase-locking (2PL) model, the data manipulation lan-
guage operation should need to have a write/read lock before it writes
or reads a data item [86].
In the timestamp-ordering model, a unique timestamp is assigned
to every data manipulation language operation and implements a read
timestamp and a write timestamp for each data item [87]. When a data
manipulation language operation is issued to read or write on the data
item, this operation is allowed only if the read or the write timestamp
of the data item is lower than the timestamp of the data manipulation
language operation; otherwise, the operation will be rejected.
In the traditional optimistic model, data manipulation language
operations are allowed to read and write on the data item without any
restriction.
Concurrency control is important for the multilevel relational data-
base because the covert channel problem can be found through the
overlap of the multilevel security operations [88]. In the multilevel
relational database, the concurrency control model should ensure
that the covert channel does not exist during the executions of the
operations at different levels of security. The covert channel problem
happens when a low classification level data manipulation language
operation is delayed or aborted by another high classification level
operation due to the need to access shared data items. So, by delaying
low classification level operations, high classification level informa-
tion can be indirectly known to the lower security level.
In the multilevel relational database, the following conflicts may
occur:
• Read-down conflict among different classification levels
• Read–write conflict at the same classification levels
• Write–write conflict at the same classification levels
Read-down conflict needs to be treated differently from the conflict
in relational multilevel security database systems because a relational
multilevel security database operation can read data in its classifica-
tion level and the classification level lower than it but can write data
only in its classification level.
 Multil e v el Rel ati o n a l Data ba se s 13 5

Common concurrency control models like the two-phase-locking

and the timestamp-ordering models are not suitable for the relational
multilevel security database because they establish the covert channel
problem between operations having different classification levels that
need access to the shared data item in the relational database. Many
models have been implemented for solving concurrency control in the
relational multilevel security database, such as secure locking, secure
timestamp-ordering and multiversion timestamp-ordering (MVTO)
models [89].
In the secure locking model, a high classification level data manip-
ulation operation should remove its lock on data when a low classifica-
tion level data manipulation operation needs a write lock on the same
data at the same time. When a read lock raised by a high classification
level data manipulation operation is aborted, it should be removed.
Because a low classification level data manipulation operation is not
blocked by a high classification level data manipulation operation,
many low classification level data manipulation operations may cause
a high classification level data manipulation operation to be broken
repeatedly, resulting in starvation [90].
In the secure timestamp-ordering model, if a high classification
level data manipulation operation needs to read low classification level
data, it will not start until all low classification level data manipula-
tion operations earlier in the timestamp are finished. A change of this
model gives the ability to the high classification level data manipula-
tion operation to read the low classification level data when it needs
to, but it cannot complete changes until all the low classification level
data manipulation operations have been completed [91].
Multilevel secure concurrency control models use an MVTO model
to eliminate both covert channels and starvation. When a low clas-
sification level data manipulation operation needs to write a datum
A while a high classification level data manipulation operation already
needs a read lock on A, the low classification level data manipulation
operation creates a new version of A. A problem of inconsistent ver-
sions of the data is given to the read of the high classification level data
manipulation operation, which is called a retrieval anomaly. To solve
the problem of the retrieval anomaly for the multilevel data manipu-
lation operations, the one-copy serializability algorithm is presented.
If a high classification level needs to read data that are being updated
13 6 Securit y f o r Rel ati o n a l Data ba se s

by a low classification level data manipulation operation, the high

security level transaction will be reexecuted starting from reading that
blocked data to present a one-copy serializable schedule [92].
The work presented in this chapter offers several major contribu-
tions to the field:
• Implementing a secure multiversion concurrency control
model by modifying the Rajwinder Singh model [93] by
dividing the write set of the transaction into two parts, which
decreases the blocking time of high classification level trans-
actions and improves the response time
• Implementing a prototype to measure the performance cost
for dividing write set of the transaction into two parts in the
secure multiversion concurrency control model
• Proofing the correctness of the secure multiversion concur-
rency control model by using the criteria of security, serial-
izability, fairness, selection of correct data version, and fast
version selection

7.2  Related Work

Kim and Sohn presented a multiversion secure concurrency control

model that satisfies the integrity and security rules [94]. This model
used the information of the conflict transaction set and the lock and
made the scheduler decide if a new version could be accessed to a
high classification level data manipulation operation. This model is
free from the problem of the starvation of high classification level data
manipulation operations by presenting the conflict transaction set, the
invisible area, and the t-lock. Also, this model can improve the avail-
ability of the relational multilevel database security system by adding
the concept of version management, which uses the t-locks and write
timestamps. Kim and Sohn present the following definitions:
• Definition 1: A read/write set of a transaction Ti is defined as
R-setTi /W-setTi. It contains the data that will be read/written
by the transaction Ti. When the transaction Ti is entered to
the scheduler, the scheduler gets R-setTi and W-setTi.
• Definition 2: The period between the times of the high clas-
sification level transaction, TH, is blocked by another low
 Multil e v el Rel ati o n a l Data ba se s 13 7

A schedule: OH,1, ….., OH,K ; OL,1 , ….., OL,m ; OH,K+1 , ….., OH,n ; CH

Invisible area of TH

TH Suspends TL Resumes TH

Figure 7.1  The notion of the invisible area.

transaction, TL; the time when TH executes again is called the

invisible area to TH. Defining the invisible area prevents the high
classification level transaction, TH, from reading new versions
created by the low transaction, TL , running within this area;
otherwise, TH may have the problem of the retrieval anomaly.
• Figure 7.1 presents the definition of the invisible area with
the execution of the high classification level transactions, TH ;
the low classification level transactions, TL; the high clas-
sification level operations, OH ; the low classification level
transactions, OL; and the high classification level transactions
commit, CH.
• Definition 3: A conflict transaction set of the high transaction
TH is defined as C-setTH and contains the transactions that
enter an invisible area of TH. Suppose that TL is entered to
the scheduler. If R-setTH ∩ W-setTL ≠ φ, then TL ∈ C-setTH.
• Definition 4: The transaction identifier (TID) is attached to
low transaction TL . The term “t-lock” will be used for the
attachment and detachment of a TID. When TL exists in
the invisible area of TH, its TID will be in the C-setTH of
the blocked high transaction TH.
Rajwinder Singh [95] adds a transaction into TL ∈ C-setTH. Singh’s
model reads the recent version by the high classification level trans-
action TH and shows that the size of C-setTH can be decreased by
increasing the condition without effect on the security of the mul-
tilevel relational database. Singh divided R-setTH into two parts:
R-setdoneTH and R-setremainingTH :

R-setdoneTH ∪ R-setremainingTH = R-setTH.

R-setdoneTH consists of the data read by TH.

R-setremainingTH consists of the data to be read by TH.

13 8 Securit y f o r Rel ati o n a l Data ba se s

7.3  Enhanced Secure Multiversion Concurrency Control Model

The enhanced secure multiversion concurrency control model is based

on the Rajwinder Singh proposed model to prevent ­creating the covert
channel without retrieval anomaly and to be free of the s­ tarvation of
the high-level transaction for multilevel r­elational d
­ atabase transac-
tions. The enhanced model improves on the Rajwinder Singh model
by splitting the write set of the low-level transactions that conflict
with the read set of the h ­ igh-level t­ransactions into “done” and
“­remaining.” This modification reduces the size of C-setTH by r­ elaxing
the ­condition used in the Rajwinder Singh model without affecting
the security of the database.
The enhanced secure multiversion concurrency control model
divided W-setTL into two parts: W-setdoneTL and W-setremainingTL .

W-setdoneTL ∪ W-setremainingTL = W-setTL .

W-setdoneTL contains data written by TL and W-setremainingTL contains

data to be written by TL .
The enhanced secure multiversion concurrency control model
also used an infinite timestamp instead of using t-lock to solve the
problem of the retrieval anomaly. When a transaction T is inserted
into the concurrency control manager, it will be assigned to a unique
timestamp, defined asts(T). If a transaction T creates the ith versions
of the data item A, an infinite write timestamp defined as Wts(Ai) will
be assigned. Then it will be updated with ts(T) when T commits.
So,  the read operation during its execution will get the version of
data item A in which its write timestamp is the recent timestamp and
is lower than or equal to its timestamp.
The enhanced secure multiversion concurrency control model
assumes that there is one scheduler that manages all the multilevel
transactions.
The enhanced secure multiversion concurrency control model con-
tains the following six steps:
• Step 1: When transaction Ti is entered to the scheduler,
R-setTi and W-setTi will be received.
• Step 2: If no transaction exists in the execution phase, the
scheduler runs and the scheduler will perform step 6.
 Multil e v el Rel ati o n a l Data ba se s 13 9

• Step 3: If a transaction Tj exists in the execution phase, the

scheduler has three cases:
• Case 1: L(Ti) > L(Tj). Step 4 is done, where L(Ti), L(Tj) are
the classification levels of the transactions Ti, Tj.
• Case 2: L(Ti) = L(Tj). Step 5 is ruined.
• Case 3: L(Ti) < L(Tj).
−− The scheduler denies Tj.
−− Set Ti is in the invisible area of Tj.
−− Create a new version of the data and an infinite write
timestamp is defined to it.
−− The transaction Ti will be executed immediately to
overcome the covert channel problem.
−− If (R-setdoneTj ∩ W-setremainingTi ≠ φ)|(R-setdoneTj ∩
R-setremainingTi ≠ φ), then Ti is added into C-setTj.
−− Perform step 6.
• Step 4: If the low transaction Tj is in the execution phase, the
scheduler will make the high classification level ­transaction Ti
wait until Tj commits and will perform step 6.
• Step 5: If the two transactions have the same classification
level, the scheduler will execute them at the same time.
• If (W-setremainingTj ∩ R-setdoneTi ≠ ϕ) & (W-setremainingTj ∩
W-setremainingTi ≠ ϕ), then Ti will enter an invisible area
of Tj for the time of the creation of a new version of con-
flicted data. After each of Ti and Tj are committed, step 6
will be performed.
• Step 6: If the transaction T is the only transaction that is run
at step 2, the scheduler will wait for other transactions to be
submitted. Otherwise, the scheduler will execute the transac-
tion, say TK, that has the lowest classification level among the
waiting transactions. The infinite write ­timestamp is assigned
to the new versions in the invisible areas of TK. Figure  7.2
shows the flow chart for the enhanced secure multiversion
concurrency control model.

7.4  Performance Evaluation

The performance of the enhanced secure multiversion concurrency

control model will be evaluated using two classification levels (high
and low) in the simulation.
14 0 Securit y f o r Rel ati o n a l Data ba se s

W-setTi and R-setTi received the scheduler

No
Tj in Execution

Yes
The scheduler executes Ti

Yes
L(Ti) > L(Tj)

No

No
L(Ti) = L(Tj)
Yes

(W-set?? Tj ∩
R-set?? Ti ≠ φ) &
Block Ti
(W-set?? Tj ∩
W-set?? Ti ≠ φ)
No Yes

The scheduler executes The scheduler selects and

them concurrently executes those transactions

End

Figure 7.2  The flow chart for the enhanced secure multiversion concurrency control model.

7.4.1  Workload Model

The workload defines the transactions according to their classification

levels and their data. Table 7.1 presents the main parameters of the
workload.

7.4.2  System Model

The machine that is used in the implementation consists of CPU

speed of 2.2 GHz, physical RAM size of 3 GB, and hard-disk size
of 320 GB. The software used in the implementation is a Microsoft
SQL server 2008 R2 and the experiments’ measurements were
 Multil e v el Rel ati o n a l Data ba se s 141

Table 7.1  Workload Parameter

PARAMETER DESCRIPTION VALUE
Arrival rate The arrival rate of the transaction From 0 to 100
Clear levels Number of classification levels 2
Transaction size The average size of the transaction 10

captured at the machine using a monitoring tool provided by the

Microsoft SQL server.
An experimental database, the timesheet database, consisting of
four relations was created and populated to facilitate our performance
study. Timesheet system relations used in the implementation are
described as follows:

The employee relation provides information about employees:

Employees(EMPID, Code, Name, Department, Type,
Contract, Shift, Religion, Job, Position, Address, City)
The departure relation is used to store the departure notice of
each employee when he leaves the site of the work:
Departure(EmpID, DepartureDate, ReturnDate,
DepartureType)
The timesheet relation is used to store the timesheet of each
employee every day:
TimeSheet(EMPID, Date, Timesheet, OverTime, Remarks)
The annual rights relation is used to store the rights of each
employee every year:
AnnualRights(EMPID, Year, Description, Inc, ADays, GDays)
Figure  7.3 shows an ER diagram for the timesheet system used
in the implementation of the prototype to facilitate our performance
study. The experiment investigates the average response times of trans-
actions at every security level for varying arrival rates. This experiment
uses the CPU response time (in milliseconds) as the metric.

7.4.3  Experiments and Results

In Figure  7.4, the response times of an enhanced secure multiver-

sion concurrency control model and the Rajwinder Singh model are
defined by using various arrival rates. In this figure, the response time
of the enhanced secure multiversion concurrency control model and
14 2 Securit y f o r Rel ati o n a l Data ba se s

Figure 7.3  ER diagram for the timesheet system used in the implementation.

500

450

400

350
Response Time (ms)

300

250

200

150

100

50 Rajwinder Singh Proposed

0
0 20 40 60 80 100
Arrival Rate

Figure 7.4  The impact of varying the arrival rates on the response times of the enhanced secure
multiversion concurrency control model and the Rajwinder Singh model.
 Multil e v el Rel ati o n a l Data ba se s 14 3

500
450
400
350
Response Time (ms)
300
250
200
150
100
50
0
0 20 40 60 80 100
Arrival Rate

Rajwinder Singh - low Rajwinder Singh - high

Proposed - low Proposed - high

Figure 7.5  The impact of varying the arrival rates on the response times of the enhanced secure
multiversion concurrency control model and the Rajwinder Singh model per security level.

the Rajwinder Singh model is the same at the low arrival rates. This is
because the conflict area is low. As the arrival rate increases, the
enhanced secure multiversion concurrency control model has ­better
performance than the performance of the Rajwinder Singh model.
This improvement in the performance is due to the reduction of the
denying time of high classification level transactions and improves
their response time.
In Figure 7.5, the response times of the enhanced secure multiver-
sion concurrency control model and the Rajwinder Singh model are
measured by calculating the response times at each classification level
by using various arrival rates.

7.5 Correctness of the Enhanced Secure Multiversion

Concurrency Control Model

The retrieval anomaly problem has a bad effect on the availability of

the multilevel relational database and it leads high transactions to be
aborted many times [96]. So, there is a great need for a secure con-
currency control model that meets the integrity, security, and avail-
ability requirements for the multilevel relational database. The covert
14 4 Securit y f o r Rel ati o n a l Data ba se s

channels and the starvation of the high transaction problems should

be prevented. In this section, the criteria for the correctness of the
enhanced secure multiversion concurrency control model will be
described as follows:

• Preventing the creation of the covert channel problem: The

low classification level transactions should not be delayed
when the high classification level transaction is in the execu-
tion phase.
• Preventing the starvation of the high transaction problem: If
the low classification level transactions need to be executed
when the high classification level transactions are executing,
the high transactions must not suffer from the repeated aborts
problem.
• Producing the serializable schedule for multilevel transac-
tions: Because of maintaining the consistency of the multi-
level relational database, the serializable schedule should be
presented for multilevel transactions.
• Preventing the retrieval anomaly problem when multiver-
sion data are run: The high security class level transactions
should read the right versions of the data, although there is a
creation of a new data version by the low security class level
transactions.
• The fast selection of the data version through more than one
version when multiversion data are run: While there are many
data versions in the multilevel relational database, the data
version selection needs to be fast.

7.5.1  Proof of Correctness

The enhanced secure multiversion concurrency control model should

not violate security requirement issues. This section will verify the
correctness of this model according to the criteria presented in the
previous section.
The covert channel is blocked by requiring the low security class
level transaction to be run when it is entered into the scheduler, and
by preventing the high security class level transactions when the low
transaction is executing [97].
 Multil e v el Rel ati o n a l Data ba se s 14 5

The starvation of the high security class level transactions can be

prevented by disallowing them to be reexecuted to read the new ver-
sions generated by the low security class level transactions to save the
consistency of the data when existing in the invisible area.
A serializable schedule can be presented for the multilevel transac-
tions by making the scheduler a one-copy serializable and one-copy
serial. The high classification level transaction will resume reading the
data that have been stored in the database.
The proof of the one-copy serializability of the enhanced secure
multiversion concurrency control model will be described as follows:
• Definition 1: a multiversion history H on T and a datum
X. A version order for X is a total order for all versions of X
in H. We define the version order by < and write Xi < Xj if
the version Xi precedes Xj in the version order. H = {ΣT, <T}
where:
1. ΣT = Ui Σi for i = 1,……,n.
2. <T = Ui <i for i = 1,……,n.
3. For any conflicting operations Oi,Oj in ΣT, either Oi <T Oj|
Oj <T Oi.
• Definition 2: H is a multiversion history on T and there is
some version order e for each item X. A multiversion serializa-
tion graph MVSG(H) for a multiversion history H over T is a
directed graph such that
• Nodes of MVSG(H) are transactions in T.
• There is a (directed) edge, Ti → Tj, i ≠ j, in MVSG(H)
whenever Rj[ Xi ] ∈ H.
• MVSG(H) also contains version order edges: For each
R k[ Xj ] and Wi[ Xi ] in H, there is an edge Ti → Tj if
Xi < Xj ; otherwise, there is an edge TK → Ti.
The retrieval anomaly problem can be prevented by assigning an
infinite write timestamp to the new data versions that are created by
the low transaction so that they are invisible to a high transaction.
The fast version selection can be performed by giving the read
operation the recent versions of the data that are not assigned to infi-
nite write timestamp because the data versions with infinite write
timestamp are visible to the transaction when the transaction resumes
at the end of its invisible area.
14 6 Securit y f o r Rel ati o n a l Data ba se s

7.6 Summary

In this chapter, the secure multiversion concurrency control model

based on the Rajwinder Singh model was implemented to solve
the problem of covert channel, retrieval anomaly, and starvation of
high security level transactions by maintaining multiple data ver-
sions. The model divided W−setTj into two parts—W−setdoneTj and
W−setremainingTj —and used an infinite timestamp instead of using
t-lock to prevent the creation of retrieval anomaly problems and to
ensure serializability of transaction. These modifications reduced the
conflict area between high- and low-level transactions and reduced
the blocking time of high-level transactions, resulting in improve-
ment of their response time. Also, this chapter implements a working
multilevel secure database prototype in a Microsoft SQL server data-
base to measure the performance experiments that were instrumented
using the system. Additionally, this chapter investigated the perfor-
mance of the proposed secure multiversion concurrency control model
by varying the transaction arrival rate. Finally, the correctness of a
secure multiversion concurrency control model by using the criteria of
security, serializability, fairness, selection of correct data version, and
fast version selection was proven.
 8
The I nstan ce -
B ased M ultile v el
S ecurit y M o d el

8.1 Introduction

Most multilevel relational databases use the mandatory access

­control mechanism that is based on the Bell–LaPadula model [98].
This model depends on the terms of the subjects and the objects.
The object may be a relation, a tuple, or an attribute within a
tuple.  The  subject is the active process that needs to access some
objects. Every object can be associated with a classification level
such as U (unclassified), C (confidential), S (secret), or TS (top
secret). Every subject also is associated with a classification level
(unclassified, confidential, secret, or top secret). Classification
­levels are partially ordered.
There are many challenges that face multilevel relational database
systems. The multilevel relational database system is restricted by the
security requirements in the Bell–LaPadula model, which prevent
covert channels [99] among the different classification levels. When
applying the security requirements in the multilevel relational data-
base, security should be ensured. As a result, some problems will be
raised and will be described as follows:
• The redundancy of the data: The SeaView model defines a
rule called the entity polyinstantiation integrity [100], which
provides the multilevel relational database system to save the
same tuple with various classification levels to protect the
higher classification level data.
Table  8.1 illustrates an example for the entity polyinstantiation
in the multilevel relational database. The primary key of the multi-
level relation is the employee attribute and the classification levels are

147
14 8 Securit y f o r Rel ati o n a l Data ba se s

defined to the data. The tuple classification is the security level for all
the tuples in the relation.
In Table  8.1, the three tuples present the same data but the
­polyinstantiation integrity policy divides the information ­according
to the various classification levels. Thus, this model stores more
data  in the multilevel relational database, resulting in data
redundancy.
The MLR security model [100] presents the “data borrow”
­concept and stores pointers in the higher level data (not the real
data) to o­ vercome the data redundancy problem. There is another
problem: We still need to save three tuples to present the single real
datum.
The BCMLS model [100] prevents the data redundancy problem
if the data redundancy of the attributes has the same classification
level, as shown in Table 8.1. The tuples can be saved as in Table 8.2
in BCMLS. If we have data as in Table  8.3, the BCMLS model
will need to save three tuples and the data redundancy cannot be
decreased.
• The problem of the null value inference: The inference when
dealing with the data is the second problem that faces the
multilevel security model. For example, if we have some of
the data as shown in Table 8.4(a), if the user with U classi-
fication level needs to execute select query, the result may be
null values, as described in Table 8.4(b). The null values could
cause some inference risks [101].

Table 8.1  Entity Polyinstantiation Integrity

EMPLOYEE DEPARTMENT SALARY TC
Ahmed U Sales U 7,000 U U
Ahmed U Sales U 7,000 U S
Ahmed U Sales U 7,000 U TS

Table 8.2  Data Redundancy of Attributes of the Same

Classification Level
EMPLOYEE DEPARTMENT SALARY TC
Ahmed U S TS Accounting U S TS 7,000 U S TS U S TS
 Ins ta n c e- Ba sed Multil e v el Securit y M o d el 14 9

Table 8.3  Three Tuples Belong to Three Levels in BCMLS

EMPLOYEE DEPARTMENT SALARY TC
Ahmed U S TS Accounting U -S -TS 7,000 U S -TS -U S TS
Ahmed U S TS Sales -U S TS 7,000 -U -S -TS S -TS
Ahmed U S TS Sales U -S TS 7,000 S TS S TS

Table 8.4(a)  The Inference Problem

EMPLOYEE DEPARTMENT SALARY
Ahmed U Sales U 7,000 U
Ahmed U Account S 8,000 U

Table 8.4(b)  The Inference Problem

EMPLOYEE DEPARTMENT SALARY
Ahmed U Sales U 7,000 U
Ahmed U Null 8,000 U

• The problem of the sensitive key value: The polyinstantiation

integrity rule in the multilevel relational security models is
intended to ensure the security of the data from the lower
classification level users by allowing only nonkey attributes
to access various values at various classification levels [101].
Since the multilevel relational database model uses the key
attributes to define the tuples, the polyinstantiation integrity
policy should be disallowed and then cannot prevent the risk
on the data.
Table  8.5 presents the problem of the sensitive key value. In the
employee table, the attribute employee is the primary key attribute.
Three tuples have various classification levels. The first contains the value
“Ahmed” in the employee attribute, which has the unclassified classifi-
cation level (U). The second tuple still has the value Ahmed for classi-
fication level (S). In the third tuple, the value for the employee attribute
has been modified to “Ali” and has the top classification level (T).
Suppose that the three tuples represent the same thing. The
­h ighest classification level user with the classification level (TS) will
access all three tuples as in Table 8.5 and will not know that the
first two tuples are used to protect the third tuple from the lower
classification level users.
15 0 Securit y f o r Rel ati o n a l Data ba se s

Table 8.5  The Sensitive Key Value Problem

EMPLOYEE DEPARTMENT SALARY TC
Ahmed U Accounting U 7,000 U U
Ahmed S Sales S 8,000 U S
Ali TS Sales S 10,000 TS TS

8.2  The Instance-Based Multilevel Security Model (IBMSM)

The instance-based model presents a two-layered model to the data;

every layer represents a different domain (Figure  8.1) [102]. Every
layer saves data and performs operations as follows:
• The instance layer contains the instances with its properties of
the model in a specific domain. The instance layer can create
and manipulate data for the domain of instances.
• The class layer contains the classes that define the simi-
larities of the instances that belong to the instance layer.
The class layer can create and manipulate the classes in the
class layer.
The users can define an object with its properties by the classifica-
tion levels in the multilevel relational database. The IBMSM contains
the following parts: the instance, the class, and the control models
and will be described as follows:

User(S) User 3 User2 (TS)

Class 2 Class 3
Class

Data

Figure 8.1  Two layers in IBMSM.

 Ins ta n c e- Ba sed Multil e v el Securit y M o d el 151

8.2.1  Definition 1: The Property View [102]

The instance at a classification level Lj is defined by i{(Pi,Lj) | Pi, ∈ P,

Lj ∈ L} where i is defined as the instance identifier, Pi is defined as the
property view on the group of the properties (P), and Lj is defined as
the classification level on the classification levels. A pair (Pi,Lj) pres-
ents the property’s view that belongs to the classification level Lj.
For example, in instance1{(FirstName Ahmed, U), (Salary 100, S),
(Salary 100, U), (Address Tanta, TS), (Address Cairo, S)}, the S level
can access the following view:
Instance1{(FirstName Ahmed, U), (Salary 100, S),
(Salary 100, U), (Address Cairo, S)}.

The U level will access the following view:

Instance1{(FirstName Ahmed, U), (Salary 100, U)}.

Since the user with a lower classification level cannot read the
higher classification level data, the instance view at the U classifica-
tion level contains less data than the view at the S classification level.

8.2.2  Definition 2: The Class View [102]

The class is defined as Class_ID({Pi}, {ui}) where Class_ID is defined

as the class identifier, {Pi} is defined as the group of properties, and
{ui} is defined as the group of users defined on the system.
The class can define which instances will be involved in the class
and can include the data of which users have the ability to access this
class. For example, if a class is defined as Class1({FirstName, Salary,
Address}, {user1, user2}), an instance of the class will be defined
as ­follows: Instance1{(FirstName Ahmed), (Salary 110), (Address
Tanta)} of the class. An instance Instance2{(FirstName Mohammed),
(Salary 110)} does not belong to the class.

8.2.3  Definition 3: The Instance View at Classification Level Lj [102]

The instance view at classification level Lj, which is i{(Pi, Lq) | Pi ∈ P,
Lq ≤ Lj and Lq Lj ∈ L} is related to the Class({PK}, {ui}) if the property
{PK} is a subgroup of the property {Pi }. A user with U classification
level can access Class({PK}, {ui}) if the user U ∈ {ui}.
15 2 Securit y f o r Rel ati o n a l Data ba se s

Rule 1: A user U with classification level L has the ability to read

the property of an instance with the classification level Lj if L ≥ Lj.

8.3  The advant address of IBMSM

• Preventing the null value inference problem: If the user

cannot see the instance’s property at specific classification
level, this property should not be found at this classification
level [103]. The absence of the property does not mean that
this property is rejected. For example, the null value may be
used if the value of the instance’s property does not exist or if
the instance cannot access this property. Thus, the meaning of
the null value is not clear.
• Preventing the data redundancy problem: In the IBMSM,
a datum could have many views in different classification lev-
els [103]. It is possible that several tuples (as different clas-
sification levels) could refer to one object. However, in the
IBMSM, any object is defined by its instance identifier.

8.4  The Select Operation Procedure of the IBMSM

The SQL-like command for the select operation has the following form:
SELECT [Ai]*
FROM R
WHERE P

The selection operation is implemented as follows:

Step 1: get the classification level of the user that executes the
select operation L(User).
Step 2: get the class views that belong to this user.
Step 3: get all the instance views that belong to the class views of
the user and satisfy the select condition P.
Step 4: for each instance, in the instance views, display the prop-
erty that has a class level lower than or equal to the classifica-
tion level of the user.
Figure  8.2 illustrates the SELECT operation procedure in the
IBMSM.
 Ins ta n c e- Ba sed Multil e v el Securit y M o d el 15 3

Get user class L(user)

Set i = 1

i=i+1
Get Classi ({P}, {u})

No
U ∈ Classi {u}

Yes

Set K = 1
K=K+1

Get InstanceK ({P}, {L})

No
InstanceK ∈ Classi

Yes

Set j = 1
j=j+1

Get PLj

No
L(user) ≥ PLj

Yes

Display PLj

End

Figure 8.2  The SELECT operation procedure in IBMSM. (E. Fernandez, E. Gudes, and
H. Song. 1989. Proceedings of the IEEE Symposium on Security and Privacy, 110–115.)
15 4 Securit y f o r Rel ati o n a l Data ba se s

8.5  Insert Operation Procedure of the IBMSM

The SQL-like command for the insert operation has the following
form:
INSERT
INTO R [Ai]*
VALUES [ai]*

The insertion operation is implemented as follows:

Step 1: get the classification level of the user that executes the
insert operation L(User).
Step 2: get the class views that belong to this user.
Step 3: if the attribute is included in the attributes list in the
insert statement, this attribute will be set to its value from
the values list in the insert statement; otherwise, the value of
this attribute will be null.
Step 4: insert the new instance with properties of the attributes’
values and the class level of the user into the multilevel relation.
Figure 8.3 illustrates the INSERT operation procedure in IBMSM.

8.6  The Update Operation Procedure of the IBMSM

The SQL-like command for the update operation has the following
form:
UPDATE R
SET Ai = ai,[Ai=ai]*
WHERE P

The update operation is implemented as follows:

Step 1: get the classification level of the user that executes the
update operation L(User).
Step 2: get the class views that belong to this user.
Step 3: get all the instance views that belong to the class views of
the user and satisfy the update condition P.
Step 4: for each instance, in the instance views, update the prop-
erty that has class level equal to the class level of the user.
Figure 8.4 illustrates the UPDATE operation procedure in IBMSM.
 Ins ta n c e- Ba sed Multil e v el Securit y M o d el 15 5

Get user class L(user)

Set i = 1

i=i+1
Get Classi ({P}, {u})

No
U ∈ Classi {u}

Yes

Set j = 1
j=j+1

Get PLj

PLj ∈ R[Ai]*
No Yes

Set PLj = null Set PLj = ai

Add PLj to Instance ({P}, {L})

Insert the instance ({P}, {L})

End

Figure 8.3  The INSERT operation procedure in IBMSM. (E. Fernandez, E. Gudes, and H. Song.
1994. International Journal of IEEE Transactions on Knowledge and Data Engineering 6  (2):
275–292.)
15 6 Securit y f o r Rel ati o n a l Data ba se s

Get user class L(user)

Set i = 1

i=i+1
Get Classi ({P}, {u})

No
U ∈ Classi {u}

Yes

Set K = 1
K=K+1

Get InstanceK ({P}, {L})

No
InstanceK ∈ Classi

Yes

Set j = 1
j=j+1

Get PLj

No
L(user) ≥ PLj

Yes

Update PLj

End

Figure 8.4  The UPDATE operation procedure in IBMSM. (E. Fernandez et al. 1994. International
Journal of IEEE Transactions on Knowledge and Data Engineering 6 (2): 275–292.)
 Ins ta n c e- Ba sed Multil e v el Securit y M o d el 15 7

8.7  The Delete Operation Procedure of the IBMSM

The SQL-like command for the delete operation has the following
form:

DELETE
FROM R
WHERE P

where R is an MLS relation and P is a delete condition that identifies

tuples that are to be deleted.

Step 1: get the classification level of the user that executes the
delete operation L(User).
Step 2: get the class views that belong to this user.
Step 3: get all the instance views that belong to the class views of
the user and satisfy the update condition P.
Step 4: for each instance, in the instance views, delete the
property that has class level equal to the class level of the
user.

Figure  8.5 illustrates the DELETE operation procedure in

IBMSM.

8.8  Comparative Study for Polyinstantiation Models

Table  8.6 illustrates the strengths and weaknesses of each model

in the last section. This table explains that earlier MLS database
models did not consider semantics as important as implementation.
Over time, the importance of semantics was properly recognized
and the Smith–Winslett model introduced simple semantics con-
cepts. That simplicity is paid for with restricting the scope of an
update to a single entity during the update procedure. The MLR
model removed that restriction (among other things), but it can-
not assert disbelief into the tuple. The belief-consistent model has
the most complete semantics but it has never been fully imple-
mented within a software application because it is very complex.
The IBMSM provides the ability to save one instance [107]. So, the
IBMSM provides m ­ ultilevel security and maximizes sharing of
data at various classification levels.
15 8 Securit y f o r Rel ati o n a l Data ba se s

Get user class L(user)

Set i = 1

i=i+1
Get Classi ({P}, {u})

No
U ∈ Classi {u}

Yes

Set K = 1
K=K+1

Get InstanceK ({P}, {L})

No
InstanceK ∈ Classi

Yes

Set j = 1
j=j+1

Get PLj

No
L(user) ≥ PLj

Yes

Detele PLj

End

Figure 8.5  The DELETE operation procedure in IBMSM. (J. Parsons and J. Su. 2006. Proceedings
of Design Science Research in Information Systems and Technology (DESRIST), Claremont, CA,
107–130.)
 Ins ta n c e- Ba sed Multil e v el Securit y M o d el 15 9

Table 8.6  Comparative Study for Polyinstantiation Models

NULL RESTRICTION DISBELIEF
DATA VALUE OF THE SCOPE IN
PROBLEM REDUNDANCY INFERENCE OF AN UPDATE A TUPLE SIMPLICITY
MODEL
SeaView Not solved Not solved Solved Not solved Very simple
Jajodia–Sandhu Solved Not solved Solved Not solved Simple
Smith–Winslett Solved Not solved Not solved Not solved Simple
MLR Solved Not solved Solved Not solved Complex
Belief- Solved Not solved Solved Solved Very complex
consistent
multilevel
secure
relational data
IBMSM Solved Solved Solved Solved Simple

8.9 Summary

The IBMSM data model is a simple, unambiguous, and powerful

model for supporting multilevel security databases. The advantage of
the IBMSM is that it eliminates null value inference and data redun-
dancy problems in other multilevel security database models. In this
chapter, we implemented the DML operations for the IBMSM.
We also explained the pseudocode and the flow charts for SELECT,
INSERT, UPDATE, and DELETE operations of the IBMSM. In
this chapter, we introduced a comparative study between the IBMSM
and other multilevel security database models to ensure that the
IBMSM solved most of the problems in the previous models. Also
in this chapter, we presented an overview of the multilevel relational
database security models and introduced the problems of each model.
 9
The S ource C od e

9.1 Introduction

This chapter will present the source code of the prototype that was
used throughout this book. The tools that are used in the implementa-
tion of the prototype are described as follows:
• Microsoft SQL server 2008 R2. SQL server is a relational
database management system (RDBMS) from Microsoft
that is designed for the enterprise environment. SQL Server
runs on T-SQL (Transact-SQL), a set of programming
extensions from Sybase and Microsoft that add several
features to standard SQL, including transaction control,
exception and error handling, row processing, and declared
variables.
• Microsoft Visual Studio C#. Microsoft Visual Studio is an
integrated development environment (IDE) from Microsoft.
It is used to develop console and graphical user interface
applications. The C# language is a simple, modern, general-
purpose, object-oriented programming language.
This chapter will present the screen shots of the prototype and
the  source code of the Microsoft SQL server 2008 R2 and the
Microsoft Visual Studio C# that were used in the implementation of
the prototype.

9.2  Screen Shots of the Prototype

The screen in Figure  9.1 is used for making the user log in to the
database by selecting the SQL server and entering his user name and
his password. At this screen the prototype will verify the credentials
of the user and will determine the user’s security classification level
(Figure 9.2).

161
16 2 Securit y f o r Rel ati o n a l Data ba se s

Figure 9.1  The login form.

Figure 9.2  The query form.

After successfully logging in, the user will get the query form. This
screen is used to help the user in executing his SQL query statement
and it contains the following:
• Execution button: used for executing the SQL query statement
• Selective radio button: used for selecting the multilevel data-
base security model
 T he S o ur c e C o d e 16 3

Figure 9.3  The concurrency control form.

• Text box: used for writing the SQL query statement

• Data grid: used for viewing the result of the SQL query
­statement (Figure 9.3)
This screen helps the user in executing the SQL query statement
and in simulating the concurrency control in the multilevel database
security. This form contains the following:
• Execution button: used for simulating the concurrency c­ ontrol
in the multilevel database security
• Selective radio button: used for selecting concurrency control
models in the multilevel database security model
• Text box: used for writing the number of the concurrent
transaction in the same time

9.3  Source Code of the Microsoft SQL Server

The source code of the Microsoft SQL server will be divided into
four parts:
• Create some tables that define the security classification levels
of the data in the multilevel relational database.
16 4 Securit y f o r Rel ati o n a l Data ba se s

Figure 9.4  The entity relationship diagram of the data security classification levels tables.

• Create roles that define the security classification levels of the

users in the multilevel relational database.
• Make some modifications to the base table.
• Define the view for each model of the multilevel relational
database models.

9.3.1 Source Code of the Data Security Classification

Level Tables (Figure 9.4)
CREATE TABLE [dbo].[tblCategory](
[ID] [int] IDENTITY(1,1) NOT NULL,
[LableSchemeID] [int] NULL,
[Name] [nvarchar](50) NULL,
[Abbreviation] [nvarchar](50) NULL,
[Hierarichical] [nchar](10) NULL,
[CompareRule] [nvarchar](50) NULL,
[Cardinality] [nvarchar](50) NULL,
[Required] [nchar](1) NULL,
[CreateDbRoles] [nchar](1) NULL,
[NoMarkingBehavior] [nvarchar](50) NULL,
[DefaultRole] [nvarchar](50) NULL,
CONSTRAINT [PK_tblCategory] PRIMARY KEY CLUSTERED
(
[ID] ASC
)WI
TH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,
IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_
PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
 T he S o ur c e C o d e 16 5

GO
CREATE TABLE [dbo].[tblMarking](
[CategoryID] [int] NOT NULL,
[MarkingRoleName] [nvarchar](50) NOT NULL,
[MarkingString] [nvarchar](50) NULL,
[Description] [nvarchar](50) NULL,
[RoleType] [nvarchar](50) NULL,
[InternallyGenerated] [nvarchar](50) NULL,
CONSTRAINT [PK_tblMarking] PRIMARY KEY CLUSTERED
(
[CategoryID] ASC,
[MarkingRoleName] ASC
)WI
TH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,
IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_
PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[tblMarkingHierarchy](
[ParentCategoryID] [int] NOT NULL,
[ParentMarkingRoleName] [nvarchar](50) NOT NULL,
[ChildCategoryID] [int] NOT NULL,
[ChildMarkingRoleName] [nvarchar](50) NOT NULL,
CON
STRAINT [PK_tblMarkingHierarchy] PRIMARY KEY
CLUSTERED
(
[ParentCategoryID] ASC,
[ParentMarkingRoleName] ASC,
[ChildCategoryID] ASC,
[ChildMarkingRoleName] ASC
)WI
TH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,
IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_
PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[tblUniqueLabel](
[ID] [int] NOT NULL,
[Label] [nvarchar](50) NULL,
[KeyName] [nvarchar](50) NULL,
[CertName] [nvarchar](50) NULL,
CONSTRAINT [PK_tblUniqueLabel] PRIMARY KEY CLUSTERED
(
[ID] ASC
)WI
TH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,
IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_
PAGE_LOCKS = ON) ON [PRIMARY]
16 6 Securit y f o r Rel ati o n a l Data ba se s

) ON [PRIMARY]
GO
CREATE TABLE [dbo].[tblUniquelabelMarking](
[KeyMappingID] [int] NOT NULL,
[CategoryID] [int] NOT NULL,
[MarkingRoleName] [nvarchar](50) NOT NULL,
CON
STRAINT [PK_tblUniquelabelMarking] PRIMARY KEY
CLUSTERED
(
[KeyMappingID] ASC,
[CategoryID] ASC,
[MarkingRoleName] ASC
)WI
TH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,
IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_
PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

9.3.2  Source Code of the User Security Classification Levels

CRE
ATE LOGIN [UUser] WITH PASSWORD = N’U’, DEFAULT_
DATABASE = [master], DEFAULT_LANGUAGE = [us_
en­
glish], CHECK_EXPIRATION = OFF, CHECK_POLICY = OFF
GO
CRE
ATE LOGIN [CUser] WITH PASSWORD = N’C’, DEFAULT_
DATABASE = [master], DEFAULT_LANGUAGE = [us_
english], CHECK_EXPIRATION = OFF, CHECK_POLICY = OFF
GO
CRE
ATE LOGIN [SUser] WITH PASSWORD = N’S’, DEFAULT_
DATABASE = [master], DEFAULT_LANGUAGE = [us_
english], CHECK_EXPIRATION = OFF, CHECK_POLICY = OFF
GO
CRE
ATE LOGIN [TSUser] WITH PASSWORD = N’TS’, DEFAULT_
DATABASE = [master], DEFAULT_LANGUAGE = [us_
english], CHECK_EXPIRATION = OFF, CHECK_POLICY = OFF
GO
USE [MLSDB]
CRE
ATE USER [UUser] FOR LOGIN [UUser] WITH DEFAULT_
SCHEMA = [dbo]
GO
USE [MLSDB]
CRE
ATE USER [CUser] FOR LOGIN [CUser] WITH DEFAULT_
SCHEMA = [dbo]
GO
 T he S o ur c e C o d e 16 7

USE [MLSDB]
CRE
ATE USER [SUser] FOR LOGIN [SUser] WITH DEFAULT_
SCHEMA = [dbo]
GO
USE [MLSDB]
CRE
ATE USER [TSUser] FOR LOGIN [TSUser] WITH DEFAULT_
SCHEMA = [dbo]
GO
USE [MLSDB]
CREATE ROLE [U] AUTHORIZATION [dbo]
GO
USE [MLSDB]
CREATE ROLE [C] AUTHORIZATION [dbo]
GO
USE [MLSDB]
CREATE ROLE [S] AUTHORIZATION [dbo]
GO
USE [MLSDB]
CREATE ROLE [TS] AUTHORIZATION [dbo]
GO

Figures 9.5–9.8 will introduce the properties of the roles that define

the security classification levels of the users in the multilevel rela-
tional database.

Figure 9.5  The properties of the U role in the database.

16 8 Securit y f o r Rel ati o n a l Data ba se s

Figure 9.6  The properties of the C role in the database.

Figure 9.7  The properties of the S role in the database.

 T he S o ur c e C o d e 16 9

Figure 9.8  The properties of the TS role in the database.

9.3.3  Source Code of the Modifications to the Base Table

The base table is called Employee and its source code for the creation
is described as follows:

CREATE TABLE [dbo].[Emp](

[Name] [nvarchar](50) NOT NULL,
[Department] [nvarchar](50) NULL,
[Salary] [smallmoney] NULL,
CONSTRAINT [PK_Employee_1] PRIMARY KEY CLUSTERED
(
[Name] ASC,
)WI
TH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,
IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_
PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

The modifications to the base table to form the SeaView model are
described as follows:

CREATE TABLE [dbo].[D1-u](

[Name] [nvarchar](50) NULL,
[CName] [int] NOT NULL
17 0 Securit y f o r Rel ati o n a l Data ba se s

) ON [PRIMARY]
GO
CREATE TABLE [dbo].[D2-c](
[Name] [nvarchar](50) NULL,
[CName] [int] NOT NULL,
[Department] [nvarchar](50) NULL,
[CDept] [int] NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[D2-s](
[Name] [nvarchar](50) NULL,
[CName] [int] NOT NULL,
[Department] [nvarchar](50) NULL,
[CDept] [int] NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[D2-ts](
[Name] [nvarchar](50) NULL,
[CName] [int] NOT NULL,
[Department] [nvarchar](50) NULL,
[CDept] [int] NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[D2-u](
[Name] [nvarchar](50) NULL,
[CName] [int] NOT NULL,
[Department] [nvarchar](50) NULL,
[CDept] [int] NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[D3-c](
[Name] [nvarchar](50) NULL,
[CName] [int] NOT NULL,
[Salary] [smallmoney] NULL,
[CSalary] [int] NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[D3-s](
[Name] [nvarchar](50) NULL,
[CName] [int] NOT NULL,
[Salary] [smallmoney] NULL,
[CSalary] [int] NOT NULL
) ON [PRIMARY]
GO
 T he S o ur c e C o d e 171

CREATE TABLE [dbo].[D3-ts](

[Name] [nvarchar](50) NULL,
[CName] [int] NOT NULL,
[Salary] [smallmoney] NULL,
[CSalary] [int] NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[D3-u](
[Name] [nvarchar](50) NULL,
[CName] [int] NOT NULL,
[Salary] [smallmoney] NULL,
[CSalary] [int] NOT NULL
) ON [PRIMARY]
GO

The modifications to the base table to form the Jajodia–Sandhu

model are described as follows:
CREATE TABLE [dbo].[Du](
[Name] [nvarchar](50) NULL,
[CName] [int] NOT NULL,
[Department] [nvarchar](50) NULL,
[CDept] [int] NOT NULL,
[Salary] [smallmoney] NULL,
[CSalary] [int] NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Dc](
[Name] [nvarchar](50) NULL,
[CName] [int] NOT NULL,
[Department] [nvarchar](50) NULL,
[CDept] [int] NOT NULL,
[Salary] [smallmoney] NULL,
[CSalary] [int] NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Ds](
[Name] [nvarchar](50) NULL,
[CName] [int] NOT NULL,
[Department] [nvarchar](50) NULL,
[CDept] [int] NOT NULL,
[Salary] [smallmoney] NULL,
[CSalary] [int] NOT NULL
) ON [PRIMARY]
GO
17 2 Securit y f o r Rel ati o n a l Data ba se s

CREATE TABLE [dbo].[Dts](

[Name] [nvarchar](50) NULL,
[CName] [int] NOT NULL,
[Department] [nvarchar](50) NULL,
[CDept] [int] NOT NULL,
[Salary] [smallmoney] NULL,
[CSalary] [int] NOT NULL
) ON [PRIMARY]
GO

The modifications to the base table to form the Smith–Winslett

model are described as follows:

CREATE TABLE [dbo].[Smith-Employee](

[Name] [nvarchar](50) NOT NULL,
[CName] [int] NOT NULL,
[Department] [nvarchar](50) NULL,
[Salary] [smallmoney] NULL,
[TC] [int] NOT NULL,
CONSTRAINT [PK_Smith-Employee] PRIMARY KEY CLUSTERED
(
[Name] ASC,
[CName] ASC
)WI
TH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,
IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_
PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

The modifications to the base table to form the MLR model are
described as follows:

CREATE TABLE [dbo].[Employee](

[Name] [nvarchar](50) NOT NULL,
[CName] [int] NOT NULL,
[Department] [nvarchar](50) NULL,
[CDept] [int] NOT NULL,
[Salary] [smallmoney] NULL,
[CSalary] [int] NOT NULL,
[TC] [int] NOT NULL,
CONSTRAINT [PK_Employee_1] PRIMARY KEY CLUSTERED
(
[Name] ASC,
 T he S o ur c e C o d e 173

[CName] ASC,
[CDept] ASC,
[CSalary] ASC,
[TC] ASC
)WI
TH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,
IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_
PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

The modifications to the base table to form the belief-consistent

model are described as follows:

CREATE TABLE [dbo].[BCEmployee](

[Name] [nvarchar](50) NOT NULL,
[CName] [int] NOT NULL,
[Department] [nvarchar](50) NULL,
[CDept] [int] NULL,
[Salary] [smallmoney] NULL,
[CSalary] [int] NULL,
[TC] [int] NULL,
[flag] [int] NULL,
CONSTRAINT [PK_BCEmployee] PRIMARY KEY CLUSTERED
(
[Name] ASC,
[CName] ASC
)WI
TH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,
IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_
PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

The modifications to the base table to form the encryption-based

multilevel database security model are described as follows:

CREATE TABLE [dbo].[Employee-Encryption](

[Name] [nvarchar](max) NOT NULL,
[Department] [nvarchar](max) NULL,
[Salary] [nvarchar](max) NULL,
[TC] [int] NOT NULL
) ON [PRIMARY]
GO
174 Securit y f o r Rel ati o n a l Data ba se s

9.3.4 Source Code of the View for Each Model of the

Multilevel Relational Database Models

The following SQL functions are used in the views of each model of
the multilevel relational database models:

CREATE FUNCTION [dbo].[SortLabels]()

RETURNS @Labels TABLE
(
Sort int,
LabelID int,
Label nvarchar(50)
)
AS
BEGIN
with RecursionCTE (Sort,Label)
as
(
select 0,ChildMarkingRoleName
from dbo.tblMarkingHierarchy
where ParentMarkingRoleName = ‘0’
union all
select R2.Sort+1,ChildMarkingRoleName
from dbo.tblMarkingHierarchy as R1
joi
n RecursionCTE as R2 on R1.ParentMarkingRoleName =
R2.Label
)
insert into @Labels select RecursionCTE.Sort,dbo.
tblUniqueLabel.ID,RecursionCTE.Label from
RecursionCTE inner join dbo.tblUniqueLabel on
RecursionCTE.Label = dbo.tblUniqueLabel.Label
RETURN
END
GO
create FUNCTION [dbo].[GetUserLabel]()
RETURNS nvarchar(10)
AS
BEGIN
declare @Label nvarchar(10)
select @Label = g.name
fr
om sys.database_principals u,
sys.database_principals g,
sys.database_role_members m
wh
ere g.principal_id = m.role_
principal_id
 T he S o ur c e C o d e 17 5

an
d u.principal_id = m.
member_principal_id
and u.name = CURRENT_USER
return @Label
END
GO
Cre
ate FUNCTION [dbo].[GetTCLabel](@CID int,@CName
int,@CDept int,@CSalary int)
RETURNS int
AS
BEGIN
declare @TC int
select @TC = LabelID from dbo.SortLabels()
whe
re Sort in (select min(Sort) from dbo.SortLabels()
where LabelID in (@CID,@CName,@CDept,@CSalary))
return @TC
END
GO
CREATE FUNCTION [dbo].[GetlBCLabe](@label int)
RETURNS nvarchar(10)
AS
BEGIN
declare @NewLabel nvarchar(10)
declare @ULabel nvarchar(1)
declare @CLabel nvarchar(1)
declare @SLabel nvarchar(1)
declare @TLabel nvarchar(1)
set @NewLabel = ‘’
set @ULabel = ‘’
set @CLabel = ‘’
set @SLabel = ‘’
set @TLabel = ‘’
set @ULabel = Cast(@label% 4 as nvarchar(1))
set @label = @label/4
set @CLabel = Cast(@label% 4 as nvarchar(1))
set @label = @label/4
set @SLabel = Cast(@label% 4 as nvarchar(1))
set @label = @label/4
set @TLabel = Cast(@label% 4 as nvarchar(1))
if @ULabel = ‘1’
set @NewLabel = @NewLabel+’-U’
else if @ULabel = ‘2’
set @NewLabel = @NewLabel+’U’
if @CLabel = ‘1’
set @NewLabel = @NewLabel+’-C’
17 6 Securit y f o r Rel ati o n a l Data ba se s

else if @CLabel = ‘2’

set @NewLabel = @NewLabel+’C’
if @SLabel = ‘1’
set @NewLabel = @NewLabel+’-S’
else if @SLabel = ‘2’
set @NewLabel = @NewLabel+’S’
if @TLabel = ‘1’
set @NewLabel = @NewLabel+’-T’
else if @TLabel = ‘2’
set @NewLabel = @NewLabel+’T’
return @NewLabel
END
GO
CREATE FUNCTION [dbo].[GetLabelID](@Label nvarchar(10))
RETURNS int
AS
BEGIN
declare @LabelID int
SELECT @LabelID = KeyMappingID FROM
tblUniqueLabelMarking WITH (NOLOCK)
WHERE CategoryID = 1 AND
MarkingRoleName = @Label
return @LabelID
END
GO
CREATE FUNCTION [dbo].[GetColumnLabel](@ID int)
RETURNS nvarchar(10)
AS
BEGIN
declare @Label nvarchar(10)
select @Label = Label from dbo.vwVisibleLabels
where ID = @ID
if @Label is null
begin
return dbo.GetUserLabel()
end
return @Label
END
GO
CRE
ATE FUNCTION [dbo].[GetColumnData](@ColumnData
nvarchar(50),@ColumnLabel int)
RETURNS nvarchar(50)
AS
BEGIN
declare @Data nvarchar(50)
 T he S o ur c e C o d e 17 7

declare @Label nvarchar(10)

select @Label = Label from dbo.vwVisibleLabels
where ID = @ColumnLabel
if @Label is null
begin
set @Data = ‘NULL’
end
else
begin
set @Data = @ColumnData
end
return @Data
END
GO
Create FUNCTION [dbo].[GetCLabel](@ID int)
RETURNS nvarchar(10)
AS
BEGIN
declare @Label nvarchar(10)
select @Label = Label from [dbo].[tblUniqueLabel]
where ID = @ID
return @Label
END
GO
CREATE FUNCTION [dbo].[GetBCUserView](@label int)
RETURNS nvarchar(10)
AS
BEGIN
declare @NewLabel nvarchar(10)
declare @ViewLabel nvarchar(10)
declare @BreakedLabel nvarchar(10)
declare @UserLabelID int
declare @NumericLabel int
declare @Counter int
set @NumericLabel = 0
set @Counter = 1
set @NewLabel = ‘’
sel
ect @UserLabelID = [dbo].GetLabelID([dbo].
[GetUserLabel]())
select @BreakedLabel = [dbo].BreaklLabe(@label)
WHILE (@Counter < = @UserLabelID)
BEGIN
set@NumericLabel = @NumericLabel+(POWER(4, @Counter-1)​
*CAST(SUBSTRING(@BreakedLabel,@Counter,1) AS int))
178 Securit y f o r Rel ati o n a l Data ba se s

— s
et @ViewLabel = @ViewLabel+SUBSTRING(@BreakedLabel,​
@Counter,1)
SET @Counter = @Counter + 1
END
set @NewLabel = dbo.GetlBCLabe(@NumericLabel)
return @NewLabel
END
GO
create FUNCTION [dbo].[BreaklLabe](@label int)
RETURNS nvarchar(10)
AS
BEGIN
declare @NewLabel nvarchar(10)
declare @ULabel int
declare @CLabel int
declare @SLabel int
declare @TLabel int
set @ULabel = @label% 4
set @label = @label/4
set @CLabel = @label% 4
set @label = @label/4
set @SLabel = @label% 4
set @label = @label/4
set @TLabel = @label% 4
set@NewLabel = Cast(@ULabel As nvarchar(1))
+Cast(@CLabel As nvarchar(1)) +Cast(@SLabel As
nvarchar(1))+Cast(@TLabel As nvarchar(1))
return @NewLabel
END
GO

The source code of the view for each model of the multilevel rela-
tional database models is described as follows:

CREATE VIEW [dbo].[vwVisibleLabels]

AS
SELECT ID, Label
FROM tblUniqueLabel WITH (NOLOCK)
WHERE
ID IN— Classification
(SELECT KeyMappingID FROM
tblUniqueLabelMarking WITH (NOLOCK)
WHERE CategoryID = 1 AND
IS_MEMBER(MarkingRoleName) = 1)
 T he S o ur c e C o d e 179

GO
CREATE VIEW [dbo].[vwEmployee]
AS
SEL ECT dbo.GetColumnData(dbo.Employee.Name, dbo.
Employee.CName) AS Name, dbo.GetColumnLabel​
(dbo.Employee.CName) AS ClassName,
dbo.GetColumnData(dbo.Employee.Department,
dbo.Employee.CDept) AS Department, dbo.
GetColumnLabel(dbo.Employee.CDept) AS ClassDept,
dbo.GetColumnData(dbo.Employee.Salary,
dbo.Employee.CSalary) AS Salary, dbo.
GetColumnLabel(dbo.Employee.CSalary) AS
ClassSalary,
dbo.GetColumnLabel(dbo.Employee.TC) AS TC
FROM dbo.Employee INNER JOIN
dbo.vwVisibleLabels ON dbo.Employee.TC
= dbo.vwVisibleLabels.ID
GO
CREATE VIEW [dbo].[VBCEmployee]
AS
SEL ECT Name, dbo.GetBCUserView(CName) AS C _ Name,
Department, dbo.GetBCUserView(CDept) AS C _ Department,
Salary, dbo.GetBCUserView(CSalary) AS C _ Salary,
dbo.GetBCUserView(TC) AS C_Tuple
FROM dbo.BCEmployee
WHERE (dbo.GetBCUserView(TC) <> ‘’)
GO
CREATE VIEW [dbo].[UserVisibleSmithEmployee]
AS
SEL ECT dbo.SmithEmployee.name, dbo.SmithEmployee.
CName, dbo.SmithEmployee.Department, dbo.
SmithEmployee.Salary, dbo.SmithEmployee.TC
FROM dbo.SmithEmployee INNER JOIN
dbo.vwVisibleLabels ON dbo.GetLabelID​
(dbo.SmithEmployee.TC) = dbo.
vwVisibleLabels.ID
GO
CREATE VIEW [dbo].[UserVisibleSeaViewEmployee]
AS
SEL ECT dbo.SeaViewEmployee.name, dbo.SeaViewEmployee.
CName, dbo.SeaViewEmployee.Department, dbo.
SeaViewEmployee.CDept, dbo.SeaViewEmployee.Salary,
dbo.SeaViewEmployee.CSalary, dbo.
SeaViewEmployee.TC
FROM dbo.SeaViewEmployee INNER JOIN
18 0 Securit y f o r Rel ati o n a l Data ba se s

dbo
.vwVisibleLabels ON dbo.GetLabelID​
(dbo.SeaViewEmployee.TC) = dbo.
vwVisibleLabels.ID
GO
CREATE VIEW [dbo].[UserVisibleJSEmployee]
AS
SEL ECT dbo.JSEmployee.name, dbo.JSEmployee.CName, dbo.
JSEmployee.Department, dbo.JSEmployee.Salary, dbo.
JSEmployee.TC
FROM dbo.JSEmployee INNER JOIN
dbo.vwVisibleLabels ON dbo.GetLabelID(dbo.
JSEmployee.TC) = dbo.vwVisibleLabels.ID
GO
CREATE VIEW [dbo].[SmithEmployee]
AS
SEL ECT name, dbo.[GetCLabel](CName) CName, Department,
Salary,dbo.[GetCLabel](CName) TC
FROM dbo.[Smith-Employee]
GO
CREATE VIEW [dbo].[SeaViewEmployee]
AS
SEL ECT dbo.[D2-u].name, dbo.[GetCLabel](dbo.[D2-u].CName)
CName, dbo.[D2-u].Department, dbo.[GetCLabel]
(dbo.[D2-u].CDept) CDept, dbo.[D3-u].Salary,
dbo.[GetCLabel](dbo.[D3-u].CSalary)
CSalary, dbo.[GetCLabel]([dbo].
[GetTCLabel](4, dbo.[D2-u].CName, dbo.
[D2-u].CDept, dbo.[D3-u].CSalary)) TC
FROM dbo.[D2-u] JOIN
dbo.[D3-u] ON dbo.[D2-u].Name = dbo.
[D3-u].Name
UNION
SEL ECT dbo.[D2-u].name, dbo.[GetCLabel](dbo.[D2-u].CName)
CName, dbo.[D2-u].Department, dbo.[GetCLabel](dbo.
[D2-u].CDept) CDept, dbo.[D3-c].Salary,
dbo.[GetCLabel](dbo.[D3-c].CSalary)
CSalary, dbo.[GetCLabel]([dbo].
[GetTCLabel](4, dbo.[D2-u].CName, dbo.
[D2-u].CDept, dbo.[D3-c].CSalary)) TC
FROM dbo.[D2-u] JOIN
dbo
.[D3-c] ON dbo.[D2-u].Name = dbo.[D3-c].Name
UNION
SEL
ECT dbo.[D2-u].name, dbo.[GetCLabel](dbo.[D2-u].CName)
CName, dbo.[D2-u].Department, dbo.[GetCLabel]
(dbo.[D2-u].CDept) CDept, dbo.[D3-s].Salary,
 T he S o ur c e C o d e 181

dbo.[GetCLabel](dbo.[D3-s].CSalary)
CSalary, dbo.[GetCLabel]([dbo].
[GetTCLabel](4, dbo.[D2-u].CName, dbo.
[D2-u].CDept, dbo.[D3-s].CSalary)) TC
FROM dbo.[D2-u] JOIN
dbo.[D3-s] ON dbo.[D2-u].Name = dbo.[D3-s].Name
UNION
SEL
ECT dbo.[D2-u].name, dbo.[GetCLabel](dbo.[D2-u].CName)
CName, dbo.[D2-u].Department, dbo.[GetCLabel](dbo.
[D2-u].CDept) CDept, dbo.[D3-ts].Salary,
dbo.[GetCLabel](dbo.[D3-ts].CSalary)
CSalary, dbo.[GetCLabel]([dbo].
[GetTCLabel](4, dbo.[D2-u].CName, dbo.
[D2-u].CDept, dbo.[D3-ts].CSalary)) TC
FROM dbo.[D2-u] JOIN
dbo.[D3-ts] ON dbo.[D2-u].Name = dbo.
[D3-ts].Name
UNION
SEL
ECT dbo.[D2-c].name, dbo.[GetCLabel](dbo.[D2-c].CName)
CName, dbo.[D2-c].Department, dbo.[GetCLabel](dbo.
[D2-c].CDept) CDept, dbo.[D3-u].Salary,
dbo.[GetCLabel](dbo.[D3-u].CSalary)
CSalary, dbo.[GetCLabel]([dbo].
[GetTCLabel](4, dbo.[D2-c].CName, dbo.
[D2-c].CDept, dbo.[D3-u].CSalary)) TC
FROM dbo.[D2-c] JOIN
dbo.[D3-u] ON dbo.[D2-c].Name = dbo.
[D3-u].Name
UNION
SEL
ECT dbo.[D2-c].name, dbo.[GetCLabel](dbo.[D2-c].CName)
CName, dbo.[D2-c].Department, dbo.[GetCLabel](dbo.
[D2-c].CDept) CDept, dbo.[D3-c].Salary,
dbo.[GetCLabel](dbo.[D3-c].CSalary)
CSalary, dbo.[GetCLabel]([dbo].
[GetTCLabel](4, dbo.[D2-c].CName, dbo.
[D2-c].CDept, dbo.[D3-c].CSalary)) TC
FROM dbo.[D2-c] JOIN
dbo.[D3-c] ON dbo.[D2-c].Name = dbo.
[D3-c].Name
UNION
SEL
ECT dbo.[D2-c].name, dbo.[GetCLabel](dbo.[D2-c].CName)
CName, dbo.[D2-c].Department, dbo.[GetCLabel]
(dbo.[D2-c].CDept) CDept, dbo.[D3-s].Salary,
dbo.[GetCLabel](dbo.[D3-s].CSalary)
CSalary, dbo.[GetCLabel]([dbo].
18 2 Securit y f o r Rel ati o n a l Data ba se s

[GetTCLabel](4, dbo.[D2-c].CName, dbo.

[D2-c].CDept, dbo.[D3-s].CSalary)) TC
FROM dbo.[D2-c] JOIN
dbo
.[D3-s] ON dbo.[D2-c].Name = dbo.[D3-s].Name
UNION
SEL
ECT dbo.[D2-c].name, dbo.[GetCLabel](dbo.[D2-c].CName)
CName, dbo.[D2-c].Department, dbo.[GetCLabel](dbo.
[D2-c].CDept) CDept, dbo.[D3-ts].Salary,
dbo.[GetCLabel](dbo.[D3-ts].CSalary)
CSalary, dbo.[GetCLabel]([dbo].
[GetTCLabel](4, dbo.[D2-c].CName, dbo.
[D2-c].CDept, dbo.[D3-ts].CSalary)) TC
FROM dbo.[D2-c] JOIN
dbo.[D3-ts] ON dbo.[D2-c].Name = dbo.
[D3-ts].Name
UNION
SEL
ECT dbo.[D2-s].name, dbo.[GetCLabel](dbo.[D2-s].CName)
CName, dbo.[D2-s].Department, dbo.[GetCLabel](dbo.
[D2-s].CDept) CDept, dbo.[D3-u].Salary,
dbo.[GetCLabel](dbo.[D3-u].CSalary)
CSalary, dbo.[GetCLabel]([dbo].
[GetTCLabel](4, dbo.[D2-s].CName, dbo.
[D2-s].CDept, dbo.[D3-u].CSalary)) TC
FROM dbo.[D2-s] JOIN
dbo.[D3-u] ON dbo.[D2-s].Name = dbo.[D3-u].Name
UNION
SEL
ECT dbo.[D2-s].name, dbo.[GetCLabel](dbo.[D2-s].CName)
CName, dbo.[D2-s].Department, dbo.[GetCLabel](dbo.
[D2-s].CDept) CDept, dbo.[D3-c].Salary,
dbo.[GetCLabel](dbo.[D3-c].CSalary)
CSalary, dbo.[GetCLabel]([dbo].
[GetTCLabel](4, dbo.[D2-s].CName, dbo.
[D2-s].CDept, dbo.[D3-c].CSalary)) TC
FROM dbo.[D2-s] JOIN
dbo.[D3-c] ON dbo.[D2-s].Name = dbo.[D3-c].Name
UNION
SEL
ECT dbo.[D2-s].name, dbo.[GetCLabel](dbo.[D2-s].CName)
CName, dbo.[D2-s].Department, dbo.[GetCLabel](dbo.
[D2-s].CDept) CDept, dbo.[D3-s].Salary,
dbo.[GetCLabel](dbo.[D3-s].CSalary)
CSalary, dbo.[GetCLabel]([dbo].
[GetTCLabel](4, dbo.[D2-s].CName, dbo.
[D2-s].CDept, dbo.[D3-s].CSalary)) TC
FROM dbo.[D2-s] JOIN
dbo.[D3-s] ON dbo.[D2-s].Name = dbo.[D3-s].Name
 T he S o ur c e C o d e 18 3

UNION
SEL ECT dbo.[D2-s].name, dbo.[GetCLabel](dbo.[D2-s].CName)
CName, dbo.[D2-s].Department, dbo.[GetCLabel](dbo.
[D2-s].CDept) CDept, dbo.[D3-ts].Salary,
dbo.[GetCLabel](dbo.[D3-ts].CSalary)
CSalary, dbo.[GetCLabel]([dbo].
[GetTCLabel](4, dbo.[D2-s].CName, dbo.
[D2-s].CDept, dbo.[D3-ts].CSalary)) TC
FROM dbo.[D2-s] JOIN
dbo.[D3-ts] ON dbo.[D2-s].Name = dbo.
[D3-ts].Name
UNION
SEL ECT dbo.[D2-ts].name, dbo.[GetCLabel](dbo.[D2-ts].CName)
CName, dbo.[D2-ts].Department, dbo.[GetCLabel](dbo.
[D2-ts].CDept) CDept, dbo.[D3-u].Salary,
dbo.[GetCLabel](dbo.[D3-u].CSalary)
CSalary, dbo.[GetCLabel]([dbo].
[GetTCLabel](4, dbo.[D2-ts].CName, dbo.
[D2-ts].CDept, dbo.[D3-u].CSalary)) TC
FROM dbo.[D2-ts] JOIN
dbo.[D3-u] ON dbo.[D2-ts].Name = dbo.
[D3-u].Name
UNION
SEL ECT dbo.[D2-ts].name, dbo.[GetCLabel](dbo.[D2-ts].CName)
CName, dbo.[D2-ts].Department, dbo.[GetCLabel](dbo.
[D2-ts].CDept) CDept, dbo.[D3-c].Salary,
dbo.[GetCLabel](dbo.[D3-c].CSalary)
CSalary, dbo.[GetCLabel]([dbo].
[GetTCLabel](4, dbo.[D2-ts].CName, dbo.
[D2-ts].CDept, dbo.[D3-c].CSalary)) TC
FROM dbo.[D2-ts] JOIN
dbo.[D3-c] ON dbo.[D2-ts].Name = dbo.
[D3-c].Name
UNION
SEL
ECT dbo.[D2-ts].name, dbo.[GetCLabel](dbo.[D2-ts].CName)
CName, dbo.[D2-ts].Department, dbo.[GetCLabel](dbo.
[D2-ts].CDept) CDept, dbo.[D3-s].Salary,
dbo.[GetCLabel](dbo.[D3-s].CSalary) CSalary,
dbo.[GetCLabel]([dbo].[GetTCLabel](4, dbo.
[D2-ts].CName, dbo.[D2-ts].CDept, dbo.
[D3-s].CSalary)) TC
FROM dbo.[D2-ts] JOIN
dbo.[D3-s] ON dbo.[D2-ts].Name = dbo.
[D3-s].Name
18 4 Securit y f o r Rel ati o n a l Data ba se s

UNION
SEL ECT dbo.[D2-ts].name, dbo.[GetCLabel](dbo.[D2-ts].CName)
CName, dbo.[D2-ts].Department, dbo.[GetCLabel](dbo.
[D2-ts].CDept) CDept, dbo.[D3-ts].Salary,
dbo.[GetCLabel](dbo.[D3-ts].CSalary)
CSalary, dbo.[GetCLabel]([dbo].
[GetTCLabel](4, dbo.[D2-ts].CName, dbo.
[D2-ts].CDept, dbo.[D3-ts].CSalary)) TC
FROM dbo.[D2-ts] JOIN
dbo.[D3-ts] ON dbo.[D2-ts].Name = dbo.
[D3-ts].Name
GO
CREATE VIEW [dbo].[JSEmployee]
AS
SEL
ECT name, dbo.[GetCLabel](CName) CName, Department,
dbo.[GetCLabel](CDept) CDept, Salary,
dbo.[GetCLabel](CSalary) CSalary, dbo.
[GetCLabel]([dbo].[GetTCLabel](4,
CName, CDept, CSalary)) TC
FROM dbo.Du
UNION
SEL
ECT name, dbo.[GetCLabel](CName) CName, Department,
dbo.[GetCLabel](CDept) CDept, Salary,
dbo.[GetCLabel](CSalary) CSalary, dbo.
[GetCLabel]([dbo].[GetTCLabel]​
(4, CName, CDept, CSalary)) TC
FROM dbo.Dc
UNION
SEL
ECT name, dbo.[GetCLabel](CName) CName, Department,
dbo.[GetCLabel](CDept) CDept, Salary,
dbo.[GetCLabel](CSalary) CSalary, dbo.
[GetCLabel]([dbo].[GetTCLabel](4,
CName, CDept, CSalary)) TC
FROM dbo.Ds
UNION
SEL
ECT name, dbo.[GetCLabel](CName) CName, Department,
dbo.[GetCLabel](CDept) CDept, Salary,
dbo.[GetCLabel](CSalary) CSalary, dbo.
[GetCLabel]([dbo].[GetTCLabel](4,
CName, CDept, CSalary)) TC
FROM dbo.Dts
GO
CREATE VIEW [dbo].[VwEmployee-Encryption]
 T he S o ur c e C o d e 18 5

AS
SEL ECT CONVERT(nvarchar(MAX), DecryptByKey(dbo.
[Employee-Encryption].Name)) AS Name,
CONVERT(nvarchar(MAX), DecryptByKey(dbo.[Employee-
Encryption].Department)) AS Department,
CONVERT(nvarchar(MAX), DecryptByKey(dbo.
[Employee-Encryption].Salary)) AS
Salary, dbo.[Employee-Encryption].TC
FROM dbo.[Employee-Encryption] INNER JOIN
dbo.vwVisibleLabels ON dbo.[Employee-
Encryption].TC = dbo.vwVisibleLabels.ID

9.4  Source Code of the Microsoft Visual Studio C#

The source code of the Microsoft visual studio C# will be divided into
five parts:
• Create classes that help the window forms in performing the
database operations and parsing the SQL query statement.
• Create login form to authenticate the user and to identify his
security classification level.
• Create queries form to generate multiple query forms inside
at the same session.
• Create query form to be used in writing the SQL query state-
ment for each model from the multilevel database security
models.
• Create concurrency control form to be used in simulating
the concurrency control in the multilevel database security
models.

9.4.1  Source Code of the Classes

• DBOperations class

using System;
using System.Data;
using System.Data.SqlClient;
///<summary>
///Summary description for Class1
///</summary>
18 6 Securit y f o r Rel ati o n a l Data ba se s

namespace GlobalClasses
{
public class DBOperations
{
public DBOperations()
{
}
//
//Date:6/4/2008
//purpose:to Check user name and password of user
public static void SqlConn(string Server, string
User, string Pass) {globals.ServerConnStr
= “Data Source = “ + Server + “;Initial
Catalog = MLSDB;User Id = “ + User +
“;Password = “ + Pass + “;”;}
//
//Date:25/10/2008
//p
urpose:to get data from database by excuting SQL
satment.
public static DataSet GetData(string SqlStr)
{
DataSet ds = new DataSet();
string SqlConnStr = globals.ServerConnStr;
Sql
Connection SqlConn = new
SqlConnection(SqlConnStr);
SqlConn.Open();
SqlCommand SqlCmd = new SqlCommand(SqlStr,
SqlConn);
SqlDataAdapter Adpt = new SqlDataAdapter(SqlCmd);
Adpt.Fill(ds);
SqlConn.Close();
return ds;
}
//
//Date:21/7/2009
//p
urpose:to fill data table in dataset by excuting
SQL statement.
public static void FillDataSet(ref DataSet DS,
string DT, string SqlStr)
{
string SqlConnStr = globals.ServerConnStr;
SqlConnection SqlConn = new
SqlConnection(SqlConnStr);
SqlConn.Open();
 T he S o ur c e C o d e 18 7

SqlCommand SqlCmd = new SqlCommand(SqlStr,

SqlConn);
SqlDataAdapter Adpt = new SqlDataAdapter(SqlCmd);
Adpt.Fill(DS, DT);
SqlConn.Close();
}
public static string DateFormate(string Date)
{
string [] dateMDY = Date.Split(‘/’);
string DateDMY = dateMDY[1] + ‘/’ + dateMDY[0]
+ ‘/’ + dateMDY[2];
return DateDMY;
}
//
//Date:7/7/2009
//purpose:to convert from string to nullable int.
public static int? StringToNullableInt32(string s)
{int i;
if (Int32.TryParse(s, out i)) return i;
return null;
}
//
//Date:25/10/2008
//p
urpose:to Set data from database by excuting SQL
satment.
public static void SetData(string SqlStr)
{
string SqlConnStr = globals.ServerConnStr;
SqlConnection SqlConn = new
SqlConnection(SqlConnStr);
SqlConn.Open();
SqlCommand SqlCmd = new SqlCommand(SqlStr,
SqlConn);
SqlCmd.ExecuteNonQuery();
SqlConn.Close();
}
}
}

• Globals class

using System;
using System.Configuration ;
using System.Collections ;
18 8 Securit y f o r Rel ati o n a l Data ba se s

using System.IO;
using GlobalClasses;
///Summary description for Class1
///</summary>
namespace GlobalClasses
{
public class globals
{
public static string ServerName;
public static string Password;
public static string UserName;
public static string ServerConnStr;
public static string UserLabel;
public static int UserLabelID;
public static string Scrub(string text)
{return text.Replace(“&nbsp;”, “”);}
pub
lic static string[] KeyWords = new
string[8];//”select”, “insert”,
“update”,”Delete”, “Where”, “from”, “Set”,
“Values”
public enum SqlStatment
{
select,
Insert,
update,
Delete
}
}
}

• MLSDB class

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Collections;
namespace GlobalClasses
{
public class MLSDB
{
public static string DMLSTR(String SQLSTR)
{
 T he S o ur c e C o d e 18 9

string DML = “”;

if (SQLSTR.ToUpper().Contains(“SELECT”))
{
if (SQLSTR.ToUpper().Contains(“WHERE”))
{
DML= SQLSTR.Substring(SQLSTR.ToUpper().
IndexOf(“FROM”) + 4, SQLSTR.
ToUpper().IndexOf(“WHERE”) - (SQLSTR.
ToUpper().IndexOf(“FROM”) + 4));
}
else
{
DML= SQLSTR.Substring(SQLSTR.
ToUpper().IndexOf(“FROM”) + 4);
}
}
else if (SQLSTR.ToUpper().Contains(“UPDATE”))
{
DML= SQLSTR.Substring(SQLSTR.ToUpper().
IndexOf(“UPDATE”) + 6, SQLSTR.
ToUpper().IndexOf(“SET”) - (SQLSTR.
ToUpper().IndexOf(“UPDATE”) + 6));
}
else if (SQLSTR.ToUpper().Contains(“INSERT”))
{
DML= SQLSTR.Substring(SQLSTR.
ToUpper().IndexOf(“INSERT”) + 6,
SQLSTR.ToUpper().IndexOf(“VALUES”)
- (SQLSTR.ToUpper().
IndexOf(“INSERT”) + 6));
}
else if
(SQLSTR.ToUpper().Contains(“UPLEVEL”))
{
DML= SQLSTR.Substring(SQLSTR.ToUpper().
IndexOf(“UPLEVEL”) + 7, SQLSTR.
ToUpper().IndexOf(“GET”) - (SQLSTR.
ToUpper().IndexOf(“UPLEVEL”) + 7));
}
else if (SQLSTR.ToUpper().Contains(“VERIFY”))
{
if(SQLSTR.ToUpper().Contains(“TRUE”))
{
DML= SQLSTR.Substring(SQLSTR.ToUpper().
IndexOf(“TRUE”) + 4, SQLSTR.
19 0 Securit y f o r Rel ati o n a l Data ba se s

ToUpper().IndexOf(“WHERE”) - (SQLSTR.
ToUpper().IndexOf(“TRUE”) + 4));
}
else if(SQLSTR.ToUpper().
Contains(“FALSE”))
{
DML= SQLSTR.Substring(SQLSTR.ToUpper().
IndexOf(“FALSE”) + 5, SQLSTR.
ToUpper().IndexOf(“WHERE”) - (SQLSTR.
ToUpper().IndexOf(“FALSE”) + 5));
}
}
else if (SQLSTR.ToUpper().Contains(“DELETE”))
{
if (SQLSTR.ToUpper().Contains(“WHERE”))
{
DML= SQLSTR.Substring(SQLSTR.ToUpper().
IndexOf(“FROM”) + 4, SQLSTR.
ToUpper().IndexOf(“WHERE”) - (SQLSTR.
ToUpper().IndexOf(“FROM”) + 4));
}
else
{
DML= SQLSTR.Substring(SQLSTR.
ToUpper().IndexOf(“FROM”) + 4);
}
}
return DML;
}
pub
lic static string AttributeSTR(String
SQLSTR)
{
string DML = “”;
if (SQLSTR.ToUpper().Contains(“SELECT”))
{
DML= SQLSTR.Substring(SQLSTR.
ToUpper().IndexOf(“SELECT”) + 6,
SQLSTR.ToUpper().IndexOf(“FROM”)
- (SQLSTR.ToUpper().
IndexOf(“SELECT”) + 6));
}
else if (SQLSTR.ToUpper().Contains(“UPDATE”))
{
if (SQLSTR.ToUpper().
Contains(“WHERE”))
 T he S o ur c e C o d e 191

{
DML= SQLSTR.Substring(SQLSTR.ToUpper().
IndexOf(“SET”) + 3, SQLSTR.ToUpper().
IndexOf(“WHERE”) - (SQLSTR.ToUpper().
IndexOf(“SET”) + 3));
}
else
{
DML= SQLSTR.Substring(SQLSTR.
ToUpper().IndexOf(“SET”) + 3);
}
}
els
e if (SQLSTR.ToUpper().
Contains(“UPLEVEL”))
{
if (SQLSTR.ToUpper().Contains(“WHERE”))
{
DML= SQLSTR.Substring(SQLSTR.ToUpper().
IndexOf(“GET”) + 3, SQLSTR.ToUpper().
IndexOf(“WHERE”) - (SQLSTR.ToUpper().
IndexOf(“GET”) + 3));
}
else
{
DML= SQLSTR.Substring(SQLSTR.
ToUpper().IndexOf(“SET”) + 3);
}
}
else if (SQLSTR.ToUpper().Contains(“VERIFY”))
{
if (SQLSTR.ToUpper().Contains(“TRUE”))
{
DML = “TRUE”;
}
else
{
DML = “FALSE”;
}
}
else if (SQLSTR.ToUpper().Contains(“INSERT”))
{
DML= SQLSTR.Substring(SQLSTR.
ToUpper().IndexOf(“VALUES”) + 6);
}
else if (SQLSTR.ToUpper().Contains(“DELETE”))
19 2 Securit y f o r Rel ati o n a l Data ba se s

{
if (SQLSTR.ToUpper().Contains(“WHERE”))
{
DML= SQLSTR.Substring(SQLSTR.
ToUpper().IndexOf(“WHERE”) + 5);
}
else
{
DML = “”;
}
}
return DML;
}
public static string PredicateSTR(String SQLSTR)
{
string DML = “”;
if (SQLSTR.ToUpper().Contains(“WHERE”))
{
DML= SQLSTR.Substring(SQLSTR.
ToUpper().IndexOf(“WHERE”) + 5);
}
else
{
DML = “”;
}
return DML;
}
public static int GetUserLabelID()
{
int UserLabel = 0;
str
ing SqlStr = “select [dbo].
GetLabelID([dbo].[GetUserLabel]()) “;
Use
rLabel = int.Parse(DBOperations.
GetData(SqlStr).Tables 0].Rows[0][0].
ToString());
return UserLabel;
}
public static string GetUserLabel()
{
string UserLabel = “”;
string SqlStr = “select [dbo].[GetUserLabel]() “;
Use
rLabel = DBOperations.GetData(SqlStr).
Tables 0].Rows[0][0].ToString();
return UserLabel;
}
 T he S o ur c e C o d e 19 3

public static int GetLabelID(string UserLabel)

{
int UserLabelID = 0;
str
ing SqlStr = “select [dbo].GetLabelID(‘” +
UserLabel + “’) “;
Use
rLabelID = int.Parse(DBOperations.
GetData(SqlStr).Tables 0].Rows[0][0].ToString());
return UserLabelID;
}
public static string GetBCLabel(int UserLabelID)
{
string UserLabel = “”;
string UChar = “”;
string CChar = “”;
string SChar = “”;
string TSChar = “”;
UChar = (UserLabelID% 4).ToString();
UserLabelID = UserLabelID/4;
CChar = (UserLabelID% 4).ToString();
UserLabelID = UserLabelID/4;
SChar = (UserLabelID% 4).ToString();
UserLabelID = UserLabelID/4;
TSChar = (UserLabelID% 4).ToString();
if (UChar = = “1”)
{
UserLabel = UserLabel + “-U”;
}
else if (UChar = = “2”)
{
UserLabel = UserLabel + “U” ;
}
if (CChar = = “1”)
{
UserLabel = UserLabel + “-C” ;
}
else if (CChar = = “2”)
{
UserLabel = UserLabel + “C”;
}
if (SChar = = “1”)
{
UserLabel = UserLabel + “-S”;
}
else if (SChar = = “2”)
19 4 Securit y f o r Rel ati o n a l Data ba se s

{
UserLabel = UserLabel + “S”;
}
if (TSChar = = “1”)
{
UserLabel = UserLabel + “-T”;
}
else if (TSChar = = “2”)
{
UserLabel = UserLabel + “T”;
}
return UserLabel;
}
pub
lic static int GetBCLabelNumeric(string
UserLabel)
{
int UserLabelID = 0 ;
UserLabel = BreakBCLabel(UserLabel);
Use
rLabelID = int.Parse(UserLabel.Substring​
(0, 1)) + (int.Parse(UserLabel.Substring​
(1, 1)) * 4) + (int.Parse(UserLabel.
Substring(2, 1)) * 16) + (int.
Parse(UserLabel.​Substring(3, 1)) * 64);
return UserLabelID;
}
public static string GetBCUserView(string Label)
{
string labelView = “”;
int NumericLabel = 0;
Label = BreakBCLabel(Label);
int UserLabelID = globals.UserLabelID ;
for (int i = 0; i < UserLabelID; i++)
{
Num
ericLabel = NumericLabel +
(int.Parse(Label.Substring(i, 1)) *
Convert.ToInt32 (Math.Pow(4, i)));
}
labelView = GetBCLabel(NumericLabel);
return labelView;
}
pub
lic static string BreakBCLabel(string
UserLabel)
{
string UserLabelID = “0”;
string Unumric = “0”;
 T he S o ur c e C o d e 19 5

string Cnumric = “0”;

string Snumric = “0”;
string TSnumric = “0”;
if(UserLabel.Contains(‘U’))
{
if (UserLabel.IndexOf(‘U’) = = 0)
{
Unumric = “2”;
}
else
{
if (UserLabel.Substring(UserLabel.
IndexOf(‘U’) - 1, 1) = = “-”)
{
Unumric = “1”;
}
else
{
Unumric = “2”;
}
}
}
if (UserLabel.Contains(‘C’))
{
if (UserLabel.IndexOf(‘C’) = = 0)
{
Cnumric = “2”;
}
else
{
if (UserLabel.Substring(UserLabel.
IndexOf(‘C’) - 1, 1) = = “-”)
{
Cnumric = “1”;
}
else
{
Cnumric = “2”;
}
}
}
if (UserLabel.Contains(‘S’))
{
if (UserLabel.IndexOf(‘S’) = = 0)
19 6 Securit y f o r Rel ati o n a l Data ba se s

{
Snumric = “2”;
}
else
{
if (UserLabel.Substring(UserLabel.
IndexOf(‘S’) - 1, 1) = = “-”)
{
Snumric = “1”;
}
else
{
Snumric = “2”;
}
}
}
if (UserLabel.Contains(‘T’))
{
if (UserLabel.IndexOf(‘T’) = = 0)
{
TSnumric = “2”;
}
else
{
if (UserLabel.Substring​
(UserLabel.IndexOf(‘T’) - 1, 1)
= = “-”)
{
TSnumric = “1”;
}
else
{
TSnumric = “2”;
}
}
}
Use
rLabelID = Unumric + Cnumric + Snumric +
TSnumric;
return UserLabelID;
}
pub
lic static string GetBCprimarylevel​
(int NumericLabel)
{
string Label = GetBCLabel(NumericLabel);
 T he S o ur c e C o d e 19 7

return Label.Substring(0, 1);

}
public static string GetBCSecondarylevel​
(int NumericLabel)
{
string Label = GetBCLabel(NumericLabel);
return Label.Remove(Label.IndexOf(GetBCprimar
ylevel(NumericLabel)), 1);
}
pub
lic static string GetBCUserbelief​
(string Label)
{
int NumericLabel = GetBCLabelNumeric(Label);
int belief = 0;
string retvalue = “”;
int UserLabelID = globals.UserLabelID;
string UserLabel = globals.UserLabel;
for (int i = 0; i < UserLabelID; i++)
{
belief = NumericLabel% 4;
NumericLabel = NumericLabel/4;
}
if (belief = = 1)
{
retvalue = “-” + UserLabel;
}
else if (belief = = 2)
{
retvalue = UserLabel;
}
return retvalue;
}
public static int UnverifyBCUserbelief​
(int NumericLabel)
{
string Label = GetBCLabel(NumericLabel);
string UserLabel = globals.UserLabel;
Label = Label.Remove(Label.
IndexOf(UserLabel), 1); ;
return GetBCLabelNumeric(Label);
}
public static int VerifyBCUserbelief​
(int NumericLabel,bool belief)
{
string Label = GetBCLabel(NumericLabel);
19 8 Securit y f o r Rel ati o n a l Data ba se s

string UserLabel = globals.UserLabel;

int UserLabelID = globals.UserLabelID;
if (belief)
{
Lab
el = Label.Insert(UserLabelID - 1,
globals.UserLabel);
}
else
{
Lab
el = Label.Insert(UserLabelID
- 1,”-”+ globals.UserLabel);
}
return GetBCLabelNumeric(Label);
}
public static ArrayList GetAttribute(string Str)
{
//ArrayList ReturnARR = new ArrayList();
ArrayList ARR = new ArrayList();
string Attribute = “”;
string Values = “”;
if (Str.Contains(‘,’))
{
ARR.AddRange(Str.Trim().Split(‘,’));
}
else
ARR.Add(Str.Trim());
return ARR;
}
pub
lic static ArrayList GetInsertValue​
(string Str)
{
ArrayList ARR = new ArrayList();
Str = Str.Remove(Str.IndexOf(‘(‘), 1);
Str = Str.Remove(Str.IndexOf(‘)’), 1);
if (Str.Contains(‘,’))
{
ARR.AddRange(Str.Trim().Split(‘,’));
}
return ARR;
}
}
}
 T he S o ur c e C o d e 19 9

9.4.2  Source Code of the Login Form

namespace MLS
{
partial class Log_In
{
///<summary>
///Required designer variable.
///</summary>
private System.ComponentModel.IContainer
components = null;
///<summary>
///Clean up any resources being used.
///</summary>
///
<param name = “disposing”>true if managed resources
should be disposed; otherwise, false.</param>
pro
tected override void Dispose(bool
disposing)
{
if (disposing && (components ! = null))
{
components.Dispose();
}
base.Dispose(disposing);
}
#region Windows Form Designer generated code
///<summary>
///Required method for Designer support - do not modify
///the contents of this method with the code editor.
///</summary>
private void InitializeComponent()
{
this.label1 = new System.Windows.Forms.Label();
thi
s.TxtServer = new System.Windows.Forms.
TextBox();
this.TxtUser = new System.Windows.Forms.TextBox();
thi
s.label2 = new System.Windows.Forms.
Label();
thi
s.TxtPassword = new System.Windows.Forms.
TextBox();
thi
s.label3 = new System.Windows.Forms.
Label();
this.button1 = new System.Windows.Forms.Button();
this.button2 = new System.Windows.Forms.Button();
200 Securit y f o r Rel ati o n a l Data ba se s

this.SuspendLayout();
//
//label1
//
this.label1.AutoSize = true;
thi
s.label1.Location = new System.Drawing.
Point(26, 28);
this.label1.Name = “label1”;
this.label1.Size = new System.Drawing.Size(69, 13);
this.label1.TabIndex = 0;
this.label1.Text = “Server Name”;
thi
s.label1.Click + = new System.
EventHandler(this.label1_Click);
//
//TxtServer
//
thi
s.TxtServer.Location = new System.Drawing.
Point(101, 25);
this.TxtServer.Name = “TxtServer”;
thi
s.TxtServer.Size = new System.Drawing.
Size(154, 20);
this.TxtServer.TabIndex = 1;
//
//TxtUser
//
thi
s.TxtUser.Location = new System.Drawing.
Point(101, 50);
this.TxtUser.Name = “TxtUser”;
thi
s.TxtUser.Size = new System.Drawing.
Size(154, 20);
this.TxtUser.TabIndex = 3;
//
//label2
//
this.label2.AutoSize = true;
thi
s.label2.Location = new System.Drawing.
Point(38, 53);
this.label2.Name = “label2”;
thi
s.label2.Size = new System.Drawing.
Size(59, 13);
this.label2.TabIndex = 2;
this.label2.Text = “User Name”;
//
//TxtPassword
//
 T he S o ur c e C o d e 2 01

thi
s.TxtPassword.Location = new System.
Drawing.Point(101, 75);
this.TxtPassword.Name = “TxtPassword”;
this.TxtPassword.PasswordChar = ‘*’;
thi
s.TxtPassword.Size = new System.Drawing.
Size(154, 20);
this.TxtPassword.TabIndex = 5;
//
//label3
//
this.label3.AutoSize = true;
thi
s.label3.Location = new System.Drawing.
Point(38, 78);
this.label3.Name = “label3”;
thi
s.label3.Size = new System.Drawing.
Size(53, 13);
this.label3.TabIndex = 4;
this.label3.Text = “Password”;
//
//button1
//
thi
s.button1.Location = new System.Drawing.
Point(101, 118);
this.button1.Name = “button1”;
thi
s.button1.Size = new System.Drawing.
Size(75, 23);
this.button1.TabIndex = 6;
this.button1.Text = “Connect”;
this.button1.UseVisualStyleBackColor = true;
thi
s.button1.Click + = new System.
EventHandler(this.button1_Click);
//
//button2
//
thi
s.button2.Location = new System.Drawing.
Point(180, 118);
this.button2.Name = “button2”;
thi
s.button2.Size = new System.Drawing.
Size(75, 23);
this.button2.TabIndex = 7;
this.button2.Text = “button2”;
this.button2.UseVisualStyleBackColor = true;
this.button2.Visible = false;
thi
s.button2.Click + = new System.
EventHandler(this.button2_Click);
202 Securit y f o r Rel ati o n a l Data ba se s

//
//Log_In
//
this.AcceptButton = this.button1;
thi
s.AutoScaleDimensions = new System.Drawing.
SizeF(6F, 13F);
thi
s.AutoScaleMode = System.Windows.Forms.
AutoScaleMode.Font;
thi
s.ClientSize = new System.Drawing.
Size(292, 153);
this.Controls.Add(this.button2);
this.Controls.Add(this.button1);
this.Controls.Add(this.TxtPassword);
this.Controls.Add(this.label3);
this.Controls.Add(this.TxtUser);
this.Controls.Add(this.label2);
this.Controls.Add(this.TxtServer);
this.Controls.Add(this.label1);
thi
s.FormBorderStyle = System.Windows.Forms.
FormBorderStyle.Fixed3D;
this.MaximizeBox = false;
this.MinimizeBox = false;
this.Name = “Log_In”;
thi
s.StartPosition = System.Windows.Forms.
FormStartPosition.CenterScreen;
this.Text = “Log In”;
this.ResumeLayout(false);
this.PerformLayout();
}
#endregion
private System.Windows.Forms.Label label1;
private System.Windows.Forms.TextBox TxtServer;
private System.Windows.Forms.TextBox TxtUser;
private System.Windows.Forms.Label label2;
private System.Windows.Forms.TextBox TxtPassword;
private System.Windows.Forms.Label label3;
private System.Windows.Forms.Button button1;
private System.Windows.Forms.Button button2;
}
}
using System;
using System.Collections.Generic;
using System.ComponentModel;
 T he S o ur c e C o d e 203

using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.Data.SqlClient;
namespace MLS
{
public partial class Log_In : Form
{
public Log_In()
{
InitializeComponent();
}
pri
vate void label1_Click(object sender,
EventArgs e)
{
}
pri
vate void button1_Click(object sender,
EventArgs e)
{
Glo
balClasses.globals.ServerName = TxtServer.
Text;
GlobalClasses.globals.UserName = TxtUser.Text;
Glo
balClasses.globals.Password = TxtPassword.
Text;
GlobalClasses.DBOperations.SqlConn(TxtServer.
Text, TxtUser.Text, TxtPassword.Text);
try
{
SqlConnection SqlConn = new
SqlConnection(GlobalClasses.
globals.ServerConnStr);
SqlConn.Open();
SqlConn.Close();
Query FRM = new Query();
FRM.Show();
GlobalClasses.globals.UserLabelID
= GlobalClasses.MLSDB.
GetUserLabelID();
GlobalClasses.globals.UserLabel
= GlobalClasses.MLSDB.
GetUserLabel();
204 Securit y f o r Rel ati o n a l Data ba se s

this.Hide();
}
catch (SqlException sqlEX)
{
MessageBox.Show(sqlEX.Message);
}
}
pri
vate void button2_Click(object sender,
EventArgs e)
{
DataSet ds = new DataSet();
str
ing SqlConnStr = “Data Source =.;Initial
Catalog = test;Integrated Security = SSPI;”;
Sql
Connection SqlConn = new
SqlConnection(SqlConnStr);
SqlConn.Open();
string SqlStr = “select * from Table 1”;
Sql
Command SqlCmd = new SqlCommand(SqlStr,
SqlConn);
SqlDataAdapter Adpt = new SqlDataAdapter(SqlCmd);
Adpt.Fill(ds);
SqlConn.Close();
for (int i = 1; i < = 5; i++)
{
foreach (DataRow DBrow in
ds.Tables 0].Rows)
{
str
ing SqlConnStr1 = “Data Source =.;
Initial Catalog = “ + DBrow[0].
ToString() + “;Integrated Security
= SSPI;”;
SqlConnection mSqlConnection1 = new
SqlConnection(SqlConnStr1);
//the primary key column resides at
index 4
string str1 = “insert into [“ +
DBrow[1].ToString() + “] select *
from
[“ + DBrow[1].ToString() + “]”;
mSqlConnection1.Open();
SqlCommand mSqlCommand1 = new
SqlCommand(str1,
mSqlConnection1);
mSqlCommand1.CommandTimeout = 200;
mSqlCommand1.ExecuteNonQuery();
 T he S o ur c e C o d e 205

mSqlConnection1.Close();
}
}
}
pub
lic void dropprimaryKey(string tableName,
string cnnString)
{
SqlDataReader mReader;
Sql
Connection mSqlConnection = new
SqlConnection();
SqlCommand mSqlCommand = new SqlCommand();
string cnString = cnnString;
mSqlConnection = new SqlConnection(cnString);
mSqlConnection.Open();
//s
p_pkeys is SQL Server default stored
procedure
//you pass it only table Name, it will return
//primary key column
mSq
lCommand = new SqlCommand(“sp_pkeys”,
mSqlConnection);
mSq
lCommand.CommandType = CommandType.
StoredProcedure;
mSqlCommand.Parameters.Add(“@table_name”,
SqlDbType.NVarChar).Value = tableName;
mReader = mSqlCommand.ExecuteReader();
while (mReader.Read())
{
try
{
Sql
Connection mSqlConnection1 = new
SqlConnection(cnnString);
//t
he primary key column resides at
index 4
str
ing str1 = “ALTER TABLE [“ +
tableName + “] DROP CONSTRAINT
[“ + mReader[5].ToString() + “]”;
mSqlConnection1.Open();
Sql
Command mSqlCommand1 = new
SqlCommand(str1, mSqlConnection1);
mSqlCommand1.ExecuteNonQuery();
mSqlConnection1.Close();
}
206 Securit y f o r Rel ati o n a l Data ba se s

catch {}
}
}
}
}

9.4.3  Source Code of the Queries Form

namespace MLS
{
partial class Query
{
///<summary>
///Required designer variable.
///</summary>
private System.ComponentModel.IContainer
components = null;
///<summary>
///Clean up any resources being used.
///</summary>
///
<param name = “disposing”>true if managed resources
should be disposed; otherwise, false.</param>
pro
tected override void Dispose(bool
disposing)
{
if (disposing && (components ! = null))
{
components.Dispose();
}
base.Dispose(disposing);
}
#region Windows Form Designer generated code
///<summary>
///Required method for Designer support - do not modify
///the contents of this method with the code editor.
///</summary>
private void InitializeComponent()
{
thi
s.components = new System.ComponentModel.
Container();
System.ComponentModel.ComponentResourceManager
resources = new System.ComponentModel.Compo
nentResourceManager(typeof(Query));
 T he S o ur c e C o d e 207

thi
s.menuStrip = new System.Windows.Forms.
MenuStrip();
thi
s.fileMenu = new System.Windows.Forms.
ToolStripMenuItem();
thi
s.newToolStripMenuItem = new System.
Windows.Forms.ToolStripMenuItem();
thi
s.openToolStripMenuItem = new System.
Windows.Forms.ToolStripMenuItem();
thi
s.toolStripSeparator3 = new System.Windows.
Forms.ToolStripSeparator();
thi
s.saveToolStripMenuItem = new System.
Windows.Forms.ToolStripMenuItem();
thi
s.saveAsToolStripMenuItem = new System.
Windows.Forms.ToolStripMenuItem();
thi
s.toolStripSeparator4 = new System.Windows.
Forms.ToolStripSeparator();
thi
s.printToolStripMenuItem = new System.
Windows.Forms.ToolStripMenuItem();
thi
s.printPreviewToolStripMenuItem = new
System.Windows.Forms.ToolStripMenuItem();
thi
s.printSetupToolStripMenuItem = new System.
Windows.Forms.ToolStripMenuItem();
thi
s.toolStripSeparator5 = new System.Windows.
Forms.ToolStripSeparator();
thi
s.exitToolStripMenuItem = new System.
Windows.Forms.ToolStripMenuItem();
thi
s.editMenu = new System.Windows.Forms.
ToolStripMenuItem();
thi
s.undoToolStripMenuItem = new System.
Windows.Forms.ToolStripMenuItem();
thi
s.redoToolStripMenuItem = new System.
Windows.Forms.ToolStripMenuItem();
thi
s.toolStripSeparator6 = new System.Windows.
Forms.ToolStripSeparator();
thi
s.cutToolStripMenuItem = new System.
Windows.Forms.ToolStripMenuItem();
thi
s.copyToolStripMenuItem = new System.
Windows.Forms.ToolStripMenuItem();
thi
s.pasteToolStripMenuItem = new System.
Windows.Forms.ToolStripMenuItem();
thi
s.toolStripSeparator7 = new System.Windows.
Forms.ToolStripSeparator();
thi
s.selectAllToolStripMenuItem = new System.
Windows.Forms.ToolStripMenuItem();
208 Securit y f o r Rel ati o n a l Data ba se s

thi
s.viewMenu = new System.Windows.Forms.
ToolStripMenuItem();
thi
s.toolBarToolStripMenuItem = new System.
Windows.Forms.ToolStripMenuItem();
thi
s.statusBarToolStripMenuItem = new System.
Windows.Forms.ToolStripMenuItem();
thi
s.toolsMenu = new System.Windows.Forms.
ToolStripMenuItem();
thi
s.optionsToolStripMenuItem = new System.
Windows.Forms.ToolStripMenuItem();
thi
s.windowsMenu = new System.Windows.Forms.
ToolStripMenuItem();
thi
s.newWindowToolStripMenuItem = new System.
Windows.Forms.ToolStripMenuItem();
thi
s.cascadeToolStripMenuItem = new System.
Windows.Forms.ToolStripMenuItem();
thi
s.tileVerticalToolStripMenuItem = new
System.Windows.Forms.ToolStripMenuItem();
thi
s.tileHorizontalToolStripMenuItem = new
System.Windows.Forms.ToolStripMenuItem();
thi
s.closeAllToolStripMenuItem = new System.
Windows.Forms.ToolStripMenuItem();
thi
s.arrangeIconsToolStripMenuItem = new
System.Windows.Forms.ToolStripMenuItem();
thi
s.helpMenu = new System.Windows.Forms.
ToolStripMenuItem();
thi
s.contentsToolStripMenuItem = new System.
Windows.Forms.ToolStripMenuItem();
thi
s.indexToolStripMenuItem = new System.
Windows.Forms.ToolStripMenuItem();
thi
s.searchToolStripMenuItem = new System.
Windows.Forms.ToolStripMenuItem();
thi
s.toolStripSeparator8 = new System.Windows.
Forms.ToolStripSeparator();
thi
s.aboutToolStripMenuItem = new System.
Windows.Forms.ToolStripMenuItem();
thi
s.statusStrip = new System.Windows.Forms.
StatusStrip();
thi
s.toolStripStatusLabel = new System.
Windows.Forms.ToolStripStatusLabel();
thi
s.toolTip = new System.Windows.Forms.
ToolTip(this.components);
thi
s.newToolStripButton = new System.Windows.
Forms.ToolStripButton();
 T he S o ur c e C o d e 209

thi
s.openToolStripButton = new System.Windows.
Forms.ToolStripButton();
thi
s.saveToolStripButton = new System.Windows.
Forms.ToolStripButton();
thi
s.toolStripSeparator1 = new System.Windows.
Forms.ToolStripSeparator();
thi
s.printToolStripButton = new System.
Windows.Forms.ToolStripButton();
thi
s.printPreviewToolStripButton = new System.
Windows.Forms.ToolStripButton();
thi
s.toolStripSeparator2 = new System.Windows.
Forms.ToolStripSeparator();
thi
s.helpToolStripButton = new System.Windows.
Forms.ToolStripButton();
thi
s.toolStrip = new System.Windows.Forms.
ToolStrip();
this.menuStrip.SuspendLayout();
this.statusStrip.SuspendLayout();
this.toolStrip.SuspendLayout();
this.SuspendLayout();
//
//menuStrip
//
this.menuStrip.Items.AddRange(new System.
Windows.Forms.ToolStripItem[] {
this.fileMenu,
this.editMenu,
this.viewMenu,
this.toolsMenu,
this.windowsMenu,
this.helpMenu});
thi
s.menuStrip.Location = new System.Drawing.
Point(0, 0);
thi
s.menuStrip.MdiWindowListItem = this.
windowsMenu;
this.menuStrip.Name = “menuStrip”;
thi
s.menuStrip.Size = new System.Drawing.
Size(632, 24);
this.menuStrip.TabIndex = 0;
this.menuStrip.Text = “MenuStrip”;
this.menuStrip.Visible = false;
//
//fileMenu
//
210 Securit y f o r Rel ati o n a l Data ba se s

this.fileMenu.DropDownItems.AddRange(new
System.Windows.Forms.ToolStripItem[] {
this.newToolStripMenuItem,
this.openToolStripMenuItem,
this.toolStripSeparator3,
this.saveToolStripMenuItem,
this.saveAsToolStripMenuItem,
this.toolStripSeparator4,
this.printToolStripMenuItem,
this.printPreviewToolStripMenuItem,
this.printSetupToolStripMenuItem,
this.toolStripSeparator5,
this.exitToolStripMenuItem});
thi
s.fileMenu.ImageTransparentColor = System.
Drawing.SystemColors.ActiveBorder;
this.fileMenu.Name = “fileMenu”;
thi
s.fileMenu.Size = new System.Drawing.
Size(37, 20);
this.fileMenu.Text = “&File”;
//
//newToolStripMenuItem
//
thi
s.newToolStripMenuItem.Image = ((System.
Drawing.Image)(resources.
GetObject(“newToolStripMenuItem.Image”)));
this.newToolStripMenuItem.
ImageTransparentColor = System.Drawing.
Color.Black;
this.newToolStripMenuItem.Name =
“newToolStripMenuItem”;
this.newToolStripMenuItem.ShortcutKeys =
((System.Windows.Forms.Keys)((System.
Windows.Forms.Keys.Control | System.
Windows.Forms.Keys.N)));
thi
s.newToolStripMenuItem.Size = new System.
Drawing.Size(146, 22);
this.newToolStripMenuItem.Text = “&New”;
thi
s.newToolStripMenuItem.Click + = new
System.EventHandler(this.ShowNewForm);
//
//openToolStripMenuItem
//
thi
s.openToolStripMenuItem.Image = ((System.
Drawing.Image)(resources.GetObject(“openToo
lStripMenuItem.Image”)));
 T he S o ur c e C o d e 211

this.openToolStripMenuItem.
ImageTransparentColor = System.Drawing.
Color.Black;
this.openToolStripMenuItem.Name =
“openToolStripMenuItem”;
this.openToolStripMenuItem.ShortcutKeys =
((System.Windows.Forms.Keys)((System.
Windows.Forms.Keys.Control | System.
Windows.Forms.Keys.O)));
thi
s.openToolStripMenuItem.Size = new System.
Drawing.Size(146, 22);
this.openToolStripMenuItem.Text = “&Open”;
thi
s.openToolStripMenuItem.Click + = new
System.EventHandler(this.OpenFile);
//
//toolStripSeparator3
//
this.toolStripSeparator3.Name =
“toolStripSeparator3”;
thi
s.toolStripSeparator3.Size = new System.
Drawing.Size(143, 6);
//
//saveToolStripMenuItem
//
thi
s.saveToolStripMenuItem.Image = ((System.
Drawing.Image)(resources.GetObject(“saveToo
lStripMenuItem.Image”)));
this.saveToolStripMenuItem.
ImageTransparentColor = System.Drawing.
Color.Black;
this.saveToolStripMenuItem.Name =
“saveToolStripMenuItem”;
this.saveToolStripMenuItem.ShortcutKeys =
((System.Windows.Forms.Keys)((System.
Windows.Forms.Keys.Control | System.
Windows.Forms.Keys.S)));
thi
s.saveToolStripMenuItem.Size = new System.
Drawing.Size(146, 22);
this.saveToolStripMenuItem.Text = “&Save”;
//
//saveAsToolStripMenuItem
//
this.saveAsToolStripMenuItem.Name =
“saveAsToolStripMenuItem”;
212 Securit y f o r Rel ati o n a l Data ba se s

thi
s.saveAsToolStripMenuItem.Size = new
System.Drawing.Size(146, 22);
thi
s.saveAsToolStripMenuItem.Text = “Save
&As”;
thi
s.saveAsToolStripMenuItem.Click + = new
System.EventHandler(this.
SaveAsToolStripMenuItem_Click);
//
//toolStripSeparator4
//
this.toolStripSeparator4.Name =
“toolStripSeparator4”;
thi
s.toolStripSeparator4.Size = new System.
Drawing.Size(143, 6);
//
//printToolStripMenuItem
//
thi
s.printToolStripMenuItem.Image = ((System.
Drawing.Image)(resources.GetObject(“printTo
olStripMenuItem.Image”)));
this.printToolStripMenuItem.
ImageTransparentColor = System.Drawing.
Color.Black;
this.printToolStripMenuItem.Name =
“printToolStripMenuItem”;
this.printToolStripMenuItem.ShortcutKeys =
((System.Windows.Forms.Keys)((System.
Windows.Forms.Keys.Control |
System.Windows.Forms.Keys.P)));
thi
s.printToolStripMenuItem.Size = new System.
Drawing.Size(146, 22);
this.printToolStripMenuItem.Text = “&Print”;
//
//printPreviewToolStripMenuItem
//
this.printPreviewToolStripMenuItem.Image =
((System.Drawing.Image)(resources.GetObject
(“printPreviewToolStripMenuItem.Image”)));
this.printPreviewToolStripMenuItem.
ImageTransparentColor = System.Drawing.
Color.Black;
this.printPreviewToolStripMenuItem.Name =
“printPreviewToolStripMenuItem”;
 T he S o ur c e C o d e 213

thi
s.printPreviewToolStripMenuItem.Size = new
System.Drawing.Size(146, 22);
this.printPreviewToolStripMenuItem.Text =
“Print Pre&view”;
//
//printSetupToolStripMenuItem
//
this.printSetupToolStripMenuItem.Name =
“printSetupToolStripMenuItem”;
thi
s.printSetupToolStripMenuItem.Size = new
System.Drawing.Size(146, 22);
thi
s.printSetupToolStripMenuItem.Text = “Print
Setup”;
//
//toolStripSeparator5
//
this.toolStripSeparator5.Name =
“toolStripSeparator5”;
thi
s.toolStripSeparator5.Size = new System.
Drawing.Size(143, 6);
//
//exitToolStripMenuItem
//
this.exitToolStripMenuItem.Name =
“exitToolStripMenuItem”;
thi
s.exitToolStripMenuItem.Size = new System.
Drawing.Size(146, 22);
this.exitToolStripMenuItem.Text = “E&xit”;
thi
s.exitToolStripMenuItem.Click + = new
System.EventHandler(this.
ExitToolsStripMenuItem_Click);
//
//editMenu
//
this.editMenu.DropDownItems.AddRange(new
System.Windows.Forms.ToolStripItem[] {
this.undoToolStripMenuItem,
this.redoToolStripMenuItem,
this.toolStripSeparator6,
this.cutToolStripMenuItem,
this.copyToolStripMenuItem,
this.pasteToolStripMenuItem,
this.toolStripSeparator7,
this.selectAllToolStripMenuItem});
214 Securit y f o r Rel ati o n a l Data ba se s

this.editMenu.Name = “editMenu”;
this.editMenu.Size = new System.Drawing.
Size(39, 20);
this.editMenu.Text = “&Edit”;
//
//undoToolStripMenuItem
//
this.undoToolStripMenuItem.Image = ((System.
Drawing.Image)(resources.GetObject(“undoToo
lStripMenuItem.Image”)));
this.undoToolStripMenuItem.ImageTransparentColor
= System.Drawing.Color.Black;
this.undoToolStripMenuItem.Name =
“undoToolStripMenuItem”;
this.undoToolStripMenuItem.ShortcutKeys
= ((System.Windows.Forms.Keys)((System.
Windows.Forms.Keys.Control | System.
Windows.Forms.Keys.Z)));
this.undoToolStripMenuItem.Size = new System.
Drawing.Size(164, 22);
this.undoToolStripMenuItem.Text = “&Undo”;
this.undoToolStripMenuItem.Click + = new
System.EventHandler(this.
undoToolStripMenuItem_Click);
//
//redoToolStripMenuItem
//
this.redoToolStripMenuItem.Image = ((System.
Drawing.Image)(resources.GetObject(“redoToo
lStripMenuItem.Image”)));
this.redoToolStripMenuItem.ImageTransparentColor
= System.Drawing.Color.Black;
this.redoToolStripMenuItem.Name =
“redoToolStripMenuItem”;
this.redoToolStripMenuItem.ShortcutKeys
= ((System.Windows.Forms.Keys)((System.
Windows.Forms.Keys.Control | System.
Windows.Forms.Keys.Y)));
this.redoToolStripMenuItem.Size = new System.
Drawing.Size(164, 22);
this.redoToolStripMenuItem.Text = “&Redo”;
//
//toolStripSeparator6
//
 T he S o ur c e C o d e 215

this.toolStripSeparator6.Name =
“toolStripSeparator6”;
thi
s.toolStripSeparator6.Size = new System.
Drawing.Size(161, 6);
//
//cutToolStripMenuItem
//
thi
s.cutToolStripMenuItem.Image = ((System.
Drawing.Image)(resources.
GetObject(“cutToolStripMenuItem.Image”)));
this.cutToolStripMenuItem.
ImageTransparentColor = System.Drawing.
Color.Black;
this.cutToolStripMenuItem.Name =
“cutToolStripMenuItem”;
this.cutToolStripMenuItem.ShortcutKeys =
((System.Windows.Forms.Keys)((System.
Windows.Forms.Keys.Control | System.
Windows.Forms.Keys.X)));
thi
s.cutToolStripMenuItem.Size = new System.
Drawing.Size(164, 22);
this.cutToolStripMenuItem.Text = “Cu&t”;
thi
s.cutToolStripMenuItem.Click + = new
System.EventHandler(this.
CutToolStripMenuItem_Click);
//
//copyToolStripMenuItem
//
thi
s.copyToolStripMenuItem.Image = ((System.
Drawing.Image)(resources.GetObject(“copyToo
lStripMenuItem.Image”)));
this.copyToolStripMenuItem.
ImageTransparentColor = System.Drawing.
Color.Black;
this.copyToolStripMenuItem.Name =
“copyToolStripMenuItem”;
this.copyToolStripMenuItem.ShortcutKeys =
((System.Windows.Forms.Keys)((System.
Windows.Forms.Keys.Control |
System.Windows.Forms.Keys.C)));
thi
s.copyToolStripMenuItem.Size = new System.
Drawing.Size(164, 22);
this.copyToolStripMenuItem.Text = “&Copy”;
216 Securit y f o r Rel ati o n a l Data ba se s

thi
s.copyToolStripMenuItem.Click + = new
System.EventHandler(this.
CopyToolStripMenuItem_Click);
//
//pasteToolStripMenuItem
//
thi
s.pasteToolStripMenuItem.Image = ((System.
Drawing.Image)(resources.GetObject(“pasteTo
olStripMenuItem.Image”)));
this.pasteToolStripMenuItem.
ImageTransparentColor = System.Drawing.
Color.Black;
this.pasteToolStripMenuItem.Name =
“pasteToolStripMenuItem”;
this.pasteToolStripMenuItem.ShortcutKeys
= ((System.Windows.Forms.Keys)((System.
Windows.Forms.Keys.Control | System.
Windows.Forms.Keys.V)));
thi
s.pasteToolStripMenuItem.Size = new System.
Drawing.Size(164, 22);
this.pasteToolStripMenuItem.Text = “&Paste”;
thi
s.pasteToolStripMenuItem.Click + = new
System.EventHandler(this.
PasteToolStripMenuItem_Click);
//
//toolStripSeparator7
//
this.toolStripSeparator7.Name =
“toolStripSeparator7”;
thi
s.toolStripSeparator7.Size = new System.
Drawing.Size(161, 6);
//
//selectAllToolStripMenuItem
//
this.selectAllToolStripMenuItem.Name =
“selectAllToolStripMenuItem”;
this.selectAllToolStripMenuItem.ShortcutKeys
= ((System.Windows.Forms.Keys)((System.
Windows.Forms.Keys.Control | System.
Windows.Forms.Keys.A)));
thi
s.selectAllToolStripMenuItem.Size = new
System.Drawing.Size(164, 22);
thi
s.selectAllToolStripMenuItem.Text = “Select
&All”;
 T he S o ur c e C o d e 217

//
//viewMenu
//
this.viewMenu.DropDownItems.AddRange(new
System.Windows.Forms.ToolStripItem[] {
this.toolBarToolStripMenuItem,
this.statusBarToolStripMenuItem});
this.viewMenu.Name = “viewMenu”;
thi
s.viewMenu.Size = new System.Drawing.
Size(44, 20);
this.viewMenu.Text = “&View”;
//
//toolBarToolStripMenuItem
//
this.toolBarToolStripMenuItem.Checked = true;
this.toolBarToolStripMenuItem.CheckOnClick
= true;
this.toolBarToolStripMenuItem.CheckState =
System.Windows.Forms.CheckState.Checked;
this.toolBarToolStripMenuItem.Name =
“toolBarToolStripMenuItem”;
thi
s.toolBarToolStripMenuItem.Size = new
System.Drawing.Size(126, 22);
this.toolBarToolStripMenuItem.Text =
“&Toolbar”;
thi
s.toolBarToolStripMenuItem.Click + = new
System.EventHandler(this.
ToolBarToolStripMenuItem_Click);
//
//statusBarToolStripMenuItem
//
this.statusBarToolStripMenuItem.Checked
= true;
this.statusBarToolStripMenuItem.CheckOnClick
= true;
this.statusBarToolStripMenuItem.CheckState =
System.Windows.Forms.CheckState.Checked;
this.statusBarToolStripMenuItem.Name =
“statusBarToolStripMenuItem”;
thi
s.statusBarToolStripMenuItem.Size = new
System.Drawing.Size(126, 22);
this.statusBarToolStripMenuItem.Text
= “&Status Bar”;
218 Securit y f o r Rel ati o n a l Data ba se s

thi
s.statusBarToolStripMenuItem.Click + = new
System.EventHandler(this.
StatusBarToolStripMenuItem_Click);
//
//toolsMenu
//
this.toolsMenu.DropDownItems.AddRange(new
System.Windows.Forms.ToolStripItem[] {
this.optionsToolStripMenuItem});
this.toolsMenu.Name = “toolsMenu”;
thi
s.toolsMenu.Size = new System.Drawing.
Size(48, 20);
this.toolsMenu.Text = “&Tools”;
//
//optionsToolStripMenuItem
//
this.optionsToolStripMenuItem.Name
= “optionsToolStripMenuItem”;
thi
s.optionsToolStripMenuItem.Size = new
System.Drawing.Size(116, 22);
this.optionsToolStripMenuItem.Text
= “&Options”;
//
//windowsMenu
//
this.windowsMenu.DropDownItems.AddRange​
(new System.Windows.Forms.ToolStripItem[] {
this.newWindowToolStripMenuItem,
this.cascadeToolStripMenuItem,
this.tileVerticalToolStripMenuItem,
this.tileHorizontalToolStripMenuItem,
this.closeAllToolStripMenuItem,
this.arrangeIconsToolStripMenuItem});
this.windowsMenu.Name = “windowsMenu”;
thi
s.windowsMenu.Size = new System.Drawing.
Size(68, 20);
this.windowsMenu.Text = “&Windows”;
//
//newWindowToolStripMenuItem
//
this.newWindowToolStripMenuItem.Name =
“newWindowToolStripMenuItem”;
thi
s.newWindowToolStripMenuItem.Size = new
System.Drawing.Size(151, 22);
 T he S o ur c e C o d e 219

this.newWindowToolStripMenuItem.Text = “&New
Window”;
this.newWindowToolStripMenuItem.Click + = new
System.EventHandler(this.ShowNewForm);
//
//cascadeToolStripMenuItem
//
this.cascadeToolStripMenuItem.Name =
“cascadeToolStripMenuItem”;
this.cascadeToolStripMenuItem.Size = new
System.Drawing.Size(151, 22);
this.cascadeToolStripMenuItem.Text =
“&Cascade”;
this.cascadeToolStripMenuItem.Click + = new
System.EventHandler(this.
CascadeToolStripMenuItem_Click);
//
//tileVerticalToolStripMenuItem
//
this.tileVerticalToolStripMenuItem.Name
= “tileVerticalToolStripMenuItem”;
this.tileVerticalToolStripMenuItem.Size = new
System.Drawing.Size(151, 22);
this.tileVerticalToolStripMenuItem.Text
= “Tile &Vertical”;
this.tileVerticalToolStripMenuItem.Click +
= new System.EventHandler(this.
TileVerticalToolStripMenuItem_Click);
//
//tileHorizontalToolStripMenuItem
//
this.tileHorizontalToolStripMenuItem.Name
= “tileHorizontalToolStripMenuItem”;
this.tileHorizontalToolStripMenuItem.Size
= new System.Drawing.Size(151, 22);
this.tileHorizontalToolStripMenuItem.Text
= “Tile &Horizontal”;
this.tileHorizontalToolStripMenuItem.Click +
= new System.EventHandler​
(this.TileHorizontalToolStripMenuItem _ Click);
//
//closeAllToolStripMenuItem
//
220 Securit y f o r Rel ati o n a l Data ba se s

this.closeAllToolStripMenuItem.Name
= “closeAllToolStripMenuItem”;
thi
s.closeAllToolStripMenuItem.Size = new
System.Drawing.Size(151, 22);
thi
s.closeAllToolStripMenuItem.Text = “C&lose
All”;
thi
s.closeAllToolStripMenuItem.Click + = new
System.EventHandler(this.
CloseAllToolStripMenuItem_Click);
//
//arrangeIconsToolStripMenuItem
//
this.arrangeIconsToolStripMenuItem.Name
= “arrangeIconsToolStripMenuItem”;
thi
s.arrangeIconsToolStripMenuItem.Size = new
System.Drawing.Size(151, 22);
this.arrangeIconsToolStripMenuItem.Text
= “&Arrange Icons”;
this.arrangeIconsToolStripMenuItem.Click +
= new System.EventHandler(this.
ArrangeIconsToolStripMenuItem_Click);
//
//helpMenu
//
this.helpMenu.DropDownItems.AddRange​
(new System.Windows.Forms.ToolStripItem[] {
this.contentsToolStripMenuItem,
this.indexToolStripMenuItem,
this.searchToolStripMenuItem,
this.toolStripSeparator8,
this.aboutToolStripMenuItem});
this.helpMenu.Name = “helpMenu”;
thi
s.helpMenu.Size = new System.Drawing.
Size(44, 20);
this.helpMenu.Text = “&Help”;
//
//contentsToolStripMenuItem
//
this.contentsToolStripMenuItem.Name =
“contentsToolStripMenuItem”;
this.contentsToolStripMenuItem.ShortcutKeys
= ((System.Windows.Forms.Keys)((System.
Windows.Forms.Keys.Control | System.
Windows.Forms.Keys.F1)));
 T he S o ur c e C o d e 2 21

this.contentsToolStripMenuItem.Size = new
System.Drawing.Size(168, 22);
this.contentsToolStripMenuItem.Text = “&Contents”;
//
//indexToolStripMenuItem
//
this.indexToolStripMenuItem.Image = ((System.
Drawing.Image)(resources.GetObject(“indexTo
olStripMenuItem.Image”)));
this.indexToolStripMenuItem.ImageTransparentColor
= System.Drawing.Color.Black;
this.indexToolStripMenuItem.Name
= “indexToolStripMenuItem”;
this.indexToolStripMenuItem.Size = new System.
Drawing.Size(168, 22);
this.indexToolStripMenuItem.Text = “&Index”;
//
//searchToolStripMenuItem
//
this.searchToolStripMenuItem.Image = ((System.
Drawing.Image)(resources.GetObject(“searchT
oolStripMenuItem.Image”)));
this.searchToolStripMenuItem.
ImageTransparentColor = System.Drawing.
Color.Black;
this.searchToolStripMenuItem.Name =
“searchToolStripMenuItem”;
this.searchToolStripMenuItem.Size = new
System.Drawing.Size(168, 22);
this.searchToolStripMenuItem.Text = “&Search”;
//
//toolStripSeparator8
//
this.toolStripSeparator8.Name =
“toolStripSeparator8”;
this.toolStripSeparator8.Size = new System.
Drawing.Size(165, 6);
//
//aboutToolStripMenuItem
//
this.aboutToolStripMenuItem.Name =
“aboutToolStripMenuItem”;
this.aboutToolStripMenuItem.Size = new System.
Drawing.Size(168, 22);
222 Securit y f o r Rel ati o n a l Data ba se s

this.aboutToolStripMenuItem.Text
= “&About......”;
//
//statusStrip
//
this.statusStrip.Items.AddRange(new System.
Windows.Forms.ToolStripItem[] {
this.toolStripStatusLabel});
thi
s.statusStrip.Location = new System.
Drawing.Point(0, 430);
this.statusStrip.Name = “statusStrip”;
this.statusStrip.RightToLeft
= System.Windows.Forms.RightToLeft.Yes;
thi
s.statusStrip.Size = new System.Drawing.
Size(632, 23);
this.statusStrip.TabIndex = 2;
this.statusStrip.Text = “StatusStrip”;
//
//toolStripStatusLabel
//
thi
s.toolStripStatusLabel.Font = new System.
Drawing.Font(“Arial”, 12F, System.Drawing.
FontStyle.Italic);
this.toolStripStatusLabel.Name
= “toolStripStatusLabel”;
thi
s.toolStripStatusLabel.Size = new System.
Drawing.Size(52, 18);
this.toolStripStatusLabel.Text = “Status”;
//
//newToolStripButton
//
thi
s.newToolStripButton.Image = ((System.
Drawing.Image)(resources.
GetObject(“newToolStripButton.Image”)));
this.newToolStripButton.ImageTransparentColor
= System.Drawing.Color.Black;
this.newToolStripButton.Name
= “newToolStripButton”;
thi
s.newToolStripButton.Size = new System.
Drawing.Size(86, 22);
this.newToolStripButton.Text = “New Query”;
thi
s.newToolStripButton.Click + = new System.
EventHandler(this.ShowNewForm);
//
//openToolStripButton
 T he S o ur c e C o d e 223

//
this.openToolStripButton.DisplayStyle
= System.Windows.Forms.
ToolStripItemDisplayStyle.Image;
thi
s.openToolStripButton.Image = ((System.
Drawing.Image)(resources.
GetObject(“openToolStripButton.Image”)));
this.openToolStripButton.ImageTransparentColor
= System.Drawing.Color.Black;
this.openToolStripButton.Name
= “openToolStripButton”;
thi
s.openToolStripButton.Size = new System.
Drawing.Size(23, 22);
this.openToolStripButton.Text = “Open”;
this.openToolStripButton.Visible = false;
thi
s.openToolStripButton.Click + = new System.
EventHandler(this.OpenFile);
//
//saveToolStripButton
//
this.saveToolStripButton.DisplayStyle
= System.Windows.Forms.
ToolStripItemDisplayStyle.Image;
thi
s.saveToolStripButton.Image = ((System.
Drawing.Image)(resources.
GetObject(“saveToolStripButton.Image”)));
this.saveToolStripButton.ImageTransparentColor
= System.Drawing.Color.Black;
this.saveToolStripButton.Name
= “saveToolStripButton”;
thi
s.saveToolStripButton.Size = new System.
Drawing.Size(23, 22);
this.saveToolStripButton.Text = “Save”;
this.saveToolStripButton.Visible = false;
thi
s.saveToolStripButton.Click + = new System.
EventHandler(this.saveToolStripButton _
Click);
//
//toolStripSeparator1
//
this.toolStripSeparator1.Name =
“toolStripSeparator1”;
thi
s.toolStripSeparator1.Size = new System.
Drawing.Size(6, 25);
//
224 Securit y f o r Rel ati o n a l Data ba se s

//printToolStripButton
//
thi
s.printToolStripButton.DisplayStyle = System.
Windows.Forms.ToolStripItemDisplayStyle.
Image;
thi
s.printToolStripButton.Image = ((System.
Drawing.Image)(resources.
GetObject(“printToolStripButton.Image”)));
this.printToolStripButton.
ImageTransparentColor = System.Drawing.
Color.Black;
this.printToolStripButton.Name
= “printToolStripButton”;
thi
s.printToolStripButton.Size = new System.
Drawing.Size(23, 22);
this.printToolStripButton.Text = “Print”;
this.printToolStripButton.Visible = false;
//
//printPreviewToolStripButton
//
this.printPreviewToolStripButton.DisplayStyle
= System.Windows.Forms.
ToolStripItemDisplayStyle.Image;
this.printPreviewToolStripButton.Image =
((System.Drawing.Image)(resources.GetObject
(“printPreviewToolStripButton.Image”)));
this.printPreviewToolStripButton.
ImageTransparentColor = System.Drawing.
Color.Black;
this.printPreviewToolStripButton.Name
= “printPreviewToolStripButton”;
thi
s.printPreviewToolStripButton.Size = new
System.Drawing.Size(23, 22);
thi
s.printPreviewToolStripButton.Text = “Print
Preview”;
this.printPreviewToolStripButton.Visible
= false;
//
//toolStripSeparator2
//
this.toolStripSeparator2.Name =
“toolStripSeparator2”;
thi
s.toolStripSeparator2.Size = new System.
Drawing.Size(6, 25);
 T he S o ur c e C o d e 225

//
//helpToolStripButton
//
this.helpToolStripButton.DisplayStyle
= System.Windows.Forms.
ToolStripItemDisplayStyle.Image;
thi
s.helpToolStripButton.Image = ((System.
Drawing.Image)(resources.
GetObject(“helpToolStripButton.Image”)));
this.helpToolStripButton.ImageTransparentColor
= System.Drawing.Color.Black;
this.helpToolStripButton.Name
= “helpToolStripButton”;
thi
s.helpToolStripButton.Size = new System.
Drawing.Size(23, 22);
this.helpToolStripButton.Text = “Help”;
this.helpToolStripButton.Visible = false;
//
//toolStrip
//
this.toolStrip.Items.AddRange(new System.
Windows.Forms.ToolStripItem[] {
this.newToolStripButton,
this.openToolStripButton,
this.saveToolStripButton,
this.toolStripSeparator1,
this.toolStripSeparator2,
this.printToolStripButton,
this.printPreviewToolStripButton,
this.helpToolStripButton});
thi
s.toolStrip.Location = new System.Drawing.
Point(0, 0);
this.toolStrip.Name = “toolStrip”;
thi
s.toolStrip.Size = new System.Drawing.
Size(632, 25);
this.toolStrip.TabIndex = 1;
this.toolStrip.Text = “ToolStrip”;
//
//Query
//
thi
s.AutoScaleDimensions = new System.Drawing.
SizeF(6F, 13F);
thi
s.AutoScaleMode = System.Windows.Forms.
AutoScaleMode.Font;
226 Securit y f o r Rel ati o n a l Data ba se s

thi
s.ClientSize = new System.
Drawing.​Size(632, 453);
this.Controls.Add(this.statusStrip);
this.Controls.Add(this.toolStrip);
this.Controls.Add(this.menuStrip);
this.IsMdiContainer = true;
this.MainMenuStrip = this.menuStrip;
this.Name = “Query”;
this.Text = “Query”;
thi
s.WindowState = System.Windows.Forms.
FormWindowState.Maximized;
thi
s.Load + = new System.EventHandler​
(this.Query_Load);
thi
s.FormClosing + = new System.Windows.Forms.
FormClosingEventHandler(this.Query_
FormClosing);
this.menuStrip.ResumeLayout(false);
this.menuStrip.PerformLayout();
this.statusStrip.ResumeLayout(false);
this.statusStrip.PerformLayout();
this.toolStrip.ResumeLayout(false);
this.toolStrip.PerformLayout();
this.ResumeLayout(false);
this.PerformLayout();
}
#endregion
private System.Windows.Forms.MenuStrip
menuStrip;
private System.Windows.Forms.StatusStrip
statusStrip;
private System.Windows.Forms.
ToolStripSeparator toolStripSeparator3;
private System.Windows.Forms.
ToolStripSeparator toolStripSeparator4;
private System.Windows.Forms.
ToolStripSeparator toolStripSeparator5;
private System.Windows.Forms.
ToolStripSeparator toolStripSeparator6;
private System.Windows.Forms.ToolStripMenuItem
printSetupToolStripMenuItem;
private System.Windows.Forms.
ToolStripSeparator toolStripSeparator7;
private System.Windows.Forms.
ToolStripSeparator toolStripSeparator8;
 T he S o ur c e C o d e 227

private System.Windows.Forms.
ToolStripStatusLabel toolStripStatusLabel;
private System.Windows.Forms.ToolStripMenuItem
aboutToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
tileHorizontalToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
fileMenu;
private System.Windows.Forms.ToolStripMenuItem
newToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
openToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
saveToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
saveAsToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
printToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
printPreviewToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
exitToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
editMenu;
private System.Windows.Forms.ToolStripMenuItem
undoToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
redoToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
cutToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
copyToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
pasteToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
selectAllToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
viewMenu;
private System.Windows.Forms.ToolStripMenuItem
toolBarToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
statusBarToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
toolsMenu;
228 Securit y f o r Rel ati o n a l Data ba se s

private System.Windows.Forms.ToolStripMenuItem
optionsToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
windowsMenu;
private System.Windows.Forms.ToolStripMenuItem
newWindowToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
cascadeToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
tileVerticalToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
closeAllToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
arrangeIconsToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
helpMenu;
private System.Windows.Forms.ToolStripMenuItem
contentsToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
indexToolStripMenuItem;
private System.Windows.Forms.ToolStripMenuItem
searchToolStripMenuItem;
private System.Windows.Forms.ToolTip toolTip;
private System.Windows.Forms.ToolStripButton
newToolStripButton;
private System.Windows.Forms.ToolStripButton
openToolStripButton;
private System.Windows.Forms.ToolStripButton
saveToolStripButton;
private System.Windows.Forms.
ToolStripSeparator toolStripSeparator1;
private System.Windows.Forms.ToolStripButton
printToolStripButton;
private System.Windows.Forms.ToolStripButton
printPreviewToolStripButton;
private System.Windows.Forms.
ToolStripSeparator toolStripSeparator2;
private System.Windows.Forms.ToolStripButton
helpToolStripButton;
private System.Windows.Forms.ToolStrip
toolStrip;
}
}
using System;
 T he S o ur c e C o d e 229

using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.Data.SqlClient;
namespace MLS
{
public partial class Query : Form
{
private int childFormNumber = 0;
public Query()
{
InitializeComponent();
}
pri
vate void ShowNewForm(object sender,
EventArgs e)
{
QueryForm childForm = new QueryForm();
childForm.MdiParent = this;
childForm.Dock = DockStyle.Fill;
chi
ldForm.Text = “SQL Query”
+ childFormNumber++;
childForm.Show();
}
pri
vate void OpenFile(object sender,
EventArgs e)
{
Ope
nFileDialog openFileDialog = new
OpenFileDialog();
ope
nFileDialog.InitialDirectory = Environment.
GetFolderPath(Environment.SpecialFolder.
Personal);
ope
nFileDialog.Filter = “Text Files (*.txt)|*.
txt|All Files (*.*)|*.*”;
if (
openFileDialog.ShowDialog(this) = =
DialogResult.OK)
{
str
ing FileName = openFileDialog.
FileName;
}
}
230 Securit y f o r Rel ati o n a l Data ba se s

private void SaveAsToolStripMenuItem_

Click(object sender, EventArgs e)
{
SaveFileDialog saveFileDialog = new
SaveFileDialog();
saveFileDialog.InitialDirectory = Environment.
GetFolderPath(Environment.SpecialFolder.
Personal);
saveFileDialog.Filter = “Text Files (*.txt)|*.
txt|All Files (*.*)|*.*”;
if (saveFileDialog.ShowDialog(this)
= = DialogResult.OK)
{
str
ing FileName = saveFileDialog.
FileName;
}
}
private void ExitToolsStripMenuItem_
Click(object sender, EventArgs e)
{
Application.Exit();
//this.Close();
}
private void CutToolStripMenuItem_Click(object
sender, EventArgs e)
{
}
private void CopyToolStripMenuItem_
Click(object sender, EventArgs e)
{
}
private void PasteToolStripMenuItem_
Click(object sender, EventArgs e)
{
}
private void ToolBarToolStripMenuItem_
Click(object sender, EventArgs e)
{
toolStrip.Visible = toolBarToolStripMenuItem.
Checked;
}
private void StatusBarToolStripMenuItem_
Click(object sender, EventArgs e)
{
 T he S o ur c e C o d e 2 31

statusStrip.Visible =
statusBarToolStripMenuItem.Checked;
}
pri
vate void CascadeToolStripMenuItem_
Click(object sender, EventArgs e)
{
LayoutMdi(MdiLayout.Cascade);
}
pri
vate void TileVerticalToolStripMenuItem_
Click(object sender, EventArgs e)
{
LayoutMdi(MdiLayout.TileVertical);
}
pri
vate void TileHorizontalToolStripMenuItem_
Click(object sender, EventArgs e)
{
LayoutMdi(MdiLayout.TileHorizontal);
}
pri
vate void ArrangeIconsToolStripMenuItem_
Click(object sender, EventArgs e)
{
LayoutMdi(MdiLayout.ArrangeIcons);
}
pri
vate void CloseAllToolStripMenuItem_
Click(object sender, EventArgs e)
{
foreach (Form childForm in MdiChildren)
{
childForm.Close();
}
}
pri
vate void undoToolStripMenuItem_
Click(object sender, EventArgs e)
{
}
pri
vate void Query_FormClosing(object sender,
FormClosingEventArgs e)
{
Application.Exit();
}
pri
vate void Query_Load(object sender,
EventArgs e)
{
232 Securit y f o r Rel ati o n a l Data ba se s

too
lStripStatusLabel.Text = GlobalClasses.
globals.UserName;
}
pri
vate void saveToolStripButton_Click(object
sender, EventArgs e)
{
}
}
}

9.4.4  Source Code of the Query Form

namespace MLS
{
partial class QueryForm
{
///<summary>
///Required designer variable.
///</summary>
private System.ComponentModel.IContainer
components = null;
///<summary>
///Clean up any resources being used.
///</summary>
///
<param name = “disposing”>true if managed resources
should be disposed; otherwise, false.</param>
pro
tected override void Dispose(bool
disposing)
{
if (disposing && (components ! = null))
{
components.Dispose();
}
base.Dispose(disposing);
}
#re
gion Windows Form Designer generated code
///<summary>
///Required method for Designer support - do not modify
///the contents of this method with the code editor.
///</summary>
private void InitializeComponent()
{
 T he S o ur c e C o d e 233

System.ComponentModel.ComponentResourceManager
resources = new System.ComponentModel.Compo
nentResourceManager(typeof(QueryForm));
thi
s.richTextBox1 = new System.Windows.Forms.
RichTextBox();
thi
s.toolStrip1 = new System.Windows.Forms.
ToolStrip();
thi
s.toolStripButton1 = new System.Windows.
Forms.ToolStripButton();
thi
s.splitContainer1 = new System.Windows.
Forms.SplitContainer();
thi
s.BCMLSBTN = new System.Windows.Forms.
RadioButton();
thi
s.MLRBTN = new System.Windows.Forms.
RadioButton();
thi
s.SmithBTN = new System.Windows.Forms.
RadioButton();
thi
s.JSBTN = new System.Windows.Forms.
RadioButton();
thi
s.SeaviewBTN = new System.Windows.Forms.
RadioButton();
thi
s.dataGridView1 = new System.Windows.Forms.
DataGridView();
thi
s.EncryptionBTN = new System.Windows.Forms.
RadioButton();
this.toolStrip1.SuspendLayout();
this.splitContainer1.Panel1.SuspendLayout();
this.splitContainer1.Panel2.SuspendLayout();
this.splitContainer1.SuspendLayout();
((System.ComponentModel.ISupportInitialize)
(this.dataGridView1)).BeginInit();
this.SuspendLayout();
//
//richTextBox1
//
this.richTextBox1.Dock
= System.Windows.Forms.DockStyle.Bottom;
thi
s.richTextBox1.Location = new System.
Drawing.Point(0, 26);
this.richTextBox1.Name = “richTextBox1”;
thi
s.richTextBox1.Size = new System.Drawing.
Size(547, 141);
this.richTextBox1.TabIndex = 0;
this.richTextBox1.Text = “”;
234 Securit y f o r Rel ati o n a l Data ba se s

thi
s.richTextBox1.TextChanged + = new System.
EventHandler(this.richTextBox1 _ TextChanged);
//
//toolStrip1
//
thi
s.toolStrip1.BackColor = System.Drawing.
SystemColors.Control;
this.toolStrip1.Items.AddRange(new System.
Windows.Forms.ToolStripItem[] {
this.toolStripButton1});
thi
s.toolStrip1.Location = new System.Drawing.
Point(0, 0);
this.toolStrip1.Name = “toolStrip1”;
thi
s.toolStrip1.Size = new System.Drawing.
Size(547, 25);
this.toolStrip1.TabIndex = 1;
this.toolStrip1.Text = “toolStrip1”;
thi
s.toolStrip1.ItemClicked + = new System.
Windows.Forms.ToolStripItemClickedEventHand
ler(this.toolStrip1_ItemClicked);
//
//toolStripButton1
//
this.toolStripButton1.Image =
((System.Drawing.Image)(resources.
GetObject(“toolStripButton1.Image”)));
this.toolStripButton1.ImageTransparentColor
= System.Drawing.Color.Magenta;
this.toolStripButton1.Name
= “toolStripButton1”;
thi
s.toolStripButton1.Size = new System.
Drawing.Size(67, 22);
this.toolStripButton1.Text = “Execute”;
thi
s.toolStripButton1.Click + = new System.
EventHandler(this.toolStripButton1_Click);
//
//splitContainer1
//
thi
s.splitContainer1.Dock = System.Windows.
Forms.DockStyle.Fill;
thi
s.splitContainer1.Location = new System.
Drawing.Point(0, 25);
this.splitContainer1.Name = “splitContainer1”;
thi
s.splitContainer1.Orientation = System.
Windows.Forms.Orientation.Horizontal;
 T he S o ur c e C o d e 235

//
//splitContainer1.Panel1
//
this.splitContainer1.Panel1.Controls.
Add(this.EncryptionBTN);
this.splitContainer1.Panel1.Controls.
Add(this.BCMLSBTN);
this.splitContainer1.Panel1.Controls.
Add(this.MLRBTN);
this.splitContainer1.Panel1.Controls.
Add(this.SmithBTN);
this.splitContainer1.Panel1.Controls.
Add(this.JSBTN);
this.splitContainer1.Panel1.Controls.
Add(this.SeaviewBTN);
this.splitContainer1.Panel1.Controls.
Add(this.richTextBox1);
//
//splitContainer1.Panel2
//
this.splitContainer1.Panel2.Controls.
Add(this.dataGridView1);
thi
s.splitContainer1.Size = new System.
Drawing.Size(547, 425);
this.splitContainer1.SplitterDistance = 167;
this.splitContainer1.TabIndex = 2;
//
//BCMLSBTN
//
this.BCMLSBTN.AutoSize = true;
thi
s.BCMLSBTN.Location = new System.Drawing.
Point(295, 3);
this.BCMLSBTN.Name = “BCMLSBTN”;
thi
s.BCMLSBTN.Size = new System.Drawing.
Size(57, 17);
this.BCMLSBTN.TabIndex = 5;
this.BCMLSBTN.TabStop = true;
this.BCMLSBTN.Text = “BCMLS”;
this.BCMLSBTN.UseVisualStyleBackColor = true;
//
//MLRBTN
//
this.MLRBTN.AutoSize = true;
thi
s.MLRBTN.Location = new System.Drawing.
Point(232, 3);
236 Securit y f o r Rel ati o n a l Data ba se s

this.MLRBTN.Name = “MLRBTN”;
thi
s.MLRBTN.Size = new System.Drawing.
Size(45, 17);
this.MLRBTN.TabIndex = 4;
this.MLRBTN.TabStop = true;
this.MLRBTN.Text = “MLR”;
this.MLRBTN.UseVisualStyleBackColor = true;
//
//SmithBTN
//
this.SmithBTN.AutoSize = true;
thi
s.SmithBTN.Location = new System.Drawing.
Point(129, 3);
this.SmithBTN.Name = “SmithBTN”;
thi
s.SmithBTN.Size = new System.Drawing.
Size(97, 17);
this.SmithBTN.TabIndex = 3;
this.SmithBTN.TabStop = true;
this.SmithBTN.Text = “Smith-Winslett “;
this.SmithBTN.UseVisualStyleBackColor = true;
//
//JSBTN
//
this.JSBTN.AutoSize = true;
thi
s.JSBTN.Location = new System.Drawing.
Point(83, 3);
this.JSBTN.Name = “JSBTN”;
this.JSBTN.Size = new System.Drawing.Size(40, 17);
this.JSBTN.TabIndex = 2;
this.JSBTN.TabStop = true;
this.JSBTN.Text = “J-S”;
this.JSBTN.UseVisualStyleBackColor = true;
//
//SeaviewBTN
//
this.SeaviewBTN.AutoSize = true;
thi
s.SeaviewBTN.Location = new System.Drawing.
Point(12, 3);
this.SeaviewBTN.Name = “SeaviewBTN”;
thi
s.SeaviewBTN.Size = new System.Drawing.
Size(65, 17);
this.SeaviewBTN.TabIndex = 1;
this.SeaviewBTN.TabStop = true;
this.SeaviewBTN.Text = “Seaview”;
 T he S o ur c e C o d e 237

this.SeaviewBTN.UseVisualStyleBackColor =
true;
//
//dataGridView1
//
this.dataGridView1.AllowUserToAddRows = false;
thi
s.dataGridView1.AllowUserToDeleteRows = false;
this.dataGridView1.ColumnHeadersHeightSizeMode
= System.Windows.Forms.
DataGridViewColumnHeadersHeightSizeMode.
AutoSize;
thi
s.dataGridView1.Dock = System.Windows.
Forms.DockStyle.Fill;
thi
s.dataGridView1.Location = new System.
Drawing.Point(0, 0);
this.dataGridView1.Name = “dataGridView1”;
this.dataGridView1.ReadOnly = true;
thi
s.dataGridView1.Size = new System.Drawing.
Size(547, 254);
this.dataGridView1.TabIndex = 0;
//
//EncryptionBTN
//
this.EncryptionBTN.AutoSize = true;
thi
s.EncryptionBTN.Location = new System.
Drawing.Point(358, 3);
this.EncryptionBTN.Name = “EncryptionBTN”;
thi
s.EncryptionBTN.Size = new System.Drawing.
Size(100, 17);
this.EncryptionBTN.TabIndex = 6;
this.EncryptionBTN.TabStop = true;
this.EncryptionBTN.Text = “MLR-Encryption”;
this.EncryptionBTN.UseVisualStyleBackColor
= true;
//
//QueryForm
//
thi
s.AutoScaleDimensions = new System.Drawing.
SizeF(6F, 13F);
this.AutoScaleMode =
System.Windows.Forms.AutoScaleMode.Font;
thi
s.ClientSize = new System.Drawing.
Size(547, 450);
this.Controls.Add(this.splitContainer1);
238 Securit y f o r Rel ati o n a l Data ba se s

this.Controls.Add(this.toolStrip1);
thi
s.FormBorderStyle = System.Windows.Forms.
FormBorderStyle.Fixed3D;
this.Name = “QueryForm”;
this.Text = “Query”;
this.toolStrip1.ResumeLayout(false);
this.toolStrip1.PerformLayout();
this.splitContainer1.Panel1.
ResumeLayout(false);
this.splitContainer1.Panel1.PerformLayout();
this.splitContainer1.Panel2.
ResumeLayout(false);
this.splitContainer1.ResumeLayout(false);
((System.ComponentModel.ISupportInitialize)
(this.dataGridView1)).EndInit();
this.ResumeLayout(false);
this.PerformLayout();
}
#endregion
private System.Windows.Forms.RichTextBox
richTextBox1;
private System.Windows.Forms.ToolStrip
toolStrip1;
private System.Windows.Forms.ToolStripButton
toolStripButton1;
private System.Windows.Forms.SplitContainer
splitContainer1;
private System.Windows.Forms.DataGridView
dataGridView1;
private System.Windows.Forms.RadioButton
SeaviewBTN;
private System.Windows.Forms.RadioButton
JSBTN;
private System.Windows.Forms.RadioButton
SmithBTN;
private System.Windows.Forms.RadioButton
MLRBTN;
private System.Windows.Forms.RadioButton
BCMLSBTN;
private System.Windows.Forms.RadioButton
EncryptionBTN;
}
}
using System;
 T he S o ur c e C o d e 239

using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using GlobalClasses;
using System.Data.SqlClient;
using System.Collections;
namespace MLS
{
public partial class QueryForm : Form
{
public QueryForm()
{
InitializeComponent();
}
pri
vate void richTextBox1_TextChanged(object
sender, EventArgs e)
{
}
pri
vate void toolStripButton1_Click(object
sender, EventArgs e)
{
try
{
DateTime dt = DateTime.Now;
string SqlStr = “”;
if (richTextBox1.Text.ToUpper().
Contains(“SELECT”))
{
string oldSTR = MLSDB.
DMLSTR(richTextBox1.Text).Trim().
ToUpper();
string newSTR = “”; ;
if (SeaviewBTN.Checked)
{
newSTR =
“UserVisibleSeaView” +
MLSDB.DMLSTR(richTextBox1.
Text).Trim().ToUpper();
}
else if (JSBTN.Checked)
24 0 Securit y f o r Rel ati o n a l Data ba se s

{
new
STR = “UserVisibleJS” +
MLSDB.DMLSTR(richTextBox1.
Text).Trim().ToUpper();
}
else if (SmithBTN.Checked)
{
new
STR = “UserVisibleSmith”
+ MLSDB.
DMLSTR(richTextBox1.Text).
Trim().ToUpper();
}
else if (MLRBTN.Checked)
{
new
STR = “VW” + MLSDB.
DMLSTR(richTextBox1.
Text).Trim().ToUpper();
}
else if (EncryptionBTN.Checked)
{
new
STR = “[Vw” + MLSDB.
DMLSTR(richTextBox1.
Text).Trim().ToUpper()
+ “-Encryption]”;
}
if (BCMLSBTN.Checked)
{
new
STR = “VBC” + MLSDB.
DMLSTR(richTextBox1.
Text).Trim().ToUpper();
}
BindingSource bindingSource1 = new
BindingSource();
Sql
Str = richTextBox1.Text.ToUpper().
Replace(oldSTR, newSTR);
if (EncryptionBTN.Checked)
{
Sql
Str = “exec dbo.usp_
EnableCellVisibility;”
+ SqlStr;
}
bindingSource1.DataSource =
GlobalClasses.DBOperations.
GetData(SqlStr).Tables 0];
 T he S o ur c e C o d e 2 41

dataGridView1.DataSource =
bindingSource1;
}
els
e if (richTextBox1.Text.
ToUpper().Contains(“INSERT”))
{
str
ing name = GlobalClasses.MLSDB.
GetInsertValue(MLSDB.
AttributeSTR(richTextBox1.Text))
[0].ToString();
str
ing Dept = GlobalClasses.MLSDB.
GetInsertValue(MLSDB.
AttributeSTR(richTextBox1.Text))
[1].ToString();
str
ing Salary = GlobalClasses.MLSDB.
GetInsertValue(MLSDB.
AttributeSTR(richTextBox1.Text))
[2].ToString();
str
ing Class = GlobalClasses.
globals.UserLabelID.ToString();
str
ing Label =
GlobalClasses.globals.UserLabel;
if (SeaviewBTN.Checked)
{
str
ing D2Str = “insert into
dbo.[D2-” + GlobalClasses.
globals.UserLabel + “]
values(“ + name + “,” +
Class + “,” + Dept + “,”
+ Class + “)”;
str
ing D3Str = “insert into
dbo.[D3-” + GlobalClasses.
globals.UserLabel + “]
values(“ + name + “,” +
Class + “,” + Salary +
“,” + Class + “)”;
GlobalClasses.DBOperations.
SetData(D2Str);
GlobalClasses.DBOperations.
SetData(D3Str);
}
else if (JSBTN.Checked)
{
string DStr = “insert into
dbo.[D” + GlobalClasses.
242 Securit y f o r Rel ati o n a l Data ba se s

globals.UserLabel + “]
values(“ + name + “,” +
Class + “,” + Dept + “,”
+ Class +”,” + Salary +
“,” + Class+ “)”;
GlobalClasses.DBOperations.
SetData(DStr);
}
else if (SmithBTN.Checked)
{
str
ing DStr = “insert into dbo.
[Smith-Employee] values(“ + name
+ “,” + Class + “,” + Dept + “,”
+ Salary + “,” + Class + “)”;
GlobalClasses.DBOperations.
SetData(DStr);
}
if (MLRBTN.Checked)
{
str
ing DStr = “insert into dbo.
[Employee] values(“ + name + “,”
+ Class + “,” + Dept + “,” +
Class + “,” + Salary + “,” +
Class + “,” + Class + “)”;
GlobalClasses.DBOperations.
SetData(DStr);
}
if (EncryptionBTN.Checked)
{
str
ing DStr = “exec dbo.
usp _ EnableCellVisibility;
insert into dbo.[Employee]
values(ENCRYPTBYKEY(KEY _
GUID(‘” + Label +
“SymmetricKey’),’” + name
+ “’),” +
“ENCRYPTBYKEY(KEY _ GUID(‘”
+ Label +
“SymmetricKey’),’” + Dept
+ “’),” +
“ENCRYPTBYKEY(KEY _ GUID(‘”
+ Label +
“SymmetricKey’),’” +
Salary + “’),” + Class+
“)”;
 T he S o ur c e C o d e 24 3

GlobalClasses.DBOperations.
SetData(DStr);
}
if (BCMLSBTN.Checked)
{
string BCClass = MLSDB.
GetBCLabelNumeric​
(globals.UserLabel.
ToUpper()).ToString();
string DStr = “insert into
dbo.[BCEmployee]
values(“ + name + “,” +
BCClass + “,” + Dept +
“,” + BCClass + “,” +
Salary + “,” + BCClass +
“,” + BCClass + “,0)”;
GlobalClasses.DBOperations.
SetData(DStr);
}
}
else if (richTextBox1.Text.
ToUpper().Contains(“UPDATE”))
{
string SelectSTR = “”;
ArrayList AttributeARR
= GlobalClasses.MLSDB.
GetAttribute(MLSDB.
AttributeSTR(richTextBox1.Text));
string PredicateSTR = MLSDB.
PredicateSTR(richTextBox1.Text);
if (SeaviewBTN.Checked)
{
string select = “”;
string updatePredicate = “”;
string UpdateStr = “”;
if (PredicateSTR.Split​
(‘ = ‘)[0].Trim().ToUpper()
= = “DEPARTMENT” ||
PredicateSTR.Split(“in”.
ToCharArray(),2)[0].Trim().
ToUpper() = =
“DEPARTMENT”)
{
24 4 Securit y f o r Rel ati o n a l Data ba se s

sel
ect = “select name from
dbo.[D2-” + GlobalClasses.
globals.UserLabel + “]
where “ + PredicateSTR;
}
els
e if (PredicateSTR.
Split(‘ = ‘)[0].Trim().
ToUpper() = = “SALARY” ||
PredicateSTR.Split(“in”.
ToCharArray(),2)[0].Trim().
ToUpper() = = “SALARY”)
{
sel
ect = “select name from
dbo.[D3-” + GlobalClasses.
globals.UserLabel + “]
where “ + PredicateSTR;
}
foreach (DataRow DR in
GlobalClasses.
DBOperations.
GetData(select).
Tables 0].Rows)
{
updatePredicate =
updatePredicate +”’” +
DR[“name”].ToString() +
“’,”;
}
updatePredicate
= updatePredicate.
Remove(updatePredicate.
Length - 1);
updatePredicate = “(“+
updatePredicate +”)”;
foreach (string s in
AttributeARR)
{
if (s.Split(‘ = ‘)[0].
Trim().ToUpper() = =
“DEPARTMENT”)
{
Upd
ateStr = “Update dbo.
[D2-” +
GlobalClasses.
globals.UserLabel +
 T he S o ur c e C o d e 24 5

“] set “ + s + “
where name in “ +
updatePredicate;
}
else if (s.Split(‘ = ‘)[0].
Trim().ToUpper() = =
“SALARY”)
{
UpdateStr = “Update dbo.
[D3-” +
GlobalClasses.
globals.UserLabel +
“] set “ + s + “
where name in “ +
updatePredicate;
}
GlobalClasses.DBOperations.
SetData(UpdateStr);
}
}
if (JSBTN.Checked)
{
string UpdateStr = “”;
UpdateStr = “Update dbo.
[D” + GlobalClasses.
globals.UserLabel + “]
set “ + MLSDB.
AttributeSTR​
(richTextBox1.Text) + “
where “ + PredicateSTR;
GlobalClasses.DBOperations.
SetData(UpdateStr);
}
if (SmithBTN.Checked)
{
string UpdateStr = “”;
if (MLSDB.PredicateSTR​
(richTextBox1.Text) = =
“”)
{
UpdateStr = “Update dbo.
[Smith-Employee] set “ +
MLSDB.AttributeSTR​
(richTextBox1.Text) + “
where TC = “ +
24 6 Securit y f o r Rel ati o n a l Data ba se s

GlobalClasses.globals.
UserLabelID.ToString();
}
else
{
UpdateStr = “Update dbo.
[Smith-Employee] set “ +
MLSDB.AttributeSTR​
(richTextBox1.Text) + “
where “ + PredicateSTR +
“ and TC = “ +
GlobalClasses.globals.
UserLabelID.ToString();
}
GlobalClasses.DBOperations.
SetData(UpdateStr);
}
else if (MLRBTN.Checked)
{
if (MLSDB.PredicateSTR​
(richTextBox1.Text) = =
“”)
{
SqlStr = richTextBox1.Text
+ “ where TC = “ +
GlobalClasses.globals.​
UserLabelID.ToString();
SelectSTR = “Select * “ + “
From VW” + MLSDB.DMLSTR​
(richTextBox1.Text).
Trim() + “ where TC <>
‘” + GlobalClasses.
globals.UserLabel+”’”;
}
else
{
SqlStr = richTextBox1.Text
+ “ and TC = “ +
GlobalClasses.globals.​
UserLabelID.ToString();
Sel
ectSTR = “Select * “ + “ From vw” + MLSDB.
DMLSTR(richTextBox1.Text).Trim() + “ where
“ + MLSDB.PredicateSTR(richTextBox1.Text) +
“ and TC <> ‘” + GlobalClasses.globals.
UserLabel+”’”;
 T he S o ur c e C o d e 2 47

}
GlobalClasses.DBOperations.
SetData(SqlStr);
foreach (DataRow DR in
GlobalClasses.
DBOperations.
GetData(SelectSTR).
Tables 0].Rows)
{
foreach (string s in
GlobalClasses.MLSDB.
GetAttribute(MLSDB.
AttributeSTR​
(richTextBox1.Text)))
{
DR.SetField(s.Split​
(‘ = ‘)[0].Trim(),
s.Split(‘ = ‘)[1].
Trim());
DR.SetField(“C” +
s.Split(‘ = ‘)[0].
Trim(),
GlobalClasses.
globals.UserLabelID);
}
DR.SetField(“TC”,
GlobalClasses.globals.
UserLabelID);
string ColumnSTR = “”;
string ColumnValuesSTR = “”;
foreach (DataColumn DC in
DR.Table.Columns)
{
ColumnSTR + =
DC.ColumnName + “,”;
}
ColumnSTR = ColumnSTR.
Remove(ColumnSTR.Length
- 1);
foreach (object value in
DR.ItemArray)
{
if (value is string)
{
24 8 Securit y f o r Rel ati o n a l Data ba se s

if (
 !value.ToString().
Contains(“’”))
{
ColumnValuesSTR + =
“’” + value.
ToString() + “’,”;
}
else
{
ColumnValuesSTR + =
value.ToString() +
“,”;
}
}
else
{
ColumnValuesSTR + =
value.ToString() +
“,”;
}
}
ColumnValuesSTR =
ColumnValuesSTR.
Remove(ColumnValuesSTR.
Length - 1);
string InsertSTR = “insert
into “ + MLSDB.
DMLSTR(richTextBox1.
Text).Trim() + “(“ +
ColumnSTR + “) values (“
+ ColumnValuesSTR + “)”;
GlobalClasses.DBOperations.
SetData(InsertSTR);
}
}
else if (EncryptionBTN.
Checked)
{
string Predicate = MLSDB.
PredicateSTR​
(richTextBox1.Text);
if (Predicate = = “”)
{
SqlStr = richTextBox1.Text
+ “ where TC = “ +
 T he S o ur c e C o d e 24 9

GlobalClasses.globals.
UserLabelID.ToString();
Sel
ectSTR = “exec dbo.
usp_EnableCellVisibility;
Select * “ + “ From [VW”
+ MLSDB.
DMLSTR(richTextBox1.
Text).Trim() +
“-Encryption] where TC
<> “ + GlobalClasses.
globals.UserLabelID;
}
else
{
str
ing newPredicate = “
CONVERT(nvarchar​
(MAX), DecryptByKey​
(“+Predicate.
Split(“in”.
ToCharArray(), 2)[0].
Trim()+”)) “;
SqlStr = “exec dbo.usp_
EnableCellVisibility;” +
richTextBox1.Text.
Replace(Predicate.
Split(“in”.
ToCharArray(), 2)[0].
Trim(), newPredicate) +
“ and TC = “ +
GlobalClasses.globals.
UserLabelID.ToString();
SqlStr = SqlStr.
Replace(MLSDB.
DMLSTR(richTextBox1.
Text).Trim(), “dbo.
[“+MLSDB.
DMLSTR(richTextBox1.
Text).Trim() +
“-Encryption]”);
//+ MLSDB.GetAttribute​
(MLSDB.AttributeSTR​
(richTextBox1.Text))[0].
ToString()
SelectSTR = “exec dbo.
usp_
250 Securit y f o r Rel ati o n a l Data ba se s

EnableCellVisibility;
Select * “ + “ From [VW”
+ MLSDB.
DMLSTR(richTextBox1.
Text).Trim() +
“-Encryption] where “ +
MLSDB.PredicateSTR​
(richTextBox1.Text) + “
and TC <> “ +
GlobalClasses.globals.
UserLabelID;
}
GlobalClasses.DBOperations.​
SetData(SqlStr);
foreach (DataRow DR in
GlobalClasses.
DBOperations.
GetData(SelectSTR).
Tables 0].Rows)
{
foreach (string s in
GlobalClasses.MLSDB.
GetAttribute(MLSDB.
AttributeSTR​
(richTextBox1.Text)))
{
DR.SetField(s.Split(‘ =
‘)[0].Trim(),
s.Split(‘ = ‘)[1].
Trim());
}
DR.SetField(“TC”,
GlobalClasses.globals.
UserLabelID);
string ColumnSTR = “”;
string ColumnValuesSTR =
“”;
foreach (DataColumn DC in
DR.Table.Columns)
{
ColumnSTR + =
DC.ColumnName + “,”;
}
 T he S o ur c e C o d e 2 51

ColumnSTR = ColumnSTR.
Remove(ColumnSTR.Length
- 1);
foreach (object value in
DR.ItemArray)
{
if (value is string)
{
if (!value.ToString().
Contains(“’”))
{
ColumnValuesSTR + =
“ENCRYPTBYKEY(KEY_
GUID(‘” + globals.
UserLabel +
“SymmetricKey’),’”
+ value.ToString()
+ “’),”;
}
else
{
ColumnValuesSTR + =
“ENCRYPTBYKEY(KEY_
GUID(‘” + globals.
UserLabel +
“SymmetricKey’),” +
value.ToString() +
“),”;
}
}
else
{
ColumnValuesSTR + =
value.ToString() +
“,”;
}
}
ColumnValuesSTR =
ColumnValuesSTR.Remove​
(ColumnValuesSTR.Length
- 1);
string InsertSTR = “exec
dbo.usp_
EnableCellVisibility;
insert into [“ + MLSDB.
252 Securit y f o r Rel ati o n a l Data ba se s

DMLSTR(richTextBox1.
Text).Trim() +
“-Encryption](“ +
ColumnSTR + “) values
(“ + ColumnValuesSTR +
“)”;
GlobalClasses.DBOperations.
SetData(InsertSTR);
}
}
else if (BCMLSBTN.Checked)
{
int TC = 0;
if (MLSDB.PredicateSTR​
(richTextBox1.Text) = =
“”)
{
SelectSTR = “Select * From
BC” + MLSDB.DMLSTR​
(richTextBox1.Text).
Trim();
}
else
{
SelectSTR = “Select * From
BC” + MLSDB.DMLSTR​
(richTextBox1.Text).
Trim() + “ where “ +
MLSDB.PredicateSTR​
(richTextBox1.Text);
}
foreach (DataRow DR in
GlobalClasses.
DBOperations.
GetData(SelectSTR).
Tables 0].Rows)
{
TC = Convert.
ToInt32(DR[6]);
if (MLSDB.
GetBCprimarylevel(TC) =
= globals.UserLabel)
{
 T he S o ur c e C o d e 253

GlobalClasses.
DBOperations.SetData​
(richTextBox1.Text);
}
}
}
}
els
e if (richTextBox1.Text.
ToUpper().Contains(“UPLEVEL”))
{
str
ing Query = richTextBox1.Text.
Replace(“\n”, “ “);
string name = “”;
string Cname = “”;
string Dept = “”;
string CDept = “”;
string Salary = “”;
string CSalary = “”;
int TC = globals.UserLabelID;
string SelectSTR = “”;
for
each (string s in GlobalClasses.
MLSDB.GetAttribute(MLSDB.
AttributeSTR(Query)))
{
string[] stringSeparators
= new string[]
{“FROM”};
str
ing Coulmn =
s.ToUpper().
Split(stringSeparators,
StringSplitOptions.
RemoveEmptyEntries)[0].
Trim().ToUpper();
str
ing CoulmnClass =
s.ToUpper().
Split(stringSeparators,
StringSplitOptions.
RemoveEmptyEntries)[1].
Trim().ToUpper();
if 
(Coulmn = =
“DEPARTMENT”)
{
Sel
ectSTR = “Select
Name,CName,Department,​
CDept from “ + MLSDB.
25 4 Securit y f o r Rel ati o n a l Data ba se s

DMLSTR(Query).Trim() + “
where “ + MLSDB.
PredicateSTR(Query) + “
and TC = “ + MLSDB.
GetLabelID(CoulmnClass);
Dat
aRow DR = GlobalClasses.
DBOperations.GetData​
(SelectSTR).Tables 0].
Rows[0];
nam
e = DR.ItemArray[0].
ToString();
Cna
me = DR.ItemArray[1].
ToString();
Dep
t = DR.ItemArray[2].
ToString();
CDe
pt = DR.ItemArray[3].
ToString();
}
els
e if (Coulmn = =
“SALARY”)
{
Sel
ectSTR = “Select
Name,CName,SALARY,​
CSALARY from “ + MLSDB.
DMLSTR(Query).Trim() + “
where “ + MLSDB.
PredicateSTR(Query) + “
and TC = “ + MLSDB.
GetLabelID(CoulmnClass);
Dat
aRow DR = GlobalClasses.
DBOperations.GetData​
(SelectSTR).Tables 0].
Rows[0];
nam
e = DR.ItemArray[0].
ToString();
Cna
me = DR.ItemArray[1].
ToString();
Sal
ary = DR.ItemArray[2].
ToString();
CSa
lary = DR.ItemArray[3].​
ToString();
}
}
str
ing DStr = “insert into “ +
MLSDB.DMLSTR(Query).Trim() + “
 T he S o ur c e C o d e 255

values(‘” + name + “’,” + Cname +

“,’” + Dept + “’,” + CDept + “,”
+ Salary + “,” + CSalary + “,” +
TC.ToString() + “)”;
GlobalClasses.DBOperations.
SetData(DStr);
}
else if (richTextBox1.Text.
ToUpper().Contains(“VERIFY”))
{
string Query = richTextBox1.Text.
Replace(“\n”, “ “);
str
ing SelectSTR = “select * from BC”
+ MLSDB.DMLSTR(richTextBox1.Text).
Trim().ToUpper() + “ where “ +
MLSDB.PredicateSTR(richTextBox1.
Text);
DataRow DR = GlobalClasses.
DBOperations.GetData(SelectSTR).
Tables 0].Rows[0];
string xkey = DR.ItemArray[0].
ToString();
intxlbOl = Convert.ToInt32(DR.
ItemArray[1].ToString());
intxtc = Convert.ToInt32(DR.
ItemArray[6].ToString());
intnewLabel = MLSDB.
VerifyBCUserbelief(xtc, Convert.
ToBoolean(MLSDB.
AttributeSTR(richTextBox1.Text)));
string UpdateSTR = “Update BC” +
MLSDB.DMLSTR(richTextBox1.Text).
Trim() + “ set CName = “ +
newLabel.ToString() + “, CDept =
“ + newLabel.ToString() + “,
CSalary = “ + newLabel.ToString()
+ “, TC = “ + newLabel.ToString()
+ “, flag = “ + newLabel.
ToString() + “ where “ + MLSDB.
PredicateSTR(richTextBox1.Text) +
“ and TC = “ + xtc.ToString();
GlobalClasses.DBOperations.
SetData(UpdateSTR);
}
256 Securit y f o r Rel ati o n a l Data ba se s

els
e if (richTextBox1.Text.
ToUpper().Contains(“DELETE”))
{
if (SeaviewBTN.Checked)
{
string D2Str = “Delete From
dbo.[D2-” +
GlobalClasses.globals.
UserLabel + “] where “ +
MLSDB.PredicateSTR​
(richTextBox1.Text);
string D3Str = “Delete From
dbo.[D3-” +
GlobalClasses.globals.
UserLabel + “] where “ +
MLSDB.PredicateSTR​
(richTextBox1.Text);
GlobalClasses.DBOperations.
SetData(D2Str);
GlobalClasses.DBOperations.
SetData(D3Str);
}
else if (JSBTN.Checked)
{
string DStr = “Delete From
dbo.[D” + GlobalClasses.
globals.UserLabel + “]
where “ + MLSDB.
PredicateSTR​
(richTextBox1.Text);
GlobalClasses.DBOperations.
SetData(DStr);
}
else if (SmithBTN.Checked)
{
string DStr = “Delete From
dbo.[Smith-Employee]
where “ + MLSDB.
PredicateSTR​
(richTextBox1.Text) + “
and TC = “ +
GlobalClasses.globals.
UserLabelID;
GlobalClasses.DBOperations.
SetData(DStr);
 T he S o ur c e C o d e 257

}
else if (MLRBTN.Checked)
{
string DStr = “Delete From
“ + MLSDB.
DMLSTR(richTextBox1.
Text).Trim() + “ where “
+ MLSDB.PredicateSTR​
(richTextBox1.Text) + “
and TC = “ +
GlobalClasses.globals.
UserLabelID;
GlobalClasses.DBOperations.
SetData(DStr);
}
else if (EncryptionBTN.Checked)
{
string DStr = “Delete From
[“ + MLSDB.DMLSTR​
(richTextBox1.Text).
Trim() + “-Encryption]
where “ + MLSDB.
PredicateSTR​
(richTextBox1.Text) + “
and TC = “ +
GlobalClasses.globals.
UserLabelID;
GlobalClasses.DBOperations.
SetData(DStr);
}
else if (BCMLSBTN.Checked)
{
str
ing SelectSTR = “select
* from BC” + MLSDB.
DMLSTR(richTextBox1.
Text).Trim().ToUpper() +
“ where “ + MLSDB.
PredicateSTR​
(richTextBox1.Text);
Dat
aRow DR = GlobalClasses.
DBOperations.GetData​
(SelectSTR).Tables 0].
Rows[0];
258 Securit y f o r Rel ati o n a l Data ba se s

string xkey =
DR.ItemArray[0].
ToString();
intxlbOl = Convert.
ToInt32(DR.ItemArray[1].
ToString());
intxtc = Convert.
ToInt32(DR.ItemArray[6].
ToString());
if (MLSDB.
GetBCSecondarylevel(xtc)
= = “”)
{
string DStr = “Delete From
BC” + MLSDB.DMLSTR​
(richTextBox1.Text).
Trim() + “ where “ +
MLSDB.PredicateSTR​
(richTextBox1.Text) + “
and TC = “ + xtc.
ToString();
GlobalClasses.DBOperations.
SetData(DStr);
}
else
{
intnewLabel = MLSDB.
UnverifyBCUserbelief​
(xtc);
string UpdateSTR = “Update
BC” + MLSDB.DMLSTR​
(richTextBox1.Text).
Trim() + “ set CName = “
+ newLabel.ToString() +
“, CDept = “ + newLabel.
ToString() + “, CSalary
= “ + newLabel.
ToString() + “, TC = “ +
newLabel.ToString() + “,
flag = “ + newLabel.
ToString() + “ where “ +
MLSDB.PredicateSTR​
(richTextBox1.Text) + “
and TC = “ + xtc.
ToString();
 T he S o ur c e C o d e 259

GlobalClasses.DBOperations.
SetData(UpdateSTR);
}
}
}
MessageBox.Show(DateTime.Now.
Subtract(dt).ToString());
}
catch (Exception EX)
{
MessageBox.Show(EX.Message);
}
}
pri
vate void toolStrip1_ItemClicked(object sender,
ToolStripItemClickedEventArgs e)
{
}
}
}

9.4.5  Source Code of the Concurrency Control Form

namespace MLS
{
partial class QueryForm
{
///<summary>
///Required designer variable.
///</summary>
private System.ComponentModel.IContainer
components = null;
///<summary>
///Clean up any resources being used.
///</summary>
///
<param name = “disposing”>true if managed resources
should be disposed; otherwise, false.</param>
pro
tected override void Dispose(bool
disposing)
{
if (disposing && (components ! = null))
{
components.Dispose();
}
base.Dispose(disposing);
}
260 Securit y f o r Rel ati o n a l Data ba se s

#region Windows Form Designer generated code

///<summary>
/// Required method for Designer support - do not
modify
///the contents of this method with the code editor.
///</summary>
private void InitializeComponent()
{
System.ComponentModel.ComponentResourceManager
resources = new System.ComponentModel.​
ComponentResourceManager​
(typeof(QueryForm));
thi
s.richTextBox1 = new System.Windows.Forms.
RichTextBox();
thi
s.toolStrip1 = new System.Windows.Forms.
ToolStrip();
thi
s.toolStripButton1 = new System.Windows.
Forms.ToolStripButton();
thi
s.splitContainer1 = new System.Windows.
Forms.SplitContainer();
thi
s.radioButton1 = new System.Windows.Forms.
RadioButton();
thi
s.SeaviewBTN = new System.Windows.Forms.
RadioButton();
thi
s.dataGridView1 = new System.Windows.Forms.
DataGridView();
this.toolStrip1.SuspendLayout();
this.splitContainer1.Panel1.SuspendLayout();
this.splitContainer1.Panel2.SuspendLayout();
this.splitContainer1.SuspendLayout();
((System.ComponentModel.ISupportInitialize)
(this.dataGridView1)).BeginInit();
this.SuspendLayout();
//
//richTextBox1
//
thi
s.richTextBox1.Dock = System.Windows.Forms.
DockStyle.Bottom;
thi
s.richTextBox1.Location = new System.
Drawing.Point(0, 26);
this.richTextBox1.Name = “richTextBox1”;
thi
s.richTextBox1.Size = new System.Drawing.
Size(547, 141);
this.richTextBox1.TabIndex = 0;
this.richTextBox1.Text = “”;
 T he S o ur c e C o d e 2 61

thi
s.richTextBox1.TextChanged + = new System.
EventHandler(this.richTextBox1_
TextChanged);
//
//toolStrip1
//
thi
s.toolStrip1.BackColor = System.Drawing.
SystemColors.Control;
this.toolStrip1.Items.AddRange(new System.
Windows.Forms.ToolStripItem[] {
this.toolStripButton1});
thi
s.toolStrip1.Location = new System.Drawing.
Point(0, 0);
this.toolStrip1.Name = “toolStrip1”;
thi
s.toolStrip1.Size = new System.Drawing.
Size(547, 25);
this.toolStrip1.TabIndex = 1;
this.toolStrip1.Text = “toolStrip1”;
thi
s.toolStrip1.ItemClicked + = new System.
Windows.Forms.ToolStripItemClickedEventHand
ler(this.toolStrip1_ItemClicked);
//
//toolStripButton1
//
thi
s.toolStripButton1.Image = ((System.
Drawing.Image)(resources.
GetObject(“toolStripButton1.Image”)));
this.toolStripButton1.ImageTransparentColor =
System.Drawing.Color.Magenta;
this.toolStripButton1.Name =
“toolStripButton1”;
thi
s.toolStripButton1.Size = new System.
Drawing.Size(67, 22);
this.toolStripButton1.Text = “Execute”;
thi
s.toolStripButton1.Click + = new System.
EventHandler(this.toolStripButton1_Click);
//
//splitContainer1
//
thi
s.splitContainer1.Dock = System.Windows.
Forms.DockStyle.Fill;
thi
s.splitContainer1.Location = new System.
Drawing.Point(0, 25);
this.splitContainer1.Name = “splitContainer1”;
262 Securit y f o r Rel ati o n a l Data ba se s

thi
s.splitContainer1.Orientation = System.
Windows.Forms.Orientation.Horizontal;
//
//splitContainer1.Panel1
//
this.splitContainer1.Panel1.Controls.Add(this.
radioButton1);
this.splitContainer1.Panel1.Controls.Add(this.
SeaviewBTN);
this.splitContainer1.Panel1.Controls.Add(this.
richTextBox1);
//
//splitContainer1.Panel2
//
this.splitContainer1.Panel2.Controls.Add(this.
dataGridView1);
thi
s.splitContainer1.Size = new System.
Drawing.Size(547, 425);
this.splitContainer1.SplitterDistance = 167;
this.splitContainer1.TabIndex = 2;
//
//radioButton1
//
this.radioButton1.AutoSize = true;
thi
s.radioButton1.Location = new System.
Drawing.Point(302, 3);
this.radioButton1.Name = “radioButton1”;
thi
s.radioButton1.Size = new System.Drawing.
Size(70, 17);
this.radioButton1.TabIndex = 2;
this.radioButton1.TabStop = true;
this.radioButton1.Text = “Proposed”;
this.radioButton1.UseVisualStyleBackColor =
true;
//
//SeaviewBTN
//
this.SeaviewBTN.AutoSize = true;
thi
s.SeaviewBTN.Location = new System.Drawing.
Point(168, 3);
this.SeaviewBTN.Name = “SeaviewBTN”;
thi
s.SeaviewBTN.Size = new System.Drawing.
Size(73, 17);
this.SeaviewBTN.TabIndex = 1;
this.SeaviewBTN.TabStop = true;
 T he S o ur c e C o d e 263

this.SeaviewBTN.Text = “Rajwinder”;
this.SeaviewBTN.UseVisualStyleBackColor =
true;
//
//dataGridView1
//
this.dataGridView1.AllowUserToAddRows = false;
this.dataGridView1.AllowUserToDeleteRows =
false;
this.dataGridView1.ColumnHeadersHeightSizeMode
= System.Windows.Forms.
DataGridViewColumnHeadersHeightSizeMode.
AutoSize;
thi
s.dataGridView1.Dock = System.Windows.
Forms.DockStyle.Fill;
thi
s.dataGridView1.Location = new System.
Drawing.Point(0, 0);
this.dataGridView1.Name = “dataGridView1”;
this.dataGridView1.ReadOnly = true;
thi
s.dataGridView1.Size = new System.Drawing.
Size(547, 254);
this.dataGridView1.TabIndex = 0;
//
//QueryForm
//
thi
s.AutoScaleDimensions = new System.Drawing.
SizeF(6F, 13F);
thi
s.AutoScaleMode = System.Windows.Forms.
AutoScaleMode.Font;
thi
s.ClientSize = new System.Drawing.Size(547,
450);
this.Controls.Add(this.splitContainer1);
this.Controls.Add(this.toolStrip1);
thi
s.FormBorderStyle = System.Windows.Forms.
FormBorderStyle.Fixed3D;
this.Name = “QueryForm”;
this.Text = “Query”;
this.toolStrip1.ResumeLayout(false);
this.toolStrip1.PerformLayout();
this.splitContainer1.Panel1.
ResumeLayout(false);
this.splitContainer1.Panel1.PerformLayout();
this.splitContainer1.Panel2.
ResumeLayout(false);
this.splitContainer1.ResumeLayout(false);
264 Securit y f o r Rel ati o n a l Data ba se s

((System.ComponentModel.ISupportInitialize)
(this.dataGridView1)).EndInit();
this.ResumeLayout(false);
this.PerformLayout();
}
#endregion
private System.Windows.Forms.RichTextBox
richTextBox1;
private System.Windows.Forms.ToolStrip
toolStrip1;
private System.Windows.Forms.ToolStripButton
toolStripButton1;
private System.Windows.Forms.SplitContainer
splitContainer1;
private System.Windows.Forms.DataGridView
dataGridView1;
private System.Windows.Forms.RadioButton
SeaviewBTN;
private System.Windows.Forms.RadioButton
radioButton1;
}
}
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using GlobalClasses;
using System.Data.SqlClient;
using System.Collections;
namespace MLS
{
public partial class QueryForm : Form
{
public QueryForm()
{
InitializeComponent();
}
pri
vate void richTextBox1_TextChanged(object
sender, EventArgs e)
{
}
 T he S o ur c e C o d e 265

pri
vate void toolStrip1_ItemClicked(object
sender, ToolStripItemClickedEventArgs e)
{
}
pri
vate void toolStripButton1_Click(object
sender, EventArgs e)
{
if (radioButton1.Checked)
{
SqlConnection HighConnection = new
SqlConnection(“Data Source =.;
Initial Catalog =
ConcurrenCycontrol;Integrated
Security = SSPI “);
HighConnection.Open();
SqlCommand HighCommand =
HighConnection.CreateCommand();
SqlTransaction LowTrans;
SqlTransaction HighTrans;
//Start a local transaction
DateTime datepefor = DateTime.Now;
HighTrans = HighConnection.
BeginTransaction();
HighCommand.Connection =
HighConnection;
HighCommand.Transaction = HighTrans;
HighCommand.CommandText = “select *
from MLS where tc = ‘Low’”;
HighCommand.ExecuteNonQuery();
intcounter = int.
Parse(richTextBox1.Text);
SqlConnection LowConnection = new
SqlConnection(“Data Source =.;
Initial Catalog =
ConcurrenCycontrol;Integrated
Security = SSPI “);
LowConnection.Open();
SqlCommand LowCommand =
LowConnection.CreateCommand();
DateTime datepefor1 = DateTime.Now;
LowTrans = LowConnection.
BeginTransaction();
LowCommand.Connection =
LowConnection;
LowCommand.Transaction = LowTrans;
266 Securit y f o r Rel ati o n a l Data ba se s

for (int i = 1; i < = counter; i++)

{
LowCommand.CommandText = “update MLS
set Salary = Salary where tc =
‘Low’”;
LowCommand.ExecuteNonQuery();
}
LowTrans.Commit();
string datelow = DateTime.Now.
Subtract(datepefor1).ToString();
HighTrans.Commit();
MessageBox.Show(DateTime.Now.
Subtract(datepefor).ToString() +
“ low “ + datelow);
}
else
{
SqlConnection HighConnection = new
SqlConnection(“Data Source =.;
Initial Catalog =
ConcurrenCycontrol;Integrated
Security = SSPI “);
HighConnection.Open();
SqlCommand HighCommand =
HighConnection.CreateCommand();
SqlTransaction LowTrans;
SqlTransaction HighTrans;
//Start a local transaction
DateTime datepefor = DateTime.Now;
HighTrans = HighConnection.
BeginTransaction();
HighCommand.Connection =
HighConnection;
HighCommand.Transaction = HighTrans;
HighCommand.CommandText = “select
top 300 * from MLS where tc =
‘Low’”;
HighCommand.ExecuteNonQuery();
intcounter = int.
Parse(richTextBox1.Text);
SqlConnection LowConnection = new
SqlConnection(“Data Source =.;
Initial Catalog =
ConcurrenCycontrol;Integrated
Security = SSPI “);
 T he S o ur c e C o d e 267

LowConnection.Open();
SqlCommand LowCommand =
LowConnection.CreateCommand();
LowTrans = LowConnection.
BeginTransaction();
LowCommand.Connection =
LowConnection;
LowCommand.Transaction = LowTrans;
LowCommand.CommandText = “update MLS
set Salary = Salary where tc =
‘Low’ and Name not in (select top
300 Name from MLS)”;
LowCommand.ExecuteNonQuery();
for (int i = 1; i < = counter; i++)
{
LowCommand.CommandText = “update MLS
set Salary = Salary where tc =
‘Low’ and Name in (select top 300
Name from MLS)”;
LowCommand.ExecuteNonQuery();
}
LowTrans.Commit();
HighTrans.Commit();
MessageBox.Show(DateTime.Now.
Subtract(datepefor).ToString());
}
}
}}
References

1. Hao-Wei He. History of relational database. Available at http://www.

studymode.com/essays/History-Of-Relational-Database-517921.html
(last visit 2013).
2. Edgar Frank Codd. 1970. A relational model of data for large shared data
banks. Communications of the ACM 13 (6): 377–387.
3. Gautam Bhargava and Shashi K. Gadia. 1993. Relational database sys-
tems with zero information loss. IEEE Transactions on Knowledge and
Data Engineering 5 (1): 76–87.
4. Joseph M. Hellerstein, Michael Stonebraker, and James Hamilton. 2007.
Architecture of a database system. Foundations and Trends in Databases
1 (2): 141–259.
5. Ramez Elmasri and Shamkant B. Navathe. 2010. Fundamentals of data-
base systems, 6th ed. Boston: Addison–Wesley.
6. Elisa Bertino and Ravi Sandhu. 2005. Database security—Concepts,
approaches, and challenges. IEEE Transactions on Dependable and Secure
Computing 2 (1): 2–19.
7. Sohail Imran and Irfan Hyder. 2009. Security issues in databases.
Proceedings of Second International Conference on Future Information
Technology and Management Engineering, 541–545.
8. Pierangela Samarati and Sabrina De Capitani di Vimercati. 2001. Access
control: Policies, models, and mechanisms. In Foundations of security anal-
ysis and design. Berlin: Springer, 137–196.
9. Ravi S. Sandhu. 1994. Relational database access controls. In Handbook of
information security management. Boca Raton, FL: Auerbach Publishers,
145–160.

269
270 Ref eren c e s

10. Ji-Won Byun and Ninghui Li. 2008. Purpose based access control for
privacy protection in relational database systems. Journal of VLDB 17 (4):
603–619.
11. Cristi Garvey and Amy Wu. ASD—Views. 1988. Proceedings of the IEEE
Conference on Security and Privacy, 85–95.
12. Zhu Hong and Feng Yu-Cai. 2001. Study on mandatory access control
in a secure database management system. Journal of Shanghai University
5 (4): 299–307.
13. Mario Pranjic, KreSimir Fertalj, and Nenad Jukic. 2002. Importance
of semantics in MLS database models. Proceedings of 24th International
Conference on Information Technology Interfaces, 51–56.
14. Hasan M. Jamil and Gillian Dobbie. 2004. On logical foundations of
multilevel secure databases. Journal of Intelligent Information Systems
23 (3): 271–294.
15. Luigi Giuri and Pietro lglio. 1996. A role-based secure database design
tool. Proceedings of the 12th Annual Computer Security Applications
Conference, 203–212.
16. Li-xin Xu, Dong Sun, and Dan Liu. 2010. Study on methods for data
confidentiality and data integrity in relational databases. Proceedings of the
3rd IEEE International Conference on Computer Science and Information
Technology (ICCSIT), 292–295.
17. Walid Rjaibi and Paul Bird. 2004. A multi-purpose implementation of
mandatory access control in relational database management systems.
Proceedings of the 30th VLDB Conference, Toronto, Canada, 1010–1020.
18. Indrakshi Ray and Wei Huang. 2005. Event detection in multilevel
secure active databases. Proceedings of the International Conference ICISS
2005, 177–190.
19. Ravi S. Sandhu and Sushil Jajodia. 1992. Polyinstantiation for cover
­stories. Proceedings of Second European Symposium on Research in Computer
Security, Toulouse, France, 307–328.
20. Sushil Jajodia, Ravi S. Sandhu, and Barbara T. Blaustein. 1995. Solutions
to the polyinstantiation problem, in information security. An integrated collec-
tion of essays, ed. M. Abrams, IEEE Computer Society Press, 493–529.
21. Doug Nelson and Chip Paradise. 1991. Using polyinstantiation to
develop an MLS application. Proceedings of the Seventh Annual Computer
Security Applications Conference, 12–22.
22. Mikko T. Siponen. 2002. Database security and the problem of polyin-
stantiation: A moral scrutiny. Australasian Journal of Information Systems
10 (1): 41–49.
23. Andro Galinovi and Vlatka Anton. 2007. Polyinstantiation in rela-
tional databases with multilevel security. Proceedings of the ITI 2007 29th
International Conference on Information Technology Interfaces, 128–132.
24. Mark Heckman and William R. Shockley. 1990. The SeaView security
model. IEEE Transactions on Software Engineering 16 (6): 593–607.
25. Sushil Jajodia and Ravi S. Sandhu. 1991. A novel decomposition of mul-
tilevel relations into single-level relations. IEEE Symposium on Security
and Privacy, Oakland, California, 300–313.
 Ref eren c e s 2 71

26. Sushil Jajodia and Ravi Sandhu. 1991. Toward a multilevel secure
relational data model. Proceedings of ACM SIGMOD International
­
Conference on Management Data, Denver, Colorado, 50–59.
27. Joachim Biskup and Lena Wiese. 2009. Combining consistency and
confidentiality requirements in first-order databases. Proceedings of
International Conference ISC 2009, 121–134.
28. Ravi Sandhu and Fang Chen. 1998. The multilevel relational (MLR) data
model. ACM Transactions on Information and System Security 1 (1): 93–132.
29. Nenad Jukic, Susan V. Vrbsky, Allen Parrish, Brandon Dixon, and
Boris Jukic. A belief-consistent multilevel secure relational data model.
Information Systems 24 (5): 377–402.
30. Teresa F. Lunt, Roger R. Schell, William R. Shockley, Mark Heckman, and
Dan Warren. 1988. A near-term design for the SeaView multilevel database
system. Proceedings of the IEEE Symposium on Security and Privacy, 234–244.
31. Frederic Cuppens and Kioumars Yazdanian. 1992. A natural decom-
position of multi-level relations. Proceedings of the IEEE Symposium on
Security and Privacy, 273–284.
32. Keith F. Brewster. 1996. Trusted database management system inter-
pretation of the trusted computer system evaluation criteria. National
Computer Security Center, NCSC technical report-005, 3 (5): 1–57.
33. Ravi Sandhu and Fang Chen. 1995. The semantics and expressive power
of the MLR data model. Proceedings of IEEE Conference on Security and
Privacy, Oakland, CA, 128–142.
34. Mario Pranjic, Nenad Jukic, and Krcsimir Fertalj. 2003. Implementing
belief-consistent multilevel secure relational data model: Issues and solu-
tions. Proceedings of 25th International Conference Information Technology
Interfaces IT1, 149–154.
35. Nenad A. Jukic and Susan V. Vrbsky. 1997. Asserting beliefs in MLS
relational models. Proceedings of SIGMOD Record 26 (3): 30–35.
36. B. Schneier. 1996. Applied cryptography, 2nd ed. New York: John Wiley
& Sons.
37. L. Kocarev. 2001. Chaos-based cryptography: A brief overview. IEEE
Circulation Systems Magazine 1 (3): 6–21.
38. D. Stinson. 2002. Cryptography: Theory and practice, 2nd ed. Boca Raton,
FL: Chapman & Hall.
39. Y. Mao, G. Chen, and S. Lian. 2004. A novel fast image encryption scheme
based on 3D chaotic Baker maps. International Journal of Bifurcation and
Chaos 14 (10): 3613–3624.
40. S. Li. 2003. Analyses and new designs of digital chaotic ciphers. PhD
­thesis, School of Electronics & Information Engineering, Xi’an Jiaotong
University, Xi’an, China.
41. National Bureau of Standards. 1980. Data encryption standard modes
of operation, federal information processing standards publication 81.
U.S. Government Printing Office, Washington, DC.
42. S. Li, G. Chen, and X. Zheng. 2004. Chaos-based encryption for digital
images and videos. In Multimedia security handbook, chap. 4. Boca Raton,
FL: CRC Press.
272 Ref eren c e s

43. Y. Mao and M. Wu. 2006. A joint signal processing and cryptographic
approach to multimedia encryption. IEEE Transactions on Image Processing
15 (7): 2061–2075.
44. Y. Mao. 2003. Research on chaos-based image encryption and water-
marking technology. PhD thesis, Department of Automation, Nanjing
University of Science & Technology, Nanjing, China.
45. J. Daemen and V. Rijmen. 1999. AES proposal: Rijndael. AES algorithm
submission.
46. R. Kusters and M. Tuengerthal. 2009. Universally composable sym-
metric encryption, 2nd IEEE Computer Security Foundations Symposium
(CSF ‘09), 293–307.
47. H. Jin, Z. Liao, D. Zou, and C. Li. 2008. Asymmetrical encryption based
automated trust negotiation model. 2nd IEEE International Conference on
Digital Ecosystems and Technologies (DEST 2008), 363–368.
48. S. G. Lian, J. Sun, and Z. Wang. 2004. A novel image encryption scheme
based on JPEG encoding. Proceedings of 8th International Conference on
Information Visualization, 217–220.
49. M. V. Droogenbroeck and R. Benedett. 2002. Techniques for a selec-
tive encryption of uncompressed and compressed images. Proceedings of
Advanced Concepts for Intelligent Vision Systems (ACIVS), Ghent, Belgium,
90–97, September 9–11.
50. F. Dachselt, K. Kelber, and W. Schwarz. 1997. Chaotic coding and cryp-
toanalysis. Proceedings of IEEE International Symposium on Circuits and
Systems, Hong Kong, 1061–1064, June 9–12.
51. S. Li and X. Zheng. 2002. Cryptanalysis of a chaotic image encryption
method. Proceedings of IEEE International Symposium on Circuits and
Systems (ISCAS) 2:708–711.
52. J. Wei, X. Liao, K. W. Wong, and T. Zhou. 2005. Cryptanalysis of crypto-
system using multiple one-dimensional chaotic maps. Communications in
Nonlinear Science and Numerical Simulation 12: 814–822.
53. L. Kocarev and G. Jakimoski. 2001. Logistic map as a block encryption
algorithm. Physics Letters A 289 (4–5): 199–206.
54. T. Xiang, X. Liao, G. Tang, Y. Chen, and K. W. Wong. 2006. A novel
block cryptosystem based on iterating a chaotic map. Physics Letters A 349
(1–4): 109–115.
55. S. Contini, R. L. Rivest, M. J. B. Robshaw, and Y. L. Yin. 1998. The secu-
rity of the RC6TM block cipher. RSA Laboratories, M. I. T. Laboratory
for Computer Science, version 1.0.
56. M. Salleh, S. Ibrahim, and I. F. Isnin. 2003. Enhanced chaotic image
encryption algorithm based on Baker’s map. Proceedings of 2003
International Symposium on Circuits and Systems (ISCAS ‘03), 2:
508–511.
57. D. Chen. 2009. A feasible chaotic encryption scheme for image.
International Workshop on Chaos-Fractals Theories and Applications
(IWCFTA’09), 172–176.
58. A. Palacios and H. Juarez. 2002. Cryptography with cycling chaos. Physics
Letters A 303 (5–6): 345–351.
 Ref eren c e s 2 73

59. H. E. H. Ahmed, H. M. Kalash, and O. S. Faragallah. 2007. Encryption

efficiency analysis and security evaluation of RC6 block cipher for digi-
tal images. International Conference on Electrical Engineering (ICEE ‘07),
1–7, April 11–12.
60. Min-A Jeong, Jung-Ja Kim, and Yonggwan Won. 2003. A flexible data-
base security system using multiple access control policies. Proceedings
of the 4th International Conference on Parallel and Distributed Computing,
Applications and Technologies, 236–240.
61. Bruce Benfield and Richard Swagerman. 2001. Encrypting data values
in DB2 universal database. Available at http://www.ibm.com/devel-
operworks/data/library/techarticle/benfield/0108benfield.html (accessed
March 2011).
62. Transparent data encryption. Available at http://docs.oracle.com/cd/
B19306_01/network.102/b14268/asotrans.htm (accessed July 2011).
63. Worawit Meanrach and Suphamit Chittayasothorn. 2007. A bitempo-
ral multilevel secure database system. Proceedings of IEEE African 2007
Conference, 1–7.
64. Art Rask, Don Rubin, and Bill Neumann. 2005. Implementing row-
and cell-level security in classified databases using SQL server. 2005.
Available at http://technet.microsoft.com/en-us/library/cc966395.aspx
(accessed April 2011).
65. Yuval Elovici, Ronen Waisenberg, Eras Shmueli, and Ehud Gudes.
2004. A structure preserving database encryption scheme. Proceedings of
International Conference SDM, 28–40.
66. Xiao-Dong Zuo, Feng-Mai Liu, and Chao-Bin Ma. 2007. A new
approach to multilevel security based on trusted computing platform.
Proceedings of the Sixth International Conference on Machine Learning and
Cybernetics, Hong Kong, 2158–2163.
67. Navdeep Kaur, Rajwinder Singh, and H. S. Saini. 2009. Design and
analysis of secure scheduler for MLS distributed database systems.
Proceedings of IEEE International Advance Computing Conference (IACC
2009) Patiala, India, 1400–1404.
68. Ramzi Haraty and Natalie Bekaii. 2006. Towards a temporal multilevel
secure database (TMSDB). Journal of Computer Science 2 (1): 19–28.
69. Pinal Dave. 2008. Introduction to SQL server encryption and symmetric
key encryption tutorial. Available at http://dotnetslackers.com/articles/
sql/IntroductionToSQLServerEncryptionAndSymmetric​KeyEncryption​
Tutorial.aspx (accessed May 2011).
70. Moses Garuba. 2003. Performance study of a cots distributed DBMS
adapted for multilevel security. PhD thesis, Department of Mathematics,
Royal Holloway, University of London, Egham, Surrey. Available at
http://digirep.rhul.ac.uk/items/f076f347-2036-6bd0-98c8-e1d2dc-
9cf4ab/1/ (accessed April 2011).
71. Moses Garuba, Edward Appiah, and Legand Burge. 2004. Performance
study of a MLS/DBMS implemented as a kernelized architecture.
Proceedings of the International Conference on Information Technology:
Coding and Computing (ITCC’04), 566–570.
2 74 Ref eren c e s

72. Zahid Rashid, Abdul Basit, and Zahid Anwar. 2010. TRDBAC: Temporal
reflective database access control. Proceedings of 6th International
Conference on Emerging Technologies (ICET), 337–342.
73. Vinti M. Doshi, William R. Hemdon, Sushil Jajodia, and Catherine
D. McCollum. 1996. Benchmarking multilevel secure database ­systems
using the MITRE benchmark. Proceedings of IEEE Transactions on
Knowledge and Data Engineering 8 (1): 46–55.
74. Leon Pan. 2008. Using criterion-based access control for multilevel
database security. Proceedings of International Symposium on Electronic
Commerce and Security, 518–522.
75. Ravi S. Sandhu and Sushil Jajodia. 1993. Referential integrity in multi-
level secure databases. Proceedings of 16th NIST-NCSC National Computer
Security Conference, Baltimore, MD, 39–52.
76. Marco Vieira and Henrique Madeira. 2005. Towards a security benchmark
for database management systems. Proceedings of the 2005 International
Conference on Dependable Systems and Networks, 1–10.
77. Gunther Pernul, A. Min Tjoa, and Werner Winiwarter. 1998. Modeling
data secrecy and integrity. Data & Knowledge Engineering Journal
26 (3): 291–308.
78. Zhu Hong, Zhu Yi, Li Chenyang, Shi Jie, Fu Ge,and Wang Yuanzhen.
2008. Formal specification and verification of an extended security
policy model for database systems. Proceedings of Third Asia–Pacific
­
Trusted Infrastructure Technologies Conference, 132–141.
79. Xiaolei Qian and Teresa F. Lunt. 1997. A semantic framework of the
multilevel secure relational model. IEEE Transactions on Knowledge and
Data Engineering 9 (2): 292–301.
80. Leon Pan. 2009. A unified network security and fine-grained database
access control model. Proceedings of the Second International Symposium on
Electronic Commerce and Security, 265–269.
81. Kamel Barkaoui, Rahma Ben Ayed, Hanifa Boucheneb, and Awatef
Hicheur. 2008. Verification of workflow processes under multilevel secu-
rity considerations. Proceedings of Third International Conference on Risks
and Security of Internet and Systems, 77–84.
82. Baohua Wang, M. A. Xinqiang, and L. I. Danning. 2008. A formal mul-
tilevel database security model. Proceedings of International Conference on
Computational Intelligence and Security, 252–256.
83. Yongzhong He, Zhen Han, Huirong Fu, and Guangzhi Qu. 2010. The
formal model of DBMS enforcing multiple security policies. Journal of
Software 5 (5): 514–521.
84. Veluchandhar Vadivelu, R. V. Jayakumar, M. Muthuvel,
K. Balasubramanian, A. Karthi, Karthikesan, G. Ramaiyan, Alagarsamy
Deepa, and S. Albert Rabara. 2008. A backup mechanism with con-
currency control for multilevel secure distributed database systems.
Proceedings of Third IEEE International Conference on Digital Information
Management (ICDIM), 57–62.
85. Aidong Zhang and Ahmed Elmagarmid. 1993. A theory of global concur-
rency control in multidatabase systems. Journal of VLDB 2 (3): 331–359.
 Ref eren c e s 275

86. Bharat Bhargava. 1999. Concurrency control in database systems. IEEE

Transactions on Knowledge and Data Engineering 11 (1): 3–16.
87. Sharon Lewis and Simon Wiseman. 1993. Database design and MLS
DBMSs: An unhappy alliance. Proceedings of the Ninth Annual Computer
Security Application Conference, 232–243.
88. Khaled Maabreh and Alaa AI-Hamami. 2008. Increasing database
concurrency control based on attribute level locking. Proceedings of the
International Conference on Electronic Design, 1–4.
89. Qilong Han, Haiwei Pan, and Guisheng Yin. 2008. A concurrency con-
trol algorithm access to temporal data in real-time database ­systems.
Proceedings of the International Multisymposiums on Computer and
Computational Sciences Conference, 168–171.
90. Fritz Laux and Martti Laiho. 2009. SQL access patterns for optimis-
tic concurrency control. Proceedings of the Future Computing, Service
Computation, Cognitive, Adaptive, Content, Patterns Conference, 254–258.
91. Xiaoyu Qi. 2010. A fast concurrency control algorithm in embedded
real-time database system. Proceedings of the International Conference on
Computer Engineering and Technology (ICCET), 608–610.
92. Qiansheng Zheng and Xiaoming Bi. 2010. An improved concurrency
control algorithm for distributed real-time database. Proceedings of the
International Conference on Advanced Management Science (ICAMS),
364–367.
93. Qiuyu Zhang, Sanjun Sui, and Jingrong Li. 2007. Research and realiza-
tion of transaction concurrency control in grid database. Proceedings of
the Sixth International Conference on Grid and Cooperative Computing,
168–172.
94. Navdeep Kaur, Rajwinder Singh, Manoj Misra, and A. K. Sarje. 2006.
A secure concurrency control for MLS/DDBSs. Proceedings of the
International Conference on Digital Information Management, 41–46.
95. Navdeep Kaur, Rajwinder Singh, A. K. Sarje, and Manoj Misra, 2005.
Performance evaluation of secure concurrency control algorithm for mul-
tilevel secure distributed database systems. Proceedings of the International
Conference on Information Technology, 249–254.
96. Navdeep Kaur, Rajwinder Singh, Manoj Misra, and A. K. Sarje. 2007.
A  feedback based secure concurrency control for MLS distributed
database. Proceedings of the International Conference on Computational
Intelligence and Multimedia Applications, 8–12.
97. Navdeep Kaur, Rajwinder Singh, Manoj Misra, and A. K. Sarje. 2009.
Concurrency control for multilevel secure databases. International Journal
of Network Security 9 (1): 70–81.
98. Markus Morgenstern. 1987. Security and inference in multilevel database
and knowledge-base systems. Proceedings of the ACM SIGMOD International
Conference on Management of Data, San Francisco, CA, 357–373.
99. Sang-Won Lee, Yong-Han Kim, and Hyoung-Joo Kim. 2004. The
semantics of an extended referential integrity for a multilevel secure rela-
tional data model. International Journal of Data & Knowledge Engineering
48 (1): 129–152.
276 Ref eren c e s

100. Nenad Jukic, Svetlozar Nestorov, Susan V. Vrbsky, and Allen Parrish.
2005. Enhancing database access control by facilitating non-key related
cover stories. Journal of Database Management 16 (10): 1–22.
101. Vijayalakshmi Atluri, Sushil Jajodia, and Elisa Bertino. 1997. Transaction
processing in multilevel secure databases with kernelized architecture:
Challenges and solutions. IEEE Transactions on Knowledge and Data
Engineering 9 (5): 697–708.
102. Jonathan Millen and Teresa Lunt. 1992. Security for object-oriented
database systems. Proceedings of the IEEE Symposium on Research in
Security and Privacy, Oakland, CA, 260–272.
103. Thomas Keefe and Wei-Tek Tsai. 1996. A multiversion transaction sched-
uler for centralized multilevel secure database systems. Proceedings of the
1st High-Assurance Systems Engineering Workshop (HASE ‘96), Niagara,
Canada, 206–213.
104. Eduardo Fernandez, Ehud Gudes, and H. Song. 1989. A security model
for object-oriented databases. Proceedings of the IEEE Symposium on
Security and Privacy, 110–115.
105. Eduardo Fernandez, Ehud Gudes, and H. Song. 1994. A model for
evaluation and administration of security in object-oriented databases.
International Journal of IEEE Transactions on Knowledge and Data
Engineering 6 (2): 275–292.
106. Jeffrey Parsons and Jianmin Su. 2006. Analysis of data structures to sup-
port the instance-based database model. Proceedings of Design Science
Research in Information Systems and Technology (DESRIST), Claremont,
CA, 107–130.
107. Jeffrey Parsons and Jianmin Su. 2010. The instance-based multilevel secu-
rity model. Proceedings of International Conference DESRIST, 365–380.
Information Technology / Database

Since databases are the primary repositories of information for today’s

organizations and governments, database security has become critically
important. Introducing the concept of multilevel security in relational
databases, this book provides a comparative study of the various models that
support multilevel security policies in the relational database—illustrating
the strengths and weaknesses of each model.

Multilevel Security for Relational Databases covers multilevel database

security concepts along with many other multilevel database security models
and techniques. It presents a prototype that readers can implement as a
tool for conducting performance evaluations to compare multilevel secure
database models.

The book supplies a complete view of an encryption-based multilevel security

database model that integrates multilevel security for the relational database
with a system that encrypts each record with an encryption key according to
its security class level. This model will help you utilize an encryption system
as a second security layer over the multilevel security layer for the database,
reduce the multilevel database size, and improve the response time of data
retrieval from the multilevel database.

Considering instance-based multilevel database security, the book covers

relational database access controls and examines concurrency control
in multilevel database security systems. It includes database encryption
algorithms, simulation programs, and Visual studio and Microsoft SQL
Server code.

K21447
6000 Broken Sound Parkway, NW
Suite 300, Boca Raton, FL 33487 ISBN: 978-1-4822-0539-8
711 Third Avenue 90000
an informa business New York, NY 10017
2 Park Square, Milton Park
www.crcpress.com Abingdon, Oxon OX14 4RN, UK
9 781482 205398
www.auerbach-publications.com