Secure one snapshot protocol for concurrency control in real-time stock trading systems

The Journal of Systems and Software 73 (2004) 441–454 www.elsevier.com/locate/jss

Secure one snapshot protocol for concurrency control in real-time stock trading systems Namgyu Kim a

a,*

, Songchun Moon a, Yonglak Sohn

b

Database Laboratory, Department of Management Engineering, Korea Advanced Institute of Science and Technology, Graduate School of Management, 207-43 Cheongryangri-dong, Dongdaemungu, Seoul 130-012, South Korea b Department of Computer Engineering, Seokyeong University, South Korea Received 9 December 2002; received in revised form 24 August 2003; accepted 27 August 2003 Available online 30 December 2003

Abstract To prevent any data from being accessed by unauthorized users, it is necessary for stock trading systems (STS) to use multilevel secure database management systems in controlling concurrent executions among multiple transactions. In STS, analytical transactions as well as mission critical transactions are executed concurrently, which makes it difficult to use traditional secure real-time transaction management schemes for STS environment. In this paper, we propose the read-down relationship-based secure one snapshot protocol (SOS) that is devised for the secure real-time transaction management in STS. By maintaining an additional one snapshot as well as working database, SOS blocks covert-channels without causing the priority inversion phenomenon. We introduce the process of SOS protocol with some examples, present the proofs of devised protocol, and then evaluate the performance gains by means of simulation method. Ó 2003 Elsevier Inc. All rights reserved. Keywords: Concurrency control; Covert channels; Secure real-time database systems; View consistency

1. Introduction In most secure database management systems, multiple users with mutually different clearance levels can access information with various sensitivity levels. This type of multiplicity is based on the access rule mechanism of so-called mandatory access control like BellLaPadula (BL) model (Bell and LaPadula, 1976), in which every data is accessed only by its authorized users. According to the BL model, a write operation should be allowed only when the security level of a transaction and that of target data are the same, while a read operation can be allowed when the security level of a transaction is higher than or equal to that of target data. Namely, the BL model allows only write-equal, read-equal, and readdown operations. Although the BL model controls

*

Corresponding author. Tel.: +82-2-958-3333; fax: +82-2-958-3604. E-mail addresses: [email protected] (N. Kim), scmoon@kgsm. kaist.ac.kr (S. Moon), [email protected] (Y. Sohn). 0164-1212/$ - see front matter Ó 2003 Elsevier Inc. All rights reserved. doi:10.1016/j.jss.2003.08.236

information flows explicitly by means of monitoring executions of read and write operations, illegal and indirect leakage of information may occur through covert channels (Lampson, 1973). The covert channels may be opened by a conspiracy among transactions with mutually different security levels. Congestion among transactions on shared data items may create storage covert channels. There is another type of covert channels so-called timing channels. The timing channels may be opened by any congestion of shared resources like CPUs. Two kinds of covert channels (i.e. timing channels and storage channels) should be considered separately. We consider only the storage covert channels in this paper, and the terms, covert channels, will only represent storage covert channels. In the literature, there have been so many researches on the ways to block covert channels. The non-interference approach (Goguen and Meseguer, 1982), the most prominent one among them, guarantees that every low-level transaction will never be interfered by any high-level transactions. Based on the number of versions

442

N. Kim et al. / The Journal of Systems and Software 73 (2004) 441–454

maintained, the researches can be divided into three schemes, single version-based scheme (George and Haritsa, 2000), restricted multiple version-based scheme (Mukkamala and Son, 1995), and multiversion basedscheme (Sohn and Moon, 2000). The single versionbased scheme maintains only a working database, while the multiversion based-scheme maintains one or more copied versions as well as a working database. The restricted multiple version-based scheme is similar to the multiversion-based scheme except that the former has limitation on the number of copied versions. Each scheme reveals trade-offs between the data availability and the cost of version management. Previous researches on database security have focused on specific and restrictive properties of transactions like real-time transactions (Ahmed and Vrbsky, 2002; George and Haritsa, 2000; Mukkamala and Son, 1995) or on-line analytical processing (OLAP) (Agrawal et al., 1987) transactions. However, because previous techniques are devised to meet only the bounded requirements of each application area, they are not applicable to a complex environment in which various transactions are concurrently executed. Stock trading systems (STS) is a typical example of the complex environment. STS has control of operational transactions for stock dealings as well as managerial transactions for analyzing the trend of the total stock market. Covert channels may have a crucial impact on secure operations of STS. For example, let us assume the following situation. A managerial transaction should be allowed to execute analytical queries on overall transactional histories in spite of transactional histories of one user must be protected against illegal access of other users. In this situation, sensitive information may be disclosed to an unauthorized end user by the conspiracy

between the managerial transaction issued by administrative user and the operational transaction issued by the end user. Example 1 describes this scenario. Example 1 (Illegal leakage of information via covert channels). There are 101 investors (F1 ; F2 ; . . . ; F101 ) in the stock market (Fig. 1). Let us suppose that F1 places an order to liquidate 10 000 shares of company x. Simultaneously, each and all of 100 investors (F2 ; F3 ; . . . ; F101 ) place orders to buy 100 shares of company x. In consequence, both buying and liquidating orders are the same at 10 000 shares. In this situation, let us assume that a managerial transaction Ta , issued by a managerial user Fa , is running for the purpose of analyzing the present status of the investment. Via conspiring with T101 , which is issued by F101 , Ta is able to send F101 the information that an order for liquidating 10 000 shares has been placed by one investor while orders for buying 10 000 shares have been placed by 100 investors. It means that Fa can, by holding or releasing locks on shared data repeatedly and systematically, send illegal information to F101 via indirect channels. These indirect channels may be opened by utilizing the amount of delay of F101 ’s executions. F101 can make the more profitable decisions than the other investors (i.e. F2 ; F3 ; . . . ; F100 ) since they only know the total amount of buying and liquidating orders. Consequently, F101 can gain undue arbitrage by means of this information. Example 1 describes an illegal leakage of information that may flow through indirect covert channels. To prevent scenario like above from actually happening, it is necessary for STS scheduler to block every type of covert channels during the concurrency control. In

Fig. 1. Illegal leakage of information via covert channels.

N. Kim et al. / The Journal of Systems and Software 73 (2004) 441–454

Example 1, operational transactions could be regarded as on-line transactional processing (OLTP) transactions while managerial ones could be regarded as OLAP transactions. Usually, OLAP transactions are issued by high-level users (e.g. executive managers or business analysts) (Priebe and Pernul, 2000), and most of OLAP transactions are long read-only ones, which extract various indexes and summarized data (Lam et al., 1998a,b). Main differences between OLAP and OLTP transactions are appeared in Table 1. The concurrency controller, which is devised for STS, must consider the following factors to meet requirements of both OLAP and OLTP transactions. First of all, OLTP transactions must be free from being interfered by OLAP transactions with high security levels. Next, even though OLAP transactions usually take long running time, STS scheduler should be able to prevent OLAP transactions from being aborted repeatedly by interferences of OLTP transactions. In addition, realtime properties, such as the deadline observation and the data freshness requirement, should not be sacrificed for the sake of security preservation. It is also required to minimize the cost of version management. The algorithm devised in this paper can be outlined as follows. A snapshot (SS) as well as a working database (WDB) is maintained for the purpose of managing realtime transactions while eliminating the threat of covert channels. The SS can be accessed only by read-down operations while the WDB may be accessed by readequal and write-equal operations. Data value in the SS cannot be updated directly by write operations because the SS could be accessed only by read-down operations. Data in the SS should be, therefore, refreshed with recent data in the WDB in order to prevent read-down operations from reading excessively stale data from the SS. We newly devise an efficient SS management algorithm by utilizing read-only characteristics of high security level transactions. The rest of this paper is organized as follows. Section 2 presents overviews on previous techniques, which are related to our work. In Section 3, we propose the readdown relationship-based secure one snapshot protocol (SOS) as a new secure real-time concurrency control protocol for STS. Section 4 provides the proofs of correctness for SOS. The performance gains of SOS are analyzed in Section 5. Finally, Section 6 concludes this paper. Table 1 Comparison between OLAP and OLTP transactions Feature Clearance level Occurrence Execution time Main operation

OLAP

OLTP

Analytical Usually high Unusual Usually long time is required Mostly read-down

Operational Usually low Very often Usually short and deadline critical Write as well as read

443

2. Related works 2.1. The real-time studies from a theoretical point of view The database management systems (DBMSs), which execute database operations with real-time constraints are generally called the real-time database management systems (RTDBMSs). In contrast to the conventional DBMSs, RTDBMSs must observe time constraints. The performance of RTDBMSs is evaluated based not only on the average transaction response time but also on how often transactions miss their deadlines (Purimetla et al., 1995). In addition, the evaluation must take into account how fresh the values of data are. It implies that the values of data in RTDBMSs should be taken from the external world with the least delay. In short, the RTDBMSs differ from the conventional DBMSs in that they are evaluated based on the temporal data consistency (Purimetla et al., 1995) and the frequency of deadline misses. The RTDBMSs can be viewed as value-added database management systems that support real-time transactions. The real-time transactions must be committed before their deadlines are expired to be of full benefit to the system. Such guarantees are, however, usually hard to ensure. In case a transaction’s deadline is not met, the transaction is called a tardy transaction. RTDBMSs can be divided into two categories based on how they handle the tardy transactions. Hard RTDBMSs do not accept any tardy transactions because they have negative values on the system. In soft RTDBMSs, on the contrary, tardy transactions may be tolerable even though they are not as good as timely committed transactions. It is argued in Ramamritham (1992) that with the current technology, it is very hard to provide an absolute guarantee on meeting the transaction deadlines, and therefore, RTDBMSs are mostly limited to the soft real-time systems. The executions of database transactions are usually data and resource dependent. Therefore, RTDBMSs have to deal with several issues such as predictability, consistency, concurrency control, transaction scheduling, time constraints, and resource management with the considerations of resource and data contention (Ramamritham, 1992). In RTDBMSs, transactions are ranked according to their priorities, and then resources are accessed by the transactions based on their priorities. Several attributes (Kao and Garcia-Molina, 1995) that may affect a transaction’s priority are appeared in Table 2. 2.2. Secure concurrency control algorithms for real-time transactions Lam et al. have proposed another concurrency control algorithm (Lam et al., 1998a,b) that deals with

444

N. Kim et al. / The Journal of Systems and Software 73 (2004) 441–454

Table 2 Factors of priority determination Attribute

Explanation

Criticalness Deadline Amount of unfinished work

The more critical a transaction, the higher is its priority The earlier its deadline, the higher is the transaction’s priority A transaction with less amount of unfinished work may be given a higher priority than a transaction with a large amount of unfinished work A transaction that already has a large amount of computation done may be given a higher priority A transaction that arrived early should be given a higher priority than those that arrived late Slackness measures how long a transaction’s execution can be delayed while still making it possible to meet the transaction’s deadline

Amount of computation already invested Age Slackness

