Elsevier

Journal of Systems and Software

Volume 73, Issue 3, November–December 2004, Pages 441-454
Journal of Systems and Software

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

https://doi.org/10.1016/j.jss.2003.08.236Get rights and content

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.

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 Bell-LaPadula (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 read-down operations. Although the BL model controls 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 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 based-scheme (Sohn and Moon, 2000). The single version-based 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 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, Lam et al., 1998b). 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, real-time 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 real-time 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 read-equal 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 read-down 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.

Section snippets

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

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 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

Proofs of correctness

In this section, we provide theoretical bases for SOS by means of semiformal proofs.

Property 1 Covert channels-free property

A low-level transaction is never interfered by high-level one in SOS schedule.

Proof

By BL model, an inter-conflict may occur only between a Ti's read-down operation on data x and a Tj's write-equal operation on x such that L(Ti)>L(Tj)=L(x). Because SOS offers separate versions to read-down and write-equal operations, there is no possibility of the inter-conflict. 

Property 2 Priority inversion-free property

There is no priority inversion in SOS schedule.

Proof

Let us

Performance evaluation

We evaluate the performance of SOS series and SRT-2PL by means of simulation. In addition to SRT-2PL, there are several other secure real-time concurrency control mechanisms such as the ones presented in Ahmed and Vrbsky (2002). In this simulation, SRT-2PL 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.

Conclusions

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

References (17)

  • Q.N. Ahmed et al.

    Maintaining security and timeliness in real-time database system

    The Journal of Systems and Software

    (2002)
  • R. Agrawal

    Concurrency control performance modeling: alternatives and implications

    ACM Transactions on Database Systems

    (1987)
  • Bell, D.E., LaPadula, L.J., 1976. Secure Computer Systems: Unified Exposition and Multics Interpretation, Tech. Rept....
  • P.A. Bernstein

    Concurrency Control and Recovery in Database Systems

    (1987)
  • B. George et al.

    Secure concurrency control in firm real-time database systems

    International Journal on Distributed and Parallel Databases

    (2000)
  • Goguen, J., Meseguer, J., 1982. Security policy and security models, Proc. IEEE Symp. Security and Privacy, IEEE...
  • Greenberg, I. et al., 1993. The Secure Alpha Study (Final Summary Report), Tech. Report ELIN A012, SRI...
  • B. Kao et al.

    An Overview of Real-Time Database Systems, Advances in Real-Time Systems

    (1995)
There are more references available in the full text version of this article.

Cited by (0)

View full text