CLASP Security Services

Revision as of 18:08, 2 June 2006 by Jeff Williams (Talk | contribs)

Jump to: navigation, search


There are several fundamental security goals that may be required for the resources in your system. For each resource in your system, you should be aware of whether and how you are addressing each concern throughout the lifetime of the resource. That is, each resource may have different protection requirements as it interacts with different resources. For example, user data may not need to be protected on the user’s machine but may need long-term secure storage in your database to prevent against possible insider attacks.

The fundamental security goals are: access control, authentication, confidentiality, data integrity, availability, accountability, and non-repudiation. In this section, we give an overview of each of the goals, explaining important nuances and discussing the levels within a system at which the concern can be addressed effectively.

Be aware that mechanisms put in place to achieve each of these services may be thwarted by unintentional logic errors in code.

Authorization (access control)


In most cases, one wants to establish the identity of either a communications partner or the owner, creator, etc. of data. For network connections, it is important to perform authentication at login time, but it is also important to perform ongoing authentication over the lifetime of the connection; this can easily be done on a per-message basis without inconveniencing the user. This is often thought of as message integrity, but in most contexts integrity is a side-effect of necessary re-authentication.

Authentication is a prerequisite for making policy-based access control decisions, since most systems have policies that differ, based on identity.

In reality, authentication rarely establishes identity with absolute certainty. In most cases, one is authenticating credentials that one expects to be unique to the entity, such as a password or a hardware token. But those credentials can be compromised. And in some cases (particularly in biometrics), the decision may be based on a metric that has a significant error rate.

Additionally, for data communications, an initial authentication provides assurance at the time the authentication completes, but when the initial authentication is used to establish authenticity of data through the life of the connection, the assurance level generally goes down as time goes on. That is, authentication data may not be “fresh,” such as when the valid user wanders off to eat lunch, and some other user sits down at the terminal.

In data communication, authentication is often combined with key exchange. This combination is advantageous since there should be no unauthenticated messages (including key exchange messages) and since general-purpose data communication often requires a key to be exchanged. Even when using public key cryptography where no key needs to be exchanged, it is generally wise to exchange them because general-purpose encryption using public keys has many pitfalls, efficiency being only one of them.

Authentication factors

There are many different techniques (or factors) for performing authentication. Authentication factors are usually termed strong or weak. The term strong authentication factor usually implies reasonable cryptographic security levels, although the terms are often used imprecisely.

Authentication factors fall into these categories:

  • Things you know — such as passwords or passphrases. These are usually considered weak authentication factors, but that is not always the case (such as when using a strong password protocol such as SRP and a large, randomly generated secret). The big problem with this kind of mechanism is the limited memory of users. Strong secrets are difficult to remember, so people tend to share authentication credentials across systems, reducing the overall security. Sometimes people will take a strong secret and convert it into a “thing you have” by writing it down. This can lead to more secure systems by ameliorating the typical problems with weak passwords; but it introduces new attack vectors.
  • Things you have — such as a credit card or an RSA SecurID (often referred to as authentication tokens). One risk common to all such authentication mechanisms is token theft. In most cases, the token may be clonable. In some cases, the token may be used in a way that the actual physical presence is not required (e.g., online use of credit card doesn’t require the physical card).
  • Things you are — referring particularly to biometrics, such as fingerprint, voiceprint, and retinal scans. In many cases, readers can be fooled or circumvented, which provides captured data without actually capturing the data from a living being.

A system can support multiple authentication mechanisms. If only one of a set of authentication mechanisms is required, the security of the system will generally be diminished, as the attacker can go after the weakest of all supported methods.

However, if multiple authentication mechanisms must be satisfied to authenticate, the security increases (the defense-in-depth principle). This is a best practice for authentication and is commonly called multi-factor authentication. Most commonly, this combines multiple kinds of authentication mechanism — such as using both SecurID cards and a short PIN or password.

Who is authenticated?

In a two-party authentication (by far, the most common case), one may perform one-way authentication or mutual authentication. In one-way authentication, the result is that one party has confidence in the identity of the other — but not the other way around. There may still be a secure channel created as a result (i.e., there may still be a key exchange).

Mutual authentication cannot be achieved simply with two parallel one-way authentications, or even two one-way authentications over an insecure medium. Instead, one must cryptographically tie the two authentications together to prove there is no attacker involved.

A common case of this is using SSL/TLS certificates to validate a server without doing a client-side authentication. During the server validation, the protocol performs a key exchange, leaving a secure channel, where the client knows the identity of the server — if everything was done properly. Then the server can use the secure channel to establish the identity of the client, perhaps using a simple password protocol. This is a sufficient proof to the server as long as the server does not believe that the client would intentionally introduce a proxy, in which case it may not be sufficient.

Authentication channels

Authentication decisions may not be made at the point where authentication data is collected. Instead it may be proxied to some other device where a decision may be made. In some cases, the proxying of data will be non-obvious. For example, in a standard client-server application, it is clear that the client will need to send some sort of authentication information to the server. However, the server may proxy the decision to a third party, allowing for centralized management of accounts over a large number of resources.

It is important to recognize that the channel over which authentication occurs provides necessary security services. For example, it is common to perform password authentication over the Internet in the clear. If the password authentication is not strong (i.e., a zero-knowledge password protocol), it will leak information, generally making it easy for the attacker to recover the password. If there is data that could possibly be leaked over the channel, it could be compromised.









Data Integrity




Most systems that export resources, either directly or otherwise, come with some implicit understanding that those resources will generally be accessible (available). If an availability problem is caused maliciously, it is known as a denial of service attack.

Note that data delays can be considered an availability problem. For example, imagine sending a message that says, “sell 10 shares of MSFT” that an attacker delays until the price has plummeted to the point where the user would no longer want to sell those shares.




