Transaction Security

Transaction security is of utmost importance in a client/server application or a Web service. Its objective is to support auditability , integrity, confidentiality, and accountability. It is likely that you're going to employ authentication and authorization as discussed in the previous section in combination with these four security techniques.

AuditabilityProof of Activity

An auditable system requires authentication and behavior tracking. Together, these enable the system to generate credible reports of activity that can be used in a variety of ways. Consider financial applications that use proof of activity to spot suspicious behavior. For example, a velocity check will spot a sudden higher-than-expected transaction volume coming from the same source, which may be an indication of fraud. Often, audit data is copied to an offsite location managed by a trusted third party, so that it can't be tampered with to remove evidence of transactions.

Three motivations dominate the creation of auditable systems. Reactive motivations include the need to respond to government or industry regulations or guidelines. Proactive motivations include the ability to create one or more unique features based on auditable data. Discovery motivations include the desire to analyze data over time in the hope of discovering interesting trends. Each of these are related to the other. A marketect may require that certain parts of the system be auditable to meet a key government regulation, but do so in a way that provides a significant edge over his competitors and provides interesting data for long- term trend analysis.

IntegrityPreventing Tampering and Alteration of Data

A digest function (also known as a one-way hash) takes a block of data and returns a small byte sequence that represents it. Good digest functions are very random, so that any change to the original data results in a different digest value and so that it is very difficult to find a different block of data that has the same value. Algorithms such as SHA1 and MD5 are well-known digest functions, and they've been exposed to public scrutiny to make sure they meet the above requirements.

Digests are normally encrypted with a private key, to create a digital signature. Anyone with the public key can decrypt them running the digest algorithm on the block of data to produce a new digest. If the digests match, the source data has not been altered . The reason we don't simply encrypt the data itself with the private key is that private key encryption is expensive and would take far too long for large blocks of data. The digest algorithm is very fast and produces a small result that is easy to encrypt. The signature for a block of data need not be attached to the data or even stored with it.

Generally speaking, integrity is easy to providethe code that implements the algorithms used is readily available, and much of it is open sourceso there's little excuse not to use it if there's a chance it will be needed. Integrity is often correlated with auditability, as a way of proving that the record of system behavior has not changed.

ConfidentialityKeeping Data Away from Those Not Entitled to It

Encryption also comes to the rescue, when you want to make sure that nobody can intercept your messages or the data stored in your system. Consider the difference between a log file that tracks system activity for billing and a message sent between two systems or a record that contains a credit card. In the case of a log file, you may only need to implement an integrity mechanism to prove that it was not altered. In the case of the credit card, you not only need to prevent a devious person from altering a message or record that contains the numberyou also need to prevent him from reading or accessing it in the first place!

The most common approach to encrypting data, and one used by systems such as Secure Sockets Layer (SSL), is a two-step process. The first step relies on symmetric key encryption, which is very fast. The sender of the message generates a symmetric key and uses it with an algorithm like RC4 to encrypt the data. In the second step the sender encrypts the symmetric key used in the first step with the public key of the receiver. Public key encryption is much slower than symmetric encryption, but the data being encrypted is so small that it happens very quickly. The sender then sends both the encrypted data and the encrypted key to the receiver. The receiver decrypts the key using his private key and then decrypts the data.

This process is a good balance of speed and cryptographic strength. Since SSL is very widespread, we recommend its use whenever possible. We also expect that SSL implementers will adopt even stronger cryptographic algorithms, such as Rijndael instead of RC4. Using the standard means that you get its benefits as it improves (you also get the drawbacks if it's cracked, but, although this is possible, we're comfortable in recommending this standard).

AccountabilityHolding People Responsible for Their Actions

One of the objectives of transaction security is to provide a mechanism for non- repudiation . That means that if you send a message to me, I can later prove that only you could have sent it. Public/private key operations alone permit nonrepudiation, but any operation that relies on public/private key operations will supply that capability. Read that sentence again, slowly. Suppose, for example, that a user logs into a multiuser system using a two-factor authorization scheme (such as a smart card with a password). Even though you have authorized this user, you may not be able to hold her accountable for her actionsunless your system requires strong authentication.

Strong accountability requires strong authenticationif all you need to send a message is a smart card containing a digital certificate, someone could steal your card and use it. On the other hand, if you need to enter a password as well, the chance that someone else can send the message decreases.

Digital signatures are used along with strong authentication to provide strong accountability. Nobody without your private key can send a message signed by it since all they have is your public key. That means that by saving a digitally signed message a service can later prove that you sent it.