Atomicity and Isolation

Atomicity and isolation, are ensured in classical database transactions by using a commit protocol. This protocol is used to turn temporary storage into permanent storage - that is, the updates to the transaction's data are not visible until the commit protocol validates the stored data. Note that it is the presence of a commit record in the database log which effectively validates the transaction's data.

With secure transaction protocols, of course, we are not concerned with the correctness of data in persistent storage, but rather that data messages are not used or referred to unless their corresponding transaction has been properly committed. This can be accomplished by:

1. including a transaction identifier within each data message that effectively ties the message to the transaction
2. using a commit protocol to conclude each transaction
3. requiring a valid commit record for a transaction prior to the use of a message from that transaction.

The protocol that we define in this paper addresses the first two of these; the last would require the complete definition of the system to ensure that all message references are properly constrained.

Two other types of secure message atomicity protocols are discussed in [15]. Encryption-based protocols guarantee atomicity by having processes encrypt all messages that they send, and then using a trusted third party to distribute the keys once all messages are acknowledged by the receiver. Authority-based protocols guarantee atomicity by having processes send all transaction messages to the trusted third party, who will then forward them once all messages in the transaction have been received.

Neither of these is suitable, however, for transactions in which earlier messages must be read before a response can be sent. The use of a database-like commit protocol effectively enables this, since it allows write or send operations to depend upon previous read or receive operations.

In the next section we present a protocol that allows two processes to conduct secure transactions. This protocol extends the privacy, integrity and authentication properties of secure messages to also include causality, atomicity and isolation. This protocol is based on trustful relationships, so the properties are not provable to a trusted third party; they can, however, be confirmed by either party, which allows security violations to be detected prior to commitment of the transaction.

In later work, we extend this protocol to model distrustful and multi-party relationships, where the protocol can be used to prove correct transactions and to disprove incorrect transactions, and we provide an implementation of both models.