read-only transactions and update transactions separately. Every read-only transaction previously declares that it will not issue any write operations. Lam et al. also demonstrated that data consistency could be preserved sufficiently by imposing only view-consistency instead of imposing conflict-serializability (Bernstein et al., 1987) for read-only transactions. Performance gains in adopting non conflict serializability but viewconsistency as a correctness criterion are illustrated in Example 2. Example 2 (Conflict-unserializable but view-consistent schedule). Let us suppose that there is a schedule that consists of a read-only transaction T1 and update transactions T2 and T3 (Fig. 2). A conflict-serializability graph (CSG) (Bernstein et al., 1987) for the schedule in Fig. 2 would be constructed as T1 ! T2 ! T3 ! T1 . On the contrary, a conflict of T2 ! T3 is not regarded as a dependency when the view consistency is concerned. It has legality based on the fact that T3 ’s operations do not reference any values that have been written by T2 . To preserve the view-consistency, read-from graph (RFG) can be used as a tool for validation. As far as RFG is concerned, every edge is appended to the graph if and only if there is a writeequal-read-equal conflict (i.e. a conflict between a writeequal operation and the following read-equal operation on the same data item) or a read-down-write-equal conflict (i.e. a conflict between a read-down operation and the following write-equal operation on the same data item) or a write-equal-read-down conflict (i.e. a conflict between a write-equal operation and the following readdown operation on the same data item). That is to say, a read-equal-write-equal conflict (i.e. a conflict between a read-equal operation and the following write-equal operation on the same data item) or a write-equal-writeequal conflict (i.e. a conflict between write-equal opera-

T1

r(x)

T2

r(y) r(x) w(x) c2

T3

r(y) c1 r(y) w(y) c3

Fig. 2. View-consistent schedule comprising T1 , T2 , and T3 .

tions on the same data item) does not append any edges to RFG. Accordingly, RFG for Fig. 2 may be constructed as T3 ! T1 ! T2 . For that reason, the schedule in Fig. 2 can be regarded as a legal one in respect of view consistency although it may be regarded as an illegal one in respect of conflict serializability. Example 2 indicates that considerable performance gains can be acquired by imposing the view consistency on read-only transactions while imposing conflict serializability on update transactions. SOS utilizes this result perceiving the fact that a high-level transaction can be regarded as a read-only transaction, because it may conflict with a low-level transaction only by issuing read-down operations. George et al. have proposed the dual approach (George and Haritsa, 2000), which handles the real time and the security requirements separately. The conflict among transactions with the same security levels was named as an intra-conflict and the conflict among transactions with mutually different security levels was named as an inter-conflict. Let us define two notations, LðTi Þ and LðxÞ, as the security level of a transaction Ti and that of data x respectively. When LðTi Þ > LðTj Þ ¼ LðxÞ, an inter-conflict may occur if there is a conflict between a Ti ’s read-down operation on x and a Tj ’s writeequal operation on x. By utilizing the fact that the covert channels may be opened only via inter-conflict, the dual approach adopts a non-interference principle for controlling the inter-conflict, while it obeys the real-time priority (RT-Priority) for controlling the intra-conflict. The RT-Priority is assigned in accordance with policies for deadline management. However, as shown in Example 3, this approach cannot be free from a phenomenon of priority inversion (Greenberg et al., 1993) when there is a conflict between Ti and Tj such that LðTi Þ > LðTj Þ and RT  PriorityðTi Þ > RT  PriorityðTj Þ. Example 3 (Priority inversion problem in dual approach). Let us suppose that TU acquires a read lock and a write lock on data x for its read and write operations respectively (Fig. 3). And then, a read lock on data x is requested by a transaction TC which has higher security level and higher RT-Priority than those of TU .

N. Kim et al. / The Journal of Systems and Software 73 (2004) 441–454

445

L(T L(TCC) >L(TU)) == L(x) = L(y) & RT-Priority(TC)) >> RT RT-Priority(T -Priority(TUU))

L(T L(TC1 = L(T C2)) == L(TC3 > L(T L(TUU))==L(x) L( x) C1)) = C3)) >

TC

TC1

TU

r(x) r(x)

w(x)

w( w(y) y)

Fig. 3. A priority inversion phenomenon.

r(x)

TC2

r(x)

w(x) t1

This phenomenon of so-called a priority inversion is caused by the contradictory requirements for the noninterference (Goguen and Meseguer, 1982) and the RTPriority. It is known that maintaining additional copied versions could prevent the priority inversion, because the restricted multiple version-based (Mukkamala and Son, 1995) or the multiversion-based (Sohn and Moon, 2000) protocols deal with an inter-conflict in a different manner. By noticing that every inter-conflict can be prevented in advance by maintaining one additional copied version as well as a working database, SOS can separate the requirements of real time from those of security. That is to say, it is sufficient for the SOS scheduler to consider only the intra-conflict because the SOS scheduler does not generate any types of interconflict, which cause the priority inversions and the covert channels. To manage real-time transactions without bringing about covert channels, secure real-time two-phase locking protocol (SRT-2PL) (Mukkamala and Son, 1995) was devised. To block covert channels, SRT-2PL maintains additional copied version, which is named a secondary copy, as well as a primary copy. The secondary copy could be accessed only by a transaction with higher security level than that of target data item, while the primary copy may be accessed in other cases. The newly updated data in the primary copy should be stored in extra queue temporarily. With the passage of time, the data value in the secondary copy needs to be replaced with the fresh value of the queued data. This data structure enables SRT-2PL to meet the secure realtime requirements by removing the inter-conflict in advance and by adopting the RT-Priority to handle the intra-conflict. SRT-2PL, however, shows degradation in concurrency of transactions, mainly due to the fact that every transaction must acquire all locks on data, which are planned to be accessed by the transaction, at the beginning of its execution. Furthermore, as soon as a write operation is executed, SRT-2PL appends the newly updated data in the primary copy into the queue in main

cC2

TC3 TU

Covert channels, from TC to TU , may be opened by the interference if a TC ’s read-down operation is executed immediately by aborting TU . To block the covert channels, the dual approach schedules the read-down operation of TC after TU ’s unlock on data x. As a result, for the benefit of preserving security, TC ought to be delayed by TU that has lower RT-Priority than TC .

cC1

t22

r(x)

cC3

t7

t8

cU t3

t4

t5

t6

Fig. 4. Data x’s long stay in temporary queue.

memory. This policy may produce side effects like the gradual lengthening of the queue, because the duration of data’s stay in the queue is increased with the passage of time. Example 4 illustrates this phenomenon (x is assumed to have a value of x0 as an initial value). Example 4 (Increment in the length of temporary data’s stay in queue). Let us suppose that there is a schedule which consists of data x and transactions TC1 , TC2 , TC3 , and TU (Fig. 4). By SRT-2PL scheduler, TC2 and TC3 read xU that has been written by TU while TC1 reads x0 (Fig. 4). For the purpose of making xU accessible to TC2 and TC3 , SRT2PL regulates that xU must be appended into the queue directly after the execution of TU ’s write operation. And xU can be removed from the queue only after TC2 and TC3 are committed. In result, xU ought to remain in the queue from t2 till t6 . On the contrary, SOS appends newly updated value into the queue after the commit of the transaction that has issued the write operation. Consequently, xU remains in the queue from t4 till t6 by SOS in Fig. 4. Consequently, SOS could make the duration of temporary data’s stay in the queue shorter than that of SRT-2PL. By SOS scheduler, TC3 can read xU although TC2 reads x0 . In Example 4, we can notice that SOS and SRT-2PL show an antinomy between the data freshness and the cost for queue management. The trade-offs are analyzed in Section 5. To say the whole simulation result briefly, the degradation of data freshness in SOS is revealed to be small when the large amount of reduction of queue management cost is considered.

3. Secure one snapshot protocol for real-time transaction management 3.1. Data structure To block covert channels without causing the priority inversion problem, SOS maintains a SS as well as a WDB. When LðTi Þ ¼ LðxÞ, Ti ’s read-equal or write-equal operations on x are executed in the WDB. On the

446

N. Kim et al. / The Journal of Systems and Software 73 (2004) 441–454

contrary, a Ti ’s read-down operation on x should read the value of x from the SS when LðTi Þ > LðxÞ. According to the BL model, an inter-conflict may occur only if there is a conflict between a read-down operation of a high-level transaction and a write-equal operation of a low-level transaction. SOS regulates that data x in the SS should be retrieved by the read-down operation of Ti when LðTi Þ > LðxÞ, while x in the WDB can be updated only by the write-equal operation of Ti when LðTi Þ ¼ LðxÞ. Consequently, SOS is able to block covert channels without causing the priority inversion problem by removing causal elements of the inter-conflict in advance. In the case of intra-conflict, previous concurrency control techniques can be used for transaction management without a threat of covert channels because they belong to the same security class. Data value in the SS cannot be updated directly by the write operation because the SS could be accessed only by the read-down operation. Data in the SS should be, therefore, refreshed with recent data in the WDB in order to prevent read-down operations from reading excessively stale data from the SS. In this paper, the term publish stands for the refreshing process and the notation Pubð Þ denotes its operation. PubðTi Þ, for example, performs the publication of every data, which has been written by a committed transaction Ti , from the WDB to the SS. SOS utilizes publication order graph (POG) for the purpose of determining appropriate publication order without violating data consistency. 3.2. Scheduling policy In this subsection, we discuss the details of the database operations under our protocol on the basis of locking method. When a write operation on data x is issued by a transaction Ti , it is certain that both x and Ti are at the same level, and therefore the operation is executed on the WDB. If data x in the WDB is unlocked, then the scheduler grants the lock to Ti and executes the operation. If x is read or write locked, then the destiny of the transaction is determined based on its priority. If the priority of Ti is higher than that of current lock holder, the scheduler grants the lock to Ti and executes the operation. In this case, the current holder should be aborted. On the contrary, if the priority of Ti is not higher than that of current holder, Ti should delay its execution until the current holder releases its lock. Since all affected transactions are at the same level as x and Ti , no security interference is caused by any of these options. When a read operation on data x is issued by a transaction Ti , two cases arise. When LðxÞ < LðTi Þ, Ti is expecting to execute a read-down operation on x in the SS. It should be noticed that the SS is accessed only by read-down operations. Therefore, no lock is required for this case and the operation is executed immediately. When LðxÞ ¼ LðTi Þ, on the contrary, the scheduler checks the status of the

WDB. If data x is unlocked or read locked, then the scheduler grants the lock to Ti and executes the operation. If x is write locked, then the destiny of the transaction is determined based on its priority. If the priority of Ti is higher than that of current lock holder, the scheduler grants the lock to Ti and executes the operation. In this case, the current holder should be aborted. On the contrary, if the priority of Ti is not higher than that of current holder, Ti should delay its execution until the current holder releases its lock. More formal proofs of correctness for the protocol are presented in Section 4. 3.3. Rules for arranging publication order POG specifies the publication order of transactions and it is constructed on the basis of read-from relationship (Lam et al., 1998a,b). When a transaction is committed, an edge should be appended to POG only if a read-from dependency is detected. Every publication ought to be executed in accordance with the sequential order of POG. For example, PubðTi Þ could be executed only after PubðTj Þ when Tj ! Ti is appeared in POG. In this subsection, we define Rules 1–3 for the process of appending edges to POG and Rules 4 and 5 for processing publications in appropriate order. Every Rule is invoked by commit operations of transactions and applied in order of Rules 1–5. Data consistency may be violated if transactions execute their publications immediately after their commits (Fig. 5). To begin with, let us take only TS and TC into consideration. TS reads data k which has been written and published by TC while it reads data t which has not been affected by TC yet. In this case, TS may be interpreted as reading inconsistent data because it is under the influence of the partial effect of TC . Data consistency can be validated by confirming that there is no cycle in read-from graph (RFG) (Lam et al., 1998a,b). In RFG for Fig. 5, we can detect the cycle between TS and TC that consists of edge TS ! TC on data t and edge TC ! TS on data k. To prevent this type of cycle from being created, SOS formulates a definition of Rule 1. Rule 1 is formulated with a notation of
N. Kim et al. / The Journal of Systems and Software 73 (2004) 441–454

447

L(TS) > L(TC)) == L(t) = L(k) > L(TU1) = L(TU2)) == L(TU3) = L(x) L(x) == L(y) L(y) == L(z) L(z) TS r(t)

r(k, x, z) cSS Pub(TSS)

TC w(k) r(x) w(t) cC Pub(TC)) TU1 TU2

w(y) r(z) w(x) cU1 Pub(TU1)) w(z) r(y) cU2 Pub(TU2))

TU3

w(z) cU3 Pub(TU3))

Fig. 5. Data inconsistency caused by immediate publications of TC , TU 1 , TU 2 , and TU 3 .

4. if ri ½x , wi ½x 2 Ti , then either ri ½x LðTi Þ ¼ LðxÞ, append Tj ! Ti to POG if rj ðxÞ LðTi Þ ¼ LðxÞ, append Tj ! Ti to POG if rj ðxÞ
committed because no edges need to be appended to POG in accordance with Rule 1 or Rule 2. Nevertheless, a cycle may be induced again in RFG when TS executes a read-down operation on z that has been written by TU 2 . In this case, the read-from dependency of TS ! TC has been delivered to TU 2 via dependencies of TC ! TU 1 and TU 1 ! TU 2 . Accordingly, the execution of PubðTU 2 Þ should be postponed until TU 1 is published. SOS formulates a definition of Rule 3 to prevent such a dependency from being delivered. Rule 3 (Edge for publication dependency by the intraconflict). For committed transactions Ti , Tj , and data x such that LðTj Þ ¼ LðTi Þ ¼ LðxÞ, append Tj ! Ti to POG if wj ðxÞ
448

