IBM®
Skip to main content
    Country/region [select]      Terms of use
 
 
      
     Home      Products      Services & solutions      Support & downloads      My account     

IBM : developerWorks : Security : Security articles
developerWorks
Information assurance powwow, Part 2
PDF - 96KB e-mail it!
Contents:
The integrated IA model
The dimensions of the IA model
Anonymous, yet authenticated, communication
The model for communications
Domain-to-domain communications
Authentication
The protocols
Summary
Resources
About the author
Rate this article
Related content:
Information assurance powwow, Part 1
Encrypting with Stunnel
Mind your FAQs
More security resources
Delving deeper into IA at the West Point conference

Larry Loeb (larryloeb@prodigy.net)
Author, Secure Electronic Transactions
August 2001

In this two-part article on the IEEE Systems, Man, and Cybernetics Information Assurance Workshop, Larry Loeb takes a look at the evolution of Information Assurance (IA) and what it means from a security standpoint. Part 1 introduced the basic IA concepts, which are powerful and deserve more attention. Here in part 2, Larry describes a contextual view of the IA process, and goes on to describe some new research presented at the workshop.

The integrated IA model
W. Victor Maconachy, Corey D. Schou, Daniel Ragsdale, and Don Welch presented a paper at the workshop on an "integrated approach to information assurance modeling" (ISBN 0-7803-9814-9). The authors started out with the McCumber INFOSEC model described in 1991. The McCumber model can be illustrated with a three dimensional cube:

Figure 1: The McCumber INFOSEC model
Figure 1: The McCumber INFOSEC model

INFOSEC was defined as "protection of information systems against unauthorized access to or modification of information, whether in storage, processing, or transit, and against the denial of service to authorized users, including those measures necessary to detect, document, and counter such threats." Quite a mouthful there.

IA is an extension of the scope of these concepts. The National Security Telecommunications and Information Systems Security Committee has defined IA as "[i]nformation operations that protect and defend information and information systems by ensuring their availability, integrity, authentication, confidentiality, and non-repudiation. This includes providing for restoration of information systems by incorporating protection, detection, and reaction capabilities." This definition expands coverage, responsibilities, and accountability of security professionals to include proactive offensive activities along with traditional defensive measures.

Figure 2: Relationship between IA and INFOSEC
Figure 2: Relationship between IA and INFOSEC

IA is multidimensional and multidisciplinary, just like McCumber's INFOSEC model. The IA dimensions are information states, security services, security countermeasures, and time.

The IA model would now look like Figure 3 if one were to take a "snapshot" in time.

Figure 3: Information assurance model
Figure 3: Information assurance model

The dimensions of the IA model
Here I'll take a look at the IA dimensions of the cube and give a better definition of them.

The first axis is information states. Information can be stored, processed, or transmitted. Remember that information may also co-exist in two states. A simple example of this is a message transmittal: Though in transmission, the original message is also in storage at the sending site.

The second axis is the five security services: availability, integrity, authentication, confidentiality, and non-repudiation.

Availability is defined as the timely and reliable access to information for authorized users. This may be thought of as the utility part of security services. It includes all the non-glamorous things like back-up power supplies, off-site capabilities, and the like. Insuring availability can drain other system security resources; but this is a risk mitigation decision.

Integrity means protection against unauthorized modification or destruction, and is a matter of degrees of trust. It also includes accuracy, relevance, and completeness -- all of which together define the robustness of a system.

Authentication establishes "the validity of a transmission, message, or originator, or a means of verifying an individual's authorizations to receive specific categories of information," according to the NSA's National Information Systems Security Glossary. Spoofing IP addresses has caused increased awareness in this area.

Confidentiality, according to the glossary, is "the assurance that information is not disclosed to unauthorized persons, processes, or devices." Seems simple enough to grasp.

Non-repudiation may not be as simple to understand. This is defined as "the assurance the sender of the data is provided with proof of delivery and the recipient is provided with proof of the sender's identity, so neither can later deny having processed the data." In the non-IA world, this word has taken on a more sticky kind of meaning, specifically a legal term implying that neither side can back out of (repudiate) an agreed upon deal. In IA, it means an extension of the friend-or-foe identity classifications. It doesn't come with all the baggage of the commerce definition.

The third axis, security countermeasures, consist of technology, operations, and people.

