Verified Order-Based Transaction Scheduling Scheme for Multilevel Secure Database Management Systems Yonglak Sohn 1 and Songchun Moon 2 1
Dept. of Computers Engineering, Seokyeong Univ., 16-1 Jungneung-Dong Sungbuk-Ku, Seoul 136-704, Korea, Tel.: +82-2-940-7103, Fax.: +82-2-919-0345
[email protected] 2 Database Sys. Lab., Graduate School of Management, Korea Advanced Institute of Science and Technology, 207-43 Cheongryangri-Dong, Dongdaemun-Ku, Seoul 130-012, Korea
[email protected]
Abstract. While the secure transaction schedulers in multilevel secure database systems synchronize transactions cleared at different security levels, they must consider the problem of covert channel. Through the covert channel, malicious users leak secret information in a way of intentional interference among the transactions that they invoked. Much work had been done for closing the covert channel. Although they succeeded in closing the covert channel, they unfortunately failed in preserving correctness, sufficient recentness of versions read, or fairness with respect to availability. In this paper, we present a new secure transaction scheduler, named Verified Order-based Transaction Scheduler (VO) that founds on multiversion database. VO overcomes the problems of previous work. Keywords: Multilevel security, Database, Concurrency Control, Covert Channel
1 Introduction While transactions execute concurrently and share data objects, conflicts among them are unavoidable. Conventional transaction schedulers preserve correctness in a way of interference such as rejecting or delaying the conflicting operations [7]. Although these conventional ones preserve correctness with regard to the notion of serializability, they are definitely vulnerable to an infringement of secrecy-focused security.1 If such interference occurs from a transaction cleared at high security level, high transaction for short, to low transactions, low transactions for short, it opens an unexpected communication channel, named covert channel, between the transactions. Eliminating the covert channel is one of the major requirements of security evaluation criteria for secure information systems. The problem of covert channel now com
1 In principle, security in computer system is composed of three major aspects: secrecy, integrity and availability. However, we focus only on secrecy. Therefore, the term security in this paper represents the aspect of secrecy. M. Ibrahim, J. Küng, and N. Revell (Eds.): DEXA 2000, LNCS 1873, pp. 254-263, 2000. © Springer-Verlag Berlin Heidelberg 2000
Verified Order-Based Transaction Scheduling Scheme
255
pulsorily demands the attention to security along with correctness. It therefore makes secure transaction schedulers more complex than conventional transaction schedulers. Much work, such as [2, 4, 5, 6, 9, 10, 11, 12] have been devoted to develop secure transaction schedulers(STSs). Some of them [2, 5, 9] argue that the traditional notion of serializability-related correctness [7] is too restrictive for MLS/DBMS to achieve desirable performance. On the other hand, STSs proposed by [4, 6, 11] achieve correctness and security at the cost of declined performance of high transactions. They thus come to infringe fairness with respect to availability of transactions of different security levels. STSs proposed by [10, 12], achieve security and correctness in a way of disposing high transactions before active low transactions with respect to serializability. Accordingly, high transactions are now forced to read far outdated data versions. Verified Order-based transaction scheduler (VO) proposed in this paper founds on multiversion database (MVDB) and eliminates covert channel in a way of driving all the abort-destined conflicts to occur only among transactions cleared at the same security level. The major scheduling policies of VO are as follows: • Non-interfered executions of conflicting operations do not always violate correctness or security. • Retaining sufficient trace of ordering relationship among transactions is very much useful for perceiving justice or injustice of non-interfered executions of conflicting operations.
2 The Models A transaction is an abstract unit of concurrent computation that executes with primitives: read, write, commit, and abort. Users interact with the database by invoking transactions. Read or write of a transaction, Ti, that accesses a data item, x, is denoted by ri[x] or wi[x], respectively. ci and ai denote commit and abort of Ti. History, H, is a set of totally ordered operations that have been scheduled by an STS. In an MVDB, each write operation of a committed transaction on a data item ultimately produces a new version of the data item that is to be added into a list of versions. wi[x] and ri[y] of a transaction, Ti, are now mapped to wi[xi] and ri[yj] in MVDB. Hence, the new version, xi, never overwrites its previous versions but instead coexists with them. Coexisting data versions, xi and xj, are called sibling versions and are totally ordered. xi comes to precede xj in case that ci precedes cj in a history. In this case, ordering relationship between them is represented by xi « xj. Versions turn out to be visible only after their creators come to commit. The principle of one-copy serializability, 1SR for short, among the scheduled transactions is applied for proving the correctness of MVDB-based history [7]. Security level labeling function defined as follows represents the relationships between transactions and(or) data objects at the standpoint of multilevel security. Definition 1(Security level labeling function): Security level labeling function, L, maps a transaction and a data object to their specific security levels. It is represented
256
Y. Sohn and S. Moon
by L: T D S where D is a set of data objects, T is a set of transactions, and S is a hierarchical set of security levels. L(Ti) > L(dj) denotes that the security level of Ti is higher than that of dj.ä In order to filter out unauthorized requests of transactions, multilevel secure information systems need to define an access control policy. In this paper, we define the access control policy as follows: Definition 2(Access control policy): A transaction Ti is allowed to access a data dj if L(Ti) and L(dj) obey following two provisions: • Read-equal/Read-down: Ti is allowed to read from dj if and only if L(Ti) L(dj). • Write-equal: Ti is allowed to write a new value to dj if and only if L(Ti) = L(dj). ä The access control policy is strictly grounded on Restricted Bell-LaPadula model [1]. By applying this, direct information flow from a transaction, Ti, to Tj with L(Ti) > L(Tj) in a way of writing and reading a value can be cut off. Unfortunately, however, it is insufficient to close covert channel that occurs after the access control policy had been applied. In order to preserve correctness and close covert channel at once, an MVDB-based STS must be able to produce trustedly serializable, TSR for short, histories all the time. It is defined as follows: Definition 3(Trusted serializability): A history, H, is TSR if and only if it satisfies following two requirements simultaneously: • Correctness preservation: H is 1SR, and • Security preservation: For any pair of transactions, Ti and Tj with L(Ti) > L(Tj), in H, any interference from Ti to Tj has been eradicated. ä
3 Verified Order-Based Transaction Scheduler: VO
3.1 Verification of Transaction Ordering Relationship In order to produce trustedly serializable history, VO maintains information that delineates obviously which transactions precede and which other transactions follow a particular transaction. VO verifies such transaction ordering relationships, TORs for short, in pursuance of following rules whenever it receives an operation. If a transaction, Ti, precedes the other transaction, Ti, TOR between Ti and Ti hereafter is depicted by Ti Tj. Rule 1(Verification of transaction ordering relationship): • TOR with regard to read-from: If wj[xj] precedes cj and cj precedes ri[xj] in a history, VO considers Tj Ti. • TOR with regard to version order: If xi « xj, VO considers Ti Tj. • TOR with regard to read-preceding: If a history has ri[xj] and xj « xk, VO considers Tj Ti and at the same time Ti Tk. ä In order to remember the verified TORs, VO maintains following two sets of transactions for each transaction.
Verified Order-Based Transaction Scheduling Scheme
257
Definition 4(Set of preceding transactions and set of following transactions): For a transaction, Ti, there are two sets of transactions, PT(Ti) and FT(Ti), that are composed of transactions which precede and which others follow Ti, respectively. ä When a transaction, Ti, begins, VO initializes PT(Ti) and FT(Ti) to «. If VO decides to abort Ti, it removes PT(Ti) and FT(Ti). If Ti precedes Tj, VO sets PT(Tj) to PT(Tj) {Ti} PT(Ti). Now that Ti ³ PT(Tj), Tj comes to follow Ti and thus all the transactions in FT(Tj) are turned out to follow Ti. Accordingly, VO sets FT(Ti) to FT(Ti) {Tj} FT(Tj). While maintaining the sets, VO adheres following rule. Rule 2(Non-intersection of preceding and following transactions sets): For a transaction, Ti, VO maintains PT(Ti) ¬FT(Ti) to be « all the time. ä By virtue of such an adherence of non-intersection, a theorem with regard to 1SR is presented as follows: Theorem 1(Preservation of one-copy serializability with non-intersection of preceding and following transactions sets): A history H is 1SR if and only if PT(Ti) ¬ FT(Ti) is « for any transaction, Ti, in H. Proof: For an arbitrary set of three transactions, Ti, Tj, and Tk in a history, H, let us suppose that Tj ³ PT(Ti) and Tk ³ FT(Ti). As long as PT(Ti) ¬ FT(Ti) is «, Tk never precedes Tj and at the same time Tj never follows Tk. Thus, TORs among them are as follows: Tj Ti, Ti Tk, and Tk Tj never occurs. Accordingly, a partial history that is composed of Ti, Tj, and Tk is now 1SR. As Tj Ti, all the transactions that precede Tj precede Ti. As Ti Tk, moreover, all the transactions that follow Tk come to follow Ti as well. Accordingly, PT(Ti) FT(Ti) {Ti} composes an extended partial history that covers all the transactions in H to which Ti is relevant. As PT(Ti) ¬ FT(Ti) is « still, the extended partial history is now allowed to be 1SR. For any other arbitrary transaction, Tl, if PT(Tl) ¬ FT(Tl) is «, PT(Tl) FT(Tl) {Tl} is 1SR as well. As long as Rule2 is applied successfully for every transaction in H, every corresponding partial history in H is now 1SR. Consequently, H is 1SR. ä
3.2 Utilization of Verified Transaction Ordering Relationship 3.2.1 Selection of Versions For serving a read on multiversion database, providing the latest data version is most desirable. However, simple-minded adherence to the provision of the last versions could lead a history to violate TSR. Accordingly, mapping the read to a second-best version becomes inevitable once in a while. Fig. 1 illustrates such inevitability in a situation of scheduling a read. In Fig. 1, time goes from left to right and thus the fact that opi positions on the left side of opj says that opi precedes opj. In Fig. 1, mapping ri[x] to ri[xj] generates a TOR circle, Ti Tk Tj Ti: yl « yk and ri[yl] generate Ti Tk, rj[yk] generates Tk Tj and ri[xj] generates Tj Ti. According to Theorem 1, this circle violates 1SR. Fortunately, we can preclude the TOR circle by mapping ri[x] to a second-best version, xl, instead of xj in that xl « xj. Through ri[xl],
258
Y. Sohn and S. Moon
VO disposes Ti prior to Tj. It now substitutes Ti Tj for Tj Ti in the TOR cycle. Now that Ti Tk Tj and Ti Tj are established instead of Ti Tk Tj Ti, a TOR cycle among Ti, Tj and Tk has been precluded. Tl: wl[xl]wl[yl] T k: Tj:
cl
wk[yk]
ck wj[xj] rj[yk] cj Ti: ri[yl]
ri[xl]
Fig. 1. Preclusion of transaction ordering relationship cycle
Although VO preserves TSR at the cost of mitigating the requests of reading the latest versions, it must be capable of serving a transaction to read a version that is the latest, i.e., the most recent, one among the candidates for being selected. VO selects such an appropriate version in a way of obeying following two rules strictly. Rule 3 (Trusted version selection): • One-copy serializability preserving version selection: When VO receives a read, it searches for an appropriate data version until it can convince that providing the selected version never produces a TOR cycle. • Security preserving version selection: Suppose that VO is to select xj as the appropriate version for ri[x] in accordance with the rule of 1SR preserving version selection. At this time, if PT(Tj) has an active transaction, Tk, with L(Ti) > L(Tk), VO relinquishes xj. Instead, it selects the other version, xl with xl « xj and Tk ³ PT(Tl). In this case, xl is naturally the latest committed version among its committed siblings that precede xj. Naturally, 1SR must be preserved after xl was read. ä In case of security preserving version selection, VO relinquishes Ti’s reading xj since reading xj is highly apprehensive of opening a covert channel between Ti and Tk. If xj is selected for the appropriate version to ri[x], Tk comes to precede Ti since Tk ³ PT(Tj). If a new TOR, Ti Tk, is generated due to the fact that ri[zl] precedes wk[zk] or wk[zk] precedes ri[zl] with zl « zk, the TOR between Ti and Tk turns out to be a cycle among Ti and Tk. Since VO cannot assure that it will never receive such a sequence of TOR cycle provoking operations, it is obliged to cope with such a situation prudently in a way of providing a second-best data version to read in advance. By selecting xl instead of xj for the appropriate version to ri[x], VO becomes capable of avoiding Tk Ti. After ri[xl], although any writes of Tk may establish Ti Tk, they never induce a TOR cycle. As a result, such a write is allowed to be processed without being interfered by Ti. Accordingly, VO is now able to close any possible covert channels between Ti and Tk. By obeying rules of trusted version selection, consequently, VO is assured to produce TSR preserving histories for these situations. Note that, however, notwithstanding the application of trusted version selection, when VO can no longer preserve TSR, it unhesitatingly decides to abort a transaction that has requested TSR violating operation. However, such an abort never opens a covert channel. The rationale of this preservation of security is that all the transactions
Verified Order-Based Transaction Scheduling Scheme
259
involved in the situation of TSR violation have been cleared at the same security level. [13] proved this in detail. 3.2.2 Elimination of Redundancies Restricted accessibility due to given access control policy and maintenance of information about verified TORs enable VO to weed out redundant versions and TORs. This will be of great help to VO for lightening the burdens of maintaining multiple versions and tracing TORs. VO eliminates redundant versions by deciding whether the versions will never be read any more or not whenever it receives a commit. For this, VO applies following rules: Rule 4(Decision of selective redundant versions): Suppose that there are two adjacent siblings, xi and xj with xi « xj, and two sets of active transactions, STa and STb. In this situation, VO decides that xi is redundant version and xj is requisite version if STa STb is composed of all the active transactions and one of following requirements is satisfied: • Readably shading: xi and xj are readable to all transactions in STa STb, or • Unreadably shading: xi and xj are unreadable to all transactions in STa STb, or • Complexly shading: xi and xj are readable to all transactions in STa and at the same time they are unreadable to all transactions in STb or vice versa. Note that xi is readable to Tk if mapping rk[x] to rk[xi] does not violate TSR. ä When a new version, xi, is created, all the previous siblings of xi are sometimes turned out to be redundant ones. In this case, fortunately, maintaining only xi appears to be sufficient for x. VO achieves such a drastic elimination of versions by applying following rule: Rule 5 (Decision of multiple redundant versions): When a transaction, Ti, commits, VO decides that xi is a unique requisite version and all the siblings of xi are redundant ones if one of following conditions meets. • Absence of active high or equal transactions: For every active transaction, Tj, L(Ti) > L(Tj), or • Absence of active preceding transactions: All the transactions in PT(Ti) have already been committed. ä In order to eliminate redundant TORs, on the other hand, VO has a philosophy that all TORs concerned with a transaction whose preceding and following sets of transactions will never intersect are no longer needed to be remembered. For the purpose of definite decision of redundant TORs, VO now applies a rule presented as follows: Rule 6(Decision of redundant transaction ordering relationship): When VO receives a commit from a transaction, Ti, if there are no active transactions in PT(Tj) of a committed transaction, Tj, that precedes Ti, all TORs concerned with Tj are decided to be redundant ones. ä
4 Performance Evaluation We evaluate the performance of three STSs by means of simulation approach. The simulation is implemented with CSIM [3] discrete event simulation language and much of its model has been borrowed from [8].
260
Y. Sohn and S. Moon
4.1 Targets of Comparison We have excluded STSs that may infringe correctness from comparison since such STSs are liable to degrade integrity. Note that integrity is one of the major aspects of computer security. Among the STSs that are capable of preserving the correctness strictly, we choose Orange-Locking method [4] and Order-Stamping method [10, 12], hereafter OL and OS for short, to be compared with VO in that they are representative STSs in the environments of single version and multiversion databases, respectively. OL schedules transactions of the same security level under the control of conventional two phase locking scheme. When a write of low transaction conflicts with a read of high transaction, OL changes read-lock of the high transaction to orange-lock that implies the possibility of incorrect read. When the high transaction commits, OL investigates the serializability. If it detects a violation of serializability, it decides to abort the high transaction unilaterally. Accordingly, the possibility of aborts of high transactions comes to be higher than that of low transactions. When OS schedules transactions of the same security level, on the other hand, it applies conventional multiversion timestamp ordering scheme. For the active transactions of different security levels, OS maintains order-stamps grounded on their security levels. The policy enforces order-stamps of active high transactions to be smaller than those of active low transactions. OS decides the ordering relationships among transactions through the order-stamps and thus high transactions come to precede low transactions in respect of serializability. Accordingly, high transactions are forced to read outdated versions. Moreover, OS leaves alone the redundant versions. This enforces the database to be composed of unbounded number of versions. 4.2 Parameter Settings The computing resource environment is limited with 2 CPUs and 4 disks. The number of data items in a database is set to 1000 and mean number of operations in a transaction is set to 10 in order to observe interesting performance effects without requiring impossibly long simulation time [8]. The percentage of write operations is set to 10%, 20%, and 30% for observing sensitivities on conflicts. Security levels are ranged from 1 to 12. The number of concurrent transactions, named multiprogramming level, is set to 10, 20 through 200 in steps of 20. 2000 committed transactions are observed after discarding first 400 commits for each run and 10 replications have been applied. All the statistical data presented now have a confidence level of 95% and absolute error of 2%. 4.3 Simulation Results and their Interpretations The effects of multiprogramming level and percentage of write operations are presented in Fig. 2 and Fig. 3. VO_10 in the figures indicates the average results with write percentage of 10% and scheduled by VO. Abort ratio presented in Fig. 2 means the ratio of number of aborted transactions to total number of transactions submitted. As illustrated, the abort ratio of VO is lower than those of OS’s and OL’s for the most
Verified Order-Based Transaction Scheduling Scheme
261
part of multiprogramming levels and write percentages. The reason is that VO never aborts a transaction until it meets a situation that non-interfered execution of the selected transaction definitely violates 1SR. 0.8
VO_10 VO_30 OS_20 OL_10 OL_30
0.7
0.9 0.8
Recentness
Abort Ratio
0.6
1
VO_20 OS_10 OS_30 OL_20
0.5 0.4 0.3
0.7 0.6 0.5 0.4 0.3
0.2 0.1
0.1
0
0 10
20
40 60
80 100 120 140 160 180 200
10
Multiprogramming Level
0.5
0.4
40
60
80 100 120 140 160 180 200
1
VO OS OL
0.9 0.8 0.7
Recentness
0.35
Abort Ratio
20
Multiprogramming Level Fig. 3. Recentness (number of security levels = 1,2,3,8,12)
Fig. 2. Abort ratio (number of security levels = 1,2,3,8,12)
0.45
VO_20 OS_10 OS_30 OL_20
VO_10 VO_30 OS_20 OL_10 OL_30
0.2
0.3 0.25 0.2
0.6 0.5 0.4
0.15
0.3
0.1
0.2
0.05
0.1
VO OS OL
0
0 L12 L11 L10
L9
L8
L7
L6
L5
Security Level
L4
L3
L2
L1
L12 L11 L10
L9
L8
L7
L6
L5
L4
L3
L2
L1
Security Level
Fig. 4. Abort ratio Fig. 5. Recentness (write percentage = 10%,20%,30%, (write percentage = 10%,20%,30%, multiprogramming level = 10,20 through 200 multiprogramming level = 10,20 through 200 in steps of 20) in steps of 20)
Fig. 3 illustrates that recentness becomes poor as write percentage increases. Recentness of 1 means reading the latest version. The rationale behind this declination in recentness is that the increased write percentage draws up the possibility of TSR violation. In case of VO, however, such probability-based synchronization is restricted to the situation of detecting high potential of security infringement. VO is now proved to provide almost the latest versions.
262
Y. Sohn and S. Moon
Fig. 4 and Fig. 5 illustrate the effects of twelve different security levels on the performance of STSs. In the figures, L12 is the lowest and L1 is the highest security level. The abort ratios of VO and OS decrease as security levels go high in that low transactions are destined to conflict each other intensively. Owing to the lack of elaborate information about TORs, the conflicts of OS lead to by far more intensive aborts than those of VO. Transactions cleared at L12 and scheduled by OS now suffer from especially serious aborts. In case of OL, on the contrary, the abort ratio increases as the security levels of transactions go high. The reason is that read-locks of high transactions become more liable to be converted orange-locks as security levels of the transactions go high. Such increment of orange-locks naturally leads to the increment of abort ratio. The recentness of VO becomes poor as the security levels of transactions go high by applying the rule of security preserving version selection. However, such a declination in the recentness of versions provided by VO is very slight by virtue of referencing TORs that have been maintained elaborately. In case of OS, on the contrary, as transactions are unilaterally forced to be positioned at the ahead of serializable history whenever there are any possibility of TSR violation, almost all of the transactions are obliged to miss a chance of reading the latest versions. On the other hand, reading versions that are outdated excessively induces a problem of accumulating redundant versions in a database. The reason is that OS does not have any information from which it can convince that the versions will never be read any more. In case of VO, by virtue of eliminating redundant versions, only 2.4 siblings of a data item in average are required to be maintained in a database [13].
5 Conclusions We have proposed a new secure transaction scheduler, named Verified Orderingbased secure transaction scheduler (VO), that founds on multiversion database. It utilizes information, which elaborately describes ordering relationships among transactions(TORs), for the purpose of verifying whether the newly arrived operation definitely violates one-copy serializability or has a high potential of opening a covert channel. By referencing the information, VO becomes capable of guarding transactions against being aborted unnecessarily and reading excessively outdated data versions. By virtue of the elaborate information about transaction ordering relationships, in addition, VO is capable of deleting redundant versions and redundant transaction ordering relationships. The ability for perceiving such redundancies has the advantage of reducing the intrinsic overhead for maintaining multiple versions and accumulated transaction ordering relationships. The profit gained by maintenance of transaction ordering relationships has been proved through the performance evaluation. In principle, computer security is composed of three major aspects: secrecy, integrity, and availability. In this paper, we have mainly focused on achieving secrecy. Integrity and availability have been achieved without precise modeling from the viewpoint of security. We therefore hope to study the issues for modeling integrity and availability in multilevel secure information systems. Founded on the studies, we expect to develop a secure transaction scheduler whose capability of security-guarding has been strengthened by far.
Verified Order-Based Transaction Scheduling Scheme
263
References [1] [2]
[3] [4]
[5]
[6]
[7] [8]
[9]
[10]
[11]
[12]
[13]
D. E. Bell and L. J. LaPaduda, Secure Computer Systems: Unified Exposition and Multics Interpretation, Tech. Rep. MTR-2997, The Mitre Corp., 1976 E. Bertino, S. Jajodia, L. Mancini, and I. Ray, Advanced Transaction Processing in Multilevel Secure File Stores, IEEE Transactions on Knowledge and Data Engineering, vol. 10, no. 1, 1998, pp. 120-135. H. Schwetman, CSIM User’s Guide for Use with CSIM Revision 16, Microeletronics and Computer Technology Corporation, 1992. J. McDermott and S. Jajodia, ”Orange Locking: Channel-Free Database Concurrency Control Via Locking,” in B.M. Thuraisingham and C.E. Landwehr, ed., Proc. IFIP WG11.3 Working Group on Database Security, North-Holland, 1992, pp. 267-284. K.P. Smith, B.T. Blaustein, and S. Jajodia, Correctness Criteria for Multilevel Secure Transactions, IEEE Transactions on Knowledge and Data Engineering, vol. 8, no. 1, 1996, pp. 32-45. L.V. Mancini and I. Ray, Secure Concurrency Control in MLS Databases with Two Versions of Data, Proc. European Symp. Research in Computer Security,.Rome, Italy, Sept. 1996, pp. 204-225. P. A. Bernstein, V. Hadzilacos, and N. Goodman, Concurrency Control and Recovery in Database Systems, Addison-Wesley, 1987, pp. 25 – 45, pp. 143 – 166. R. Agrawal, M. J. Carey, and M. Livny, ”Concurrency Control Performance Modeling: Alternatives and Implications,” in Kurmar, V. ed., Performance of Concurrency Control Mechanisms in Centralized Database Systems, Prentice Hall, 1996, pp. 58 – 105. S. Jajodia, L. V. Mancini, and I. Ray, Secure Locking Protocols for Multilevel Database Management Systems, Proc. IFIP WG11.3 Working Group on Database Security, Como, Italy, July 1996, pp. 177-194. T. F. Keefe and W.T. Tsai, Multiversion Concurrency Control for Multilevel Secure Database Systems, Proc. IEEE Computer Society Symp., Research in Security and Privacy, Oakland, California, U.S.A, May 1990., pp. 369-383. V. Atluri, S. Jajodia, and T.F. Keefe, Multilevel Secure Transaction Processing: State and Prospects, Proc. IFIP WG11.3 Working Group on Database Security, Como, Italy, July 1996, pp. 79-98. W. T. Maimone and I.B. Greenberg, Single-Level Multiversion Schedulers for Multilevel Secure Database Systems, Proc. 6th Annual Computer Security Applications Conference, Tucson, Arizona, U.S.A., Dec. 1990, pp. 157-180. Y. Sohn, Confidential Concurrency Control for Secure Transaction Management in Database Systems: C3, Ph.D. Thesis, KAIST, Seoul, Korea, 2000, pp. 120 – 127.