N. Kim et al. / The Journal of Systems and Software 73 (2004) 441–454

L(T L(TSS) > L(TC)) == L(t) L(t) == L( L(k) k) > L(TU1) = L(TU2)) == L(TU3)) == L(x) = L(y) = L(z) TS r(t)

r(k, x, z) cS Pub(TS))

TC w(k) r(x) w(t) cC TU1

Pub(TC))

w(y) r(z) w(x) cU1

Pub(TU1)) w(z) r(y) cU2

TU2 TU3

Pub(TU2)) w(z) cU3 Pub(TU3))

Fig. 6. Postponed publications based on Rules 1–3.

TS

TC

TU1

TU2

TU3

Fig. 7. RFG for the schedule in Fig. 6.

Next, we define rules for executing publications in the order of dependencies in POG. Rules 1–3 should be invoked when a transaction Ti is committed. PubðTi Þ can be executed immediately after Ti ’s commit, if there is still no node for Ti in POG after Rules 1–3 having been applied. We define Rule 4 for such a case. Moreover, Ti can be published if there is no incoming edge to node Ti , even though Ti already exists in POG. Rule 5 should be applied to this case. Rule 5 is defined by a recursion for the case of cascading publications. Rule 4 (Immediate publication rule). Execute PubðTi Þ if the committed transaction Ti does not exist in POG. Rule 5 (Recursive publication rule). If committed the transaction Ti exists in POG but there is no incoming edge to itself, execute PubðTi Þ and remove all outgoing edges of Ti from POG. Rule 5 is recursively applied to Ti ’s dependents (i.e. following nodes) with modified POG. Operations of five rules for Fig. 6 are as follows. Edges, TS ! TC , TC ! TU 1 , and TU 1 ! TU 2 , should be appended to POG by Rules 1–3 respectively. As a result, TC , TU 1 , and TU 2 ought to postpone their publications until TS is published. On the contrary, TU 3 can be published immediately by Rule 4 because no edges for TU 3 need to be appended to POG by Rules 1–3. When TS is committed, Rule 5 should be invoked by TS because TS has no incoming edge to itself in POG. By adopting Rule 5 recursively, TC (i.e. TS ’s dependent) can be published after TS ’s publication. In this way, total order of publications may be arranged to TU 3 ! TS ! TC ! TU 1 ! TU 2 . 3.4. Pseudo-algorithm for SOS protocol The Rules 1–5 could be summarized in the following pseudo-code.

when transaction Ti is committed{ for every active transaction Tj such that LðTj Þ > LðTi Þ if rj ðxÞ LðTi Þ if rj ðxÞ LðTj Þ ¼ LðxÞ. Because SOS offers separate versions to read-down and write-equal operations, there is no possibility of the inter-conflict. h

N. Kim et al. / The Journal of Systems and Software 73 (2004) 441–454

Property 2 (Priority inversion-free property). There is no priority inversion in SOS schedule. Proof. Let us suppose the situation that a transaction Tj issues an operation on data x which has been already accessed by the Ti ’s operation and at least one of those operations is a write one. Only following two cases may raise a phenomenon of priority inversion. Case 1 (Requesting a write-equal lock on already readdown scheduled data). LðTi Þ > LðTj Þ ¼ LðxÞ and RT  PriorityðTi Þ > RT  PriorityðTj Þ. Case 2 (Issuing a read-down operation on already writeequal locked data). LðTi Þ ¼ LðxÞ < LðTj Þ and RT  PriorityðTi Þ < RT  PriorityðTj Þ. Case 1 describes the situation that Tj requests a writeequal lock after the Ti ’s read-down operation. In the data structure of SOS, a high-level transaction needs not to acquire any locks on low-level data because the readdown operation of the high-level transaction reads the data value from the SS. Therefore, Tj can acquire a write lock on x without delaying or aborting Ti . Much the same proofs can be extended to the Case 2. Therefore, any types of priority inversion cannot be detected in the schedule produced by SOS. h Lemma 1 (Conflict-serializability among the same level transactions). All transactions with the same security level are conflict-serializable. Proof. SOS has no additional restriction for scheduling transactions with the same security level. Therefore, conflict serializability among the same level transactions can be preserved by applying traditional concurrency control schemes. More formal proofs could be found in Bernstein et al. (1987). h Property 3 (View consistency among all committed transactions). All committed transactions are view consistent regardless of their security levels. Proof. Let us suppose the schedule which comprising transactions TC1 , TC2 ; . . ., and TCn and TU 1 , TU 2 ; . . ., and TUm such that LðTC1 Þ ¼ LðTC2 Þ ¼    ¼ LðTCn Þ > LðTU 1 Þ ¼ LðTU 2 Þ ¼    ¼ LðTUm Þ. The sequential execution order of TC1 ! TC2 !    ! TCn and TU 1 ! TU 2 !    ! TUm could be assumed without damaging generality because all transactions with the same security level are conflict serializable by Lemma 1. A schedule can be regarded to be view consistent one if its corresponding RFG has no cycle. We can, with generality, assure that the only following type of cycle might be constructed in RFG. Case (cycle with inter-conflicts): TCi ! TCj ! TUt ! TUk ! TCi (for 1 6 i < j 6 n, and 1 6 t < k 6 m).

449

In this case, TUk ! TCi describes that TCi reads the data written by TUk from the SS after execution of PubðTUk Þ. However, PubðTUk Þ ought to be postponed after PubðTCj Þ owing to the dependencies of TCj ! TUt and TUt ! TUk . It means that PubðTUk Þ should be executed after TCj ’s commit. Thus, it is not possible for TCi to read the data from the SS which has been written and published by TUk , because TCi ought to precede TCj according to the sequential order assumption among the same level transactions. Hence, the cycle like in this case cannot be constructed by SOS. In conclusion, it is guaranteed that all committed transactions are view-consistent regardless of their security levels. h

5. Performance evaluation We evaluate the performance of SOS series and SRT-2PL by means of simulation. In addition to SRT2PL, there are several other secure real-time concurrency control mechanisms such as the ones presented in Ahmed and Vrbsky (2002). In this simulation, SRT2PL is chosen for performance comparison because of its following characteristics. First of all, SRT-2PL tries to block covert channels completely without bringing about priority inversion problem. Its aim is exactly the same as that of SOS. Furthermore, SRT-2PL has similar data structure (i.e. two data versions) to SOS. On the contrary, the mechanism in (Ahmed and Vrbsky) considers covert channels among adjacent security levels as less dangerous while the ones among distant security levels as more dangerous ones. This approach cannot be directly compared to SOS using the same criteria for performance evaluation. For that reason, we evaluate the performance of SOS series and SRT-2PL only. SOS series comprises SOS_CL_CS, SOS_CL_VS, SOS_TO_CS, and SOS_TO_VS that have mutually different concurrency control protocols and correctness criteria. In brief, the terms CL, TO, CS, and VS represent Conservative Two-Phase Locking (conservative 2PL), Strict Timestamp Ordering (strict TO), ConflictSerializability, and View-Serializability respectively. SOS_CL_CS and SOS_CL_VS represent SOS schedulers that are implemented with conservative 2PL for guaranteeing conflict-serializability and view-serializability respectively. On the contrary, SOS_TO_CS and SOS_TO_VS represent SOS schedulers that are implemented with Strict Timestamp Ordering (strict TO) for guaranteeing conflict-serializability and view-serializability respectively. In this section, a performance evaluation for protocols in Table 3 is executed. Table 3 shows concurrency control algorithms and correctness criteria for SOS series and SRT-2PL.

450

N. Kim et al. / The Journal of Systems and Software 73 (2004) 441–454

Table 3 Specifications for evaluated protocols Protocol

Concurrency control

Correctness criterian for data publication

SRT-2PL SOS_CL_CS SOS_CL_VS SOS_TO_CS SOS_TO_VS

Conservative 2PL Conservative 2PL Conservative 2PL Strict TO Strict TO

Conflict-serializability Conflict-serializability View-consistency Conflict-serializability View-consistency

5.1. Input parameters and performance indices List of parameters and their values are presented in Table 4. Values in Table 4 have been set in accordance with Agrawal et al. (1987) for the purpose of conserving coherence with previous studies. These parameters settings might not be directly applicable to advanced modern systems. However, it should be noticed that the object of this simulation is to analyze relative discrepancies in performance between each of the protocols. We believe that these parameters are not insufficient to achieve the object of this simulation. In Table 4, default values for simulation are marked with underlines. For example, when we investigate the effect of db_size on performance indices, we set num_terms ¼ 200, tr_size_min ¼ 3, tr_size_max ¼ 10, update_pct ¼ 25, and max_c_level ¼ 8. Each transaction has the size between tr_size_min and tr_size_max. We run 2000 transactions for each simulation. Each simulation is executed three times with mutually different random seeds. The average values of three executions are used for performance analysis. We define following indices to evaluate performance gains of each protocol. resp_time: Average response time for each transaction resp_time/ops: Average response time for each operation

queue_ratio: Average ratio of temporary queue in main memory to database size stale_ratio: Average ratio of stale read count to total read count deadline_miss_ratio: Average ratio of the number of deadline missed transactions to that of total committed transactions To use stale_ratio as performance index, we should define the term stale first. We regard any data as stale if the value of data is not the most current one. For example, a data x in the SS is said to be stale if its value is not equal to the value of x in the WDB. This simulation has been performed by means of Microsoft Visual C++ 6.0 compiler and CSIM version 18 (Schwetman, 1992) on the Windows XP operating systems. 5.2. Simulation results and their interpretations In this subsection, we evaluate performance gains of SOS series and SRT-2PL in respect of resp_time, q_ ratio, stale_ratio, and deadline_miss_ratio. 5.2.1. Effect of version management policy on response time While SRT-2PL ought to base its version management policy only on conservative 2PL, SOS is able to be implemented with various concurrency control algorithms. That is to say, SOS can be implemented with strict TO as well as conservative 2PL. By adopting strict TO as a concurrency control algorithm, SOS can have advantages over SRT-2PL in respect of average response time. In all cases of our simulation, SOS_TO_VS shows shorter average response time than that of SRT2PL. Furthermore, the difference in resp_time becomes large when there is heavy contention among transactions. That is mainly due to the fact that the heavy

Table 4 List of parameters and their values System parameters num_cpus num_disks cpu_cc_delay obj_io_delay obj_cpu_delay Smin Smax

Two CPUs Four disks 7.5 ms 35 ms 15 ms 4 10

Number of cpus Number of disks CPU time for controlling concurrent execution I/O time for accessing an object CPU time for accessing an object Minimum slack factor Maximum slack factor

600, 800, 1000, 1200, 1400 and 1600 pages 30, 60, 90, 120, 150, 200 and 250 terminals 3 pages 4, 6, 8, 10, 15, 20 pages 5%, 10%, 15%, 20%, 25%, 30%, 40% and 50% 2, 4, 6, 8, 10 and 12 levels

Number of objects in database Number of terminals Size of smallest transaction Size of largest transaction Percentage of update operations Number of security levels

Database and transaction parameters db_size num_terms tr_size_min tr_size_max update_pct max_c_levels

N. Kim et al. / The Journal of Systems and Software 73 (2004) 441–454

120 100 80 60 40 20 0 4

6

8

10 tr_size_max

SOS_TO_VS

15

20

SRT_2PL

Fig. 8. resp_time with tr_size_max varied.

contention may bring about more serious delay of transactions in the case of SRT-2PL because SRT-2PL enforces every transaction to acquire all potential locks at the beginning of its execution. Fig. 8 illustrates effect of tr_size_max on resp_time for SRT-2PL and SOS_ TO_VS.

1.6 1.4 1.2 1 0.8 0.6 0.4 0.2 0

5.2.4. Effect of real-time policy on deadline observance It is known that the aggregate response time cannot effectively represent individual transactions deadlines. Therefore, deadline_miss_ratio should be examined to analyze deadline observance property of real-time transactions. In this paper, the deadline of a transaction is determined by Definition 2. Definition 2 (Deadline of a transaction). The deadline of a transaction Ti is defined as follows: DLðTi Þ ¼ ARRðTi Þ þ SLACK  EXP ðTi Þ

0.3 0.25

5

10

15

20 25 update_pct

SOS_CL_CS

SOS_CL_VS

SOS_TO_VS

SRT_2PL

30

40

50

SOS_TO_CS

Fig. 9. q_ratio with update_pct varied.

0.2 0.15 0.1 0.05 0 600

800

1000 1200 db_size

SOS_CL_CS

SOS_CL_VS

SOS_TO_VS

SRT_2PL

1400

1600

SOS_TO_CS

Fig. 10. stale_ratio with db_size varied.

stale_read

q_ratio

5.2.2. Effect of update timing on queue length Both of SRT-2PL and SOS series should store updated data value in temporarily queue for version management. SRT-2PL appends the newly updated data of the primary copy into the queue as soon as a write operation is executed. On the contrary, SOS appends newly written value into the queue only after commit of the transaction. Consequently, SOS can let temporary data remain in queue during shorter period than that of SRT-2PL. In all cases of our simulation, SOS_TO_VS has shorter average queue length than that of SRT-2PL. Furthermore, such difference in q_ratio gets large when there is heavy contention among transactions. Among SOS series, SOS_TO_VS and SOS_CL_VS show slightly lower q_ratio than that of SOS_TO_CS and SOS_CL_CS respectively. It should be noticed that every protocol in SOS series shows lower q_ratio than that of SRT_2PL. Fig. 9 depicts effect of update_pct on q_ratio.

5.2.3. Effect of update timing on data freshness To analyze temporal aspect of devised algorithm, we evaluate stale_ratio of SRT-2PL and SOS series. When compared to SRT-2PL, SOS series shows a little lower data freshness although they have lower q_ratio that that of SRT-2PL. SOS and SRT-2PL, therefore, show antinomy between data freshness and cost of queue management. Fig. 10 shows effect of db_size on stale_ratio for SRT-2PL and SOS_TO_VS. When more subdivided security levels are used, SOS may offer more stale value to the high-level transaction (Fig. 11). It means that SOS shows more desirable properties when not too many security levels are maintained.

stale_ratio

resp_time

160 140

451

0.16 0.14 0.12 0.1 0.08 0.06 0.04 0.02 0 2

4

6 8 max_c_level

SOS_CL_CS

SOS_CL_VS

SOS_TO_VS

SRT_2PL

10

12 SOS_TO_CS

Fig. 11. stale_ratio with max_c_level varied.

N. Kim et al. / The Journal of Systems and Software 73 (2004) 441–454 35

0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0

33 resp_time

deadline_miss_ratio

452

31 29 27 25 23 21

30

60

90

120 num_terms

SOS_TO_VS

150

200

250

19

1

2

3

4

5 c_level

SOS_TO_VS

SRT_2PL

6

7

8

SRT_2PL

Fig. 12. deadline_miss_ratio with num_terms varied.

Fig. 13. resp_time for each c_level.

where DLðTi Þ is deadline of Ti , ARRðTi Þ is the arrival time of Ti , EXP ðTi Þ is the expected execution time of Ti , and SLACK is the slack factor. In our simulation, SLACK is uniformly chosen from the range ½Smin ; Smax .

mentioned results are presented in Fig. 13 (the smaller value in x-axis denotes the lower security level).

Fig. 12 illustrates the effect of num_terms on deadline_miss_ratio for SRT-2PL and SOS_TO_VS. For both protocols, the deadline_miss_ratio is increased as the num_terms is increased. The rate of increase of SRT2PL is, however, shown to be larger than that of SOS_TO_VS. It means that SOS_TO_VS can meet deadline constraints better than SRT-2PL when the large number of terminals is contained in system. STS usually assumes heavy congestion of transactions. Therefore, SOS_TO_VS can be considered as more appropriate protocol for SOS environment than SRT2PL in the aspect of deadline observance. 5.2.5. Fairness analysis We performed fairness analysis to compare performance indices of each security level. Each transaction with mutually different security level shows similar stale_ratio in both cases of SRT-2PL and SOS series. Again, resp_time of each level appears not to be different from each other in SOS series. However, resp_time of low-level appears to be larger than that of high level in SRT-2PL. Such unfairness may occur because high-level transactions may issue more read-down operations than low-level ones do. It should be noted that read-down operations have no need to acquire locks on data because the read-down operation of a high-level transaction reads the data from the SS while every write operation is executed in the WDB. Consequently, SOS series are shown to have more desirable properties than SRT-2PL when the fairness is concerned. Above-

5.2.6. Performance evaluation in a simulated STS environment Besides basic assumptions (Agrawal et al., 1987), additional suppositions are appended to some input parameters for simulating the STS environment. We simplified security levels by assigning higher one to OLAP transactions and lower one to OLTP transactions. Each level has different assumptions for transactions such as transaction size or percentage of write operations. Table 5 summarizes such assumptions for an OLAP transaction (H_Tr) and an OLTP transaction (L_Tr). Because average response time has no connection with correctness criterion of version management, we analyze it only for SRT-2PL and SOS_TO_VS. For impartial comparison, we use a performance index resp_time/ops instead of resp_time, because we assume that H_Tr has larger transaction size than that of L_Tr. The result of resp_time/ops analysis is presented in Fig. 14. In Fig. 14, the average response time of H_Tr appears to be very long in SRT-2PL, when it is compared to SOS_TO_VS. Actually, SOS_TO_VS can yield performance gains in overall response time by reducing average response time of high-level transactions. The result of stale_ratio analysis for H_Tr, which indicates real-timeness is presented in Fig. 15. SOS series, as stated above, show slightly larger stale_ratio than that of SRT-2PL. However, stale_ratio of SOS_TO_VS appears not to be much different from that of SRT-2PL. Fig. 16 shows result of deadline_miss_ratio analysis, which indicates real-timeness also, in STS environment. It is

Table 5 Differentiated assumptions for transactions H_Tr and L_Tr H_Tr L_Tr

c_level

trans_size

update_pct

db_size

num_terms

SLACK

High Low

12 pages 5 pages

10% 90%

1600 pages 1600 pages

200 terms 200 terms

10 4

N. Kim et al. / The Journal of Systems and Software 73 (2004) 441–454

Fig. 14. Average response time per each operation.

Fig. 17. Queue length in the simulated STS environment.

actions while it guarantees similar deadline_miss_ratio to that of SRT-2PL for OLTP transactions. Finally, Fig. 17 shows the result of q_ratio analysis for SRT-2PL and SOS series. SOS series, on the whole, have small q_ratio while SRT-2PL has a large one. In particular, the difference of q_ratio between SOS_ TO_VS and SRT-2PL appears to be the largest one. Results of performance evaluation between SOS_ TO_VS and SRT-2PL in the simulated STS environment can be summarized as Table 6. On the ground of Table 6, we can notice that SOS_ TO_VS can reduce average response time of OLAP transactions and it can keep temporary queue very short. A difference in data freshness between SOS_TO_VS and SRT-2PL appears to be very small. Moreover, when it is considered that most stale reads may occur by OLAP transactions in which data freshness does not play a critical role, SOS_TO_VS can be regarded to have desirable properties for being applied to STS.

deadline_miss_ratio

Fig. 15. Data freshness in the simulated STS environment.

1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 30

60

90

120 150 num_terms

SOS_TO_VS_H_Tr SRT_2PL_H_Tr

200

453

6. Conclusions

250

SOS_TO_VS_L_Tr SRT_2PL_L_Tr

Fig. 16. Deadline observance in the simulated STS environment.

shown that SOS_TO_VS and SRT-2PL have mutually similar deadline_miss_ratio when L_Tr is concerned. However, SOS_TO_VS has lower deadlile_miss_ratio than that of SRT-2PL for H_Tr. This result could be interpreted that SOS_TO_VS can guarantee lower deadline_miss_ratio than that of SRT-2PL for OLAP trans-

There have been many works in the literature on a secure transaction management in real-time environments. In this paper, we proposed SOS protocol as a new secure real-time concurrency control protocol for STS. SOS can block the covert channels without giving rise to the priority inversion problem by removing causal elements of an inter-conflict. Moreover, the flexibility in adopting concurrency control algorithms enables SOS to reduce the average response time. SOS tries to minimize the cost of version management by maintaining only one additional copied version, and it can reduce the overhead

Table 6 Comparative results for performance evaluation in the simulated STS environment Protocol SOS_TO_VS SRT-2PL

resp_time/ops

queue_ratio

H_Tr

Overall

L_Tr

4.1324 17.3875

6.1031 11.0071

7.9430 5.2459

0.0706 0.6567

stale_ratio 0.0868 0.0682

deadline_miss_ratio (num_terms ¼ 200) H_Tr

Overall

L_Tr

0.8972 0.9988

0.5273 0.5638

0.1798 0.1687

454

N. Kim et al. / The Journal of Systems and Software 73 (2004) 441–454

of main memory management by keeping the temporary queue short during the stage of version update. We also demonstrated that the degradation in data freshness could be relieved by utilizing the characteristics of readonly transactions. Moreover, it should be noticed that most of the degradation in data freshness occurs to OLAP transactions in which data freshness does not play a critical role. It is also shown that SOS can meet deadline constraints better than SRT-2PL for OLAP transactions while SOS shows similar deadline misses to that of SRT-2PL for OLTP transactions in the simulated STS environment. This result says that SOS can improve availability for OLAP transactions while it still meets the deadline constraints of real-time OLTP transactions. The simulation results reveal that SOS has adequate properties for STS in which not only OLTP but also OLAP transactions are executed concurrently. However, when more subdivided security levels are used, SOS may offer more stale value to a high-level transaction. Consequently, SOS cannot guarantee desirable properties to the real-time systems when too many security levels are used. Moreover, it should be noticed that some OLAP applications such as fraud detection transactions for credit information companies require the most current data. Therefore, as far as these OLAP applications are concerned, trade-offs between the required data freshness and the availability should be examined carefully. The performance evaluation for SOS in more accurately simulated STS environment needs to be achieved in future works. References Agrawal, R. et al., 1987. Concurrency control performance modeling: alternatives and implications. ACM Transactions on Database Systems 12 (4), 609–654.

Ahmed, Q.N., Vrbsky, S.V., 2002. Maintaining security and timeliness in real-time database system. The Journal of Systems and Software 61, 15–29. Bell, D.E., LaPadula, L.J., 1976. Secure Computer Systems: Unified Exposition and Multics Interpretation, Tech. Rept. MTR-2997, The Mitre Corp., Belford, Massachusetts. Bernstein, P.A. et al., 1987. Concurrency Control and Recovery in Database Systems. Addison-Wesley. George, B., Haritsa, J.R., 2000. Secure concurrency control in firm real-time database systems. International Journal on Distributed and Parallel Databases 8 (1), 41–84. Goguen, J., Meseguer, J., 1982. Security policy and security models, Proc. IEEE Symp. Security and Privacy, IEEE Computer Society Press, California, pp. 11–20. Greenberg, I. et al., 1993. The Secure Alpha Study (Final Summary Report), Tech. Report ELIN A012, SRI International. Kao, B., Garcia-Molina, H., 1995. An Overview of Real-Time Database Systems, Advances in Real-Time Systems. Prentice Hall. Lam, K.W. et al., 1998. Using Separate algorithms to process readonly transactions in real-time systems, Proc. IEEE Symp. RealTime Systems, IEEE Computer Society Press, Madrid, pp. 50–59. Lam, K.Y. et al., 1998. On using similarity to process transactions in stock trading systems, Proc. IEEE Workshop on Dependable and Real-Time E-Commerce Systems, Colorado, pp. 13–19. Lampson, B.W., 1973. A note on the confinement problem. Communications of the ACM 16 (10), 613–615. Mukkamala, R., Son, S.H., 1995. A secure concurrency control protocol for real-time databases, Proc. 9th. IFIP WG 11.3 Working Conf. on Database Security, New York, pp. 215–230. Priebe, T., Pernul, G., 2000. Towards OLAP security design––survey and research issues, Proc. Third ACM International Workshop on Data Warehousing and OLAP, Washington, DC, pp. 33–40. Purimetla, B. et al., 1995. Real-Time Databases: Issues and Applications, Advances in Real-Time Systems. Prentice-Hall. Ramamritham, K., 1992. Real-time databases. International Journal of Distributed and Parallel Databases. Schwetman, H., 1992. CSIM Users’ Guide for use with CSIM Revision 16, Microelectronics and Computer Technology Corporation, Texas. Sohn, Y., Moon, S.C., 2000. Verified order-based secure concurrency controller in multilevel secure database management systems. IEICE Transactions on Information and Systems 83 (5), 1128– 1141.