Technology is the hardware, software, and firmware that make up a system or network. Stuff like firewalls and routers would be part of this element, which is constantly changing.

Operations include actual procedures performed by users, as well as what the system administrators impose on the system. Effects of software that can constrain things during specified system operations must be considered as well.

People are always a wild card, but can be characterized as the actions that people take. The relevant questions about the topic might be: Do the users follow the security policy? What happens when a new situation is introduced that is not covered by the policy?

And then, there is the fourth dimension of the model: time. In IA, time reminds us that everything we do is in a flux. Everything changes, all the time. As the model grows old, some seemingly essential elements of the original may have to be jettisoned or re-purposed due to ever-changing circumstances. In the last stages of a project, storage, confidentiality, and data availability would likely be more important than transmission or non-repudiation. New technology can greatly affect other dimensions of the model. Be ready to change when it is needed.

In summary, IA says that the interactions of the model's elements are just as important as, if not more important than, the components themselves. IA is real-time and dynamic, appreciating the "higher-order" effects of a framework change along with the obvious ones.

It's a process, not a product.

Anonymous, yet authenticated, communication
Cheryl Beaver, Richard Schroeppel, and Lillian Snyder showed off what they have been doing lately with "A Design for Anonymous, Authenticated Information Sharing" (ISBN 0-7803-9814-9). This kind of communication has been a desirable goal for some time, and has been attempted before. The main drawback is if you allow anonymity, you may also allow undetectable system abuse. Since it's been posited that the biggest security risks in a system are found inside the general user pool, this has been a real problem to design around.

In general, this kind of information sharing is done to keep the identity separate from the data that is being contributed by a user. This is hard to do on a network because even if identifying headers are stripped out before the message is transmitted, the path that the message takes may be observed, thus compromising the anonymity. The design goals that the authors had in mind reflect these sorts of concerns. The goals are: anonymity of message author, anonymous communications paths, authentication of the source, integrity of the data, and privacy, as well as protection against user abuse.

Remailers have been the typical cypherpunk to this kind of anonymity need. A remailer is a message store-and-forward system that sends a message through a networked server with a different address than that of the sender. Improving on this is a type 1 remailer where messages are nested and encrypted, and sent through a path of specialized re-encrypting routers called "mixes." To defeat tracking, the message is delayed by a certain number of other messages before being sent out. Spammers can defeat this kind of system, and both traffic analysis and replay attacks are possible. To get around this, a type 2 remailer (or "mixmaster") uses padding, delay, and reordering along with type 1 techniques.

The model for communications
The author's communication model is one of several loose groups called domains that are linked by communicating with a single central unit. If there are multiple users in a domain, intra-domain traffic may or may not need to be anonymous between the users. The model, while strict on communication between domains, is more lax in intra-domain messaging. These communications are always authenticated, but have the option for anonymity, revocable anonymity, or none at all. This two-level structure offers the ability to revoke messages anonymously at the domain-to-domain level.

Figure 4: High-level communications model
Figure 4: High-level communications model

The authors also assume a public key infrastructure is up and working for the group, and that each domain will have a public/private key pair available to it. This allows for secure message transmittal, since each domain has another domain's public key available to it.

Domain-to-domain communications
Domain-to-domain communications first puts a message into an identity-stripping pre-processor. The message then goes to a "mixmaster" variant called an "onion router." An onion router removes routing headers, creates anonymous communication routes, and provides some resistance to traffic analysis. This specific variant allows a "reply onion" to be included, which can get a reply back to the sender while preserving anonymity. Anonymous reply capability is needed to implement design goals. The onion router appends a random 128-bit reply key (RK), logs RK at the domain, and then encrypts the message and RK with the public key of the receiver. (Note that this system is encryption-agnostic, though the authors recommend adhering to NIST standards. That means triple-DES or other algorithms are equally acceptable as long as they are cryptologically strong.)

Authentication
Authentication usually involves symmetric keys. The proposed system requires a physical object (a CD) and knowledge of a token that changes daily. The CD (obtained from the known secure central location) contains at least 20,000 random 256-bit numbers. Each user has a copy of this, as well as a known hash value for the CD. This known hash authenticates to each user that their CD is valid.

Each day, the central location generates a random 128-bit token, encrypts it with the domain's public key, and sends it to the domain. A hash of the token is also published daily, allowing each domain to verify it has the correct token active.

The protocols
Let's examine the individual steps that make up each of the protocols decribed in the paper. The process is described as sequential steps, the way pseudo-code might be constructed. We'll look at the major activity protocols, along with their contexts.

Key generation and encryption
Input: Message, date, Daily Token, Random Number CD.
Output: Encrypted message, ENC-MSG.

  1. Generate an encryption key:
    1. Insert the Random Number CD.
    2. DONE=FALSE
    3. Repeat until DONE.
      1. Generate a random number, r between 1 and N (where there are N random numbers on the CD).
      2. Read in the r-th random number on the CD, nr.
      3. Compute h1 = Hash(nr) and h2 = Hash(T) (where T is the daily token).
      4. If the last 10 bits of h1 equal the last 10 bits of h2, then DONE=TRUE.
    4. The encryption key for this message is K = Hash(T//nr//T).
  2. Encrypt the message: E(K, message) Here E is a symmetric key encryption algorithm such as Rijndael.
  3. Create a file, ENC-MSG, containing the encrypted message, E(K, message), the index of the random number used in step 1;3, r, and the date.

The ENC-MSG must contain the index of the random number used in step 1c and the date so the recipient can reconstruct the key used for encryption in order to decrypt. The test in 1c will pass about 20 numbers on a 20,000-number CD, so that the CD does not have to be updated as often if that test were not there, even with group membership changing.

Decryption and authentication protocol

Input: Encrypted message file, ENC-MSG, Random number CD, Daily Token.
Output: Either decrypted message or invalid message warning.
  1. Upon receipt of ENC-MSG, read in the date, the index, r, and the encrypted message M.
  2. Let T be the daily token corresponding to the date.
  3. Let n be the r-th random number from the CD.
  4. Let h1 = Hash(n) and h2 = Hash(T).
  5. If the last 10 bits of h1 DO NOT equal the last 10 bits of h2, then reject the message as invalid.
  6. Otherwise, Let K = Hash(T//nr//T).
  7. If D(K,M) is an intelligible message then accept the message as valid. Here, D is the decryption algorithm corresponding to the encryption algorithm used in step 2 of the Key generation and encryption protocol.

A domain will handle revocation rather simply. If decryption fails, the central location generates a 128-bit revocation token, and encrypts the token and a copy of the message using RK. The domain then alerts whatever revocation mechanism it has, which decides if the message is legitimate. If not, the revocation token is sent to the central location and the message is marked "revoked."

Should there be no trusted central authority location, users can generate their own secure token using a distributed threshold secret sharing scheme. If tokens are generated this way, all communications can be done between domains. An encrypted message is sent to the target domain directly, and is decrypted at the domain to check for authentication. If the receiving domain returns the revocation token, the sending domain revokes the message by returning the revocation token to the receiving domain.

Summary
The 2nd annual IEEE/SMC IA conference was a success simply because it occurred. There are many security conferences, but these are usually grouped around specific classes of users, like the military. IA has broader concerns, and involves what all users want from computer security: that it works in the manner that is expected. Conferences like this serve a valuable purpose in bringing together people from different fields that might not otherwise be talking to each other. Such discussion can only lead to better ideas.

IA as a discipline will most likely have as great an effect on the organizational use of information as its predecessor (INFOSEC) did. Developers in this area should appreciate what sorts of parameters are constrained by use of IA, and using its precepts to guide their modeling and abstracting of secured information systems

Resources

About the author
Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been -- among other things -- a consulting editor for BYTE magazine and senior editor for the launch of WebWeek. He's been online since uucp "bang" addressing (where the world existed relative to !decvax), serving as editor of the Macintosh Exchange on BIX, and the VARBusiness Exchange. He's also written a book on the Secure Electronic Transaction Internet protocol. His first Mac had 128K of memory. His first 1130 had 4K, as did his first 1401. You can e-mail him at larryloeb@prodigy.net.



PDF - 96KB e-mail it!
What do you think of this article?
Killer! (5) Good stuff (4) So-so; not bad (3) Needs work (2) Lame! (1)

Comments?   Send us your comments or click Discuss to share your comments with others.


  About IBM  |  Privacy  |  Terms of use  |  Contact