Multilevel security (MLS) has posed a challenge to the computer security community since the 1960s. MLS sounds like a mundane problem in access control: allow information to flow freely between recipients in a computing system who have appropriate security clearances while preventing leaks to unauthorized recipients. However, MLS systems incorporate two essential features: first, the system must enforce these restrictions regardless of the actions of system users or administrators, and second, MLS systems strive to enforce these restrictions with incredibly high reliability. This has led developers to implement specialized security mechanisms and to apply sophisticated techniques to review, analyze, and test those mechanisms for correct and reliable behavior.

Despite this, MLS systems have rarely provided the degree of security desired by their most demanding customers in the military services, intelligence organizations, and related agencies. The high costs associated with developing MLS products, combined with the limited size of the user community, have also prevented MLS capabilities from appearing in commercial products.

Portions of this article also appear as Chapter 205 of the Handbook of Information Security, Volume 3, Threats, Vulnerabilities, Prevention, Detection and Management, Hossein Bidgoli, ed., ISBN 0-471-64832-9, John Wiley, 2006.

Multilevel security (MLS) is an overloaded term that describes both an abstract security objective and a well-known mechanism that is supposed to achieve that objective, more or less.

Click here for a general introduction to MLS.

MLS: The Objective

A system or device achieves the objective of being "multilevel secure" if it can handle information at a variety of sensitivity levels without disclosing information to an unauthorized person. In a perfect world, this yields two more specific objectives:

• If a document contains classified information, then the system will prevent the document from being delivered to a user who lacks the appropriate clearance. For example, a document containing Top Secret information can't be given to a user who only has a Secret clearance. This is the information flow problem.
• If a document contains no information above a particular classification level, then it can be shared with users who have that clearance. For example, if a Top Secret user takes a Top Secret document and removes all information classified above the Secret level, then the system should allow Secret users to look at the document. This is the sanitization problem.

The information flow problem is very hard to solve through automated access restrictions. The sanitization problem is almost impossible to solve through automated access restrictions.

A device enforces MLS information flow if it can't be induced (accidentally or intentionally) to release information to the wrong person. The U.S. government has a body of laws and regulations that make it illegal to share classified information with people who do not possess the appropriate security clearance. In theory, an "MLS device" will automatically enforce those restrictions. Some defense officials refer to MLS devices as felony boxes since they can automatically commit felonies if they malfunction.

While it might seem easy to implement such a thing just by setting up the right access restrictions on files, this approach isn't reliable enough for large-scale use. For one thing, it's hard to reliably establish and review the permission settings for hundreds or even thousands of files and expect to have them all set correctly at all times. Another problem is that a malicious user could leak enormous amounts of classified information with a few simple keystrokes. Moreover, an innocent user could be tricked into releasing comparable amounts of classified information if subjected to a virus or other malicious software.

The sanitization problem is made difficult by two things. First, it assumes that software applications don't hide data from their users, and that simply isn't true. A Microsoft Word file carries all sorts of information, including reams of text that its owner may have tried to remove. There are even circumstances where cut-and-paste may copy deleted information from one Word file to another. The second problem is that it requires a certain level of intellect to distinguish more-sensitive informaiton from less-sensitive information. While classifying authorities may sometimes attempt to make it obvious which data is Top Secret, which is Secret, and which is unclassified, it is often impossible in practice to build an automated tool to identify sensitivity simply on the basis of the unmarked material.

MLS: The Mechanism

In practice, the devices we generally recognize as implementing "MLS" are based on a hierarchical, lattice-based access control model developed for the Multics operating system in 1975. In this model, the system assigns security classification labels to processes it runs and to files and other system-level objects, particularly those containing data. The mechanism enforces the following rules:

• A process is always allowed to read and write an object if the process’ label matches the object’s label (subject to other permissions, like those linked to file ownership).
• A process is allowed to read the data in an object if the object’s classification label is lower than the process’ label. For example, a “secret” process can read data from an “unclassified” object, but never vice versa.
• A process is never allowed to write data to an object when the object’s classification label is lower than the process’ label. This prevents programs from accidentally leaking classified information into files where unauthorized users might see the data. More importantly, it prevents users from being tricked into leaking information by trojan horse programs.

The mechanism is also referred to as mandatory access control because it is always enforced and users could not disable or bypass it. One of the reasons why you can't reliably enforce MLS (the objective) with conventional access control mechanisms is that such mechanisms are usually under the complete control of a file's owner. Thus the owner can accidentally or intentionally violate the access control rules simply by changing the permissions on a sensitive file. The MLS mechanism is mandatory, which means that individual users can't really control it themselves. Once a file is labeled "top secret," the MLS mechanism won't permit the user to share it with merely "secret" users or to mingle its contents with that of "secret" files. Once "top secret" information is mixed with "secret" information, the aggregate becomes "top secret."

The original motivation for building MLS mechanisms was the perception that it would make applications development safe from serious security risks. The notion was that applications programmers would be saved from the bother of having to worry about security labels. Existing applications would be able to handle labeled data safely and correctly without reprogramming. Even more important, programmers would not be able to sneak data between security levels by writing clever programs: the MLS protection mechanism would prevent any attempt to violate the most important security constraints on the system.

MLS: Hard to Implement

Although this basic MLS mechanism may seem simple to implement, it proved very difficult to implement effectively. Several systems were developed that enforced the security rules, but experimenters quickly found ways to bypass the mechanism and leak data from high classification levels to low ones. The techniques were often called covert channels. These channels used operating system resources to transmit data between higher classified processes and lower classified processes. For example, the higher process might systematically modify a file name or other file system resource (like the free space count for the disk or for main memory) that is visible to the lower process in order to transmit data.

Attempts to block covert channels led to very expensive operating system development efforts. The resulting systems were hard to use in practice and often had performance problems. While it's never been conclusively proven that you can't build a high performance system that avoids or blocks covert channels, there are no working examples.

The high cost of MLS systems was also driven by the high cost of security product evaluations performed by the US government.

MLS: An Impractical Mechanism

Although MLS (the objective) remains a requirement for many military and government systems, the objective is not met by MLS (the mechanism). The fundamental problem is that the mechanism only allows data to flow "upwards" in terms of sensitivity. So, automatic software can easily take unclassified data, mix it with secret data to make more secret data, and then with top secret data to produce more top secret data. There are a few applications in the intelligence community where this is a very useful property.

However, this upward flow works against modern notions of "information dominance" and "sensor to shooter" information flow. The modern concept is that technical intelligence assets should identify targets, pass the information to mission planners, who assemble a mission, and pass the mission details to tactical assets, who in turn share details with support and maintenance assets. The problem is that technical intelligence, mission planning, tactical assets, and support assets tend to operate at decreasing security levels. The flow of information goes the exact opposite of what the MLS mechanism allows.

This article by Rick Smith is licensed under a Creative Commons Attribution 3.0 United States License.

The LOCK project (short for LOgical Coprocessing Kernel) developed a "trusted computing system" that implemented multilevel security. LOCK was intended to exceed the requirements for an "A1" system as defined by the old Trusted Computing System Evaluation Criteria (a.k.a. the TCSEC or "Orange Book").

The project was modestly successful in that we actually deployed a couple dozen systems in military command centers. A major design feature of LOCK was type enforcement, a fine grained access control mechanism that could tie access restrictions to the programs being run.

The work was performed at Secure Computing Corporation in Minnesota.

LOCK technology, particularly type enforcement, live on in two 'children' that still exist:

• the Sidewinder Internet Firewall product line
• the "SELinux" security enhancements to Linux

Here are links to papers about LOCK and the Standard Mail Guard (the deployed version of LOCK).

• LOCK : An Historical Perspective
• LOCK trek: navigating uncharted space
• Cost Profile of a Highly Assured, Secure Operating System
• Constructing a High Assurance Mail Guard

I wrote the following message as part of a discussion on the old Firewalls mailing list in 1996. The message was part of a discussion on the use of MLS technology to protect Internet servers from attack. The basic concepts still apply in some ways, though the threats have evolved in many other ways.

The message opens with a summary of my background in MLS (through 1996, anyway) motivated by some questions raised in the discussion. Then it explains why, based on classical MLS reasoning, you can't use MLS to enforce separation between different Internet servers that share a common network interface. The article ends by explaining how an MLS-based Internet server can enforce the separation once we change our assumptions about how MLS works. An unspoken assumption of this discussion is that a "firewall" might be a large scale device that hosts a variety of "secure" services, like e-mail and DNS. Only a handful of firewalls (notably Secure Computing's Sidewinder) do anything like this today.

Someday I'd like to reconstruct the entire discussion from my own archives and from copies on the Internet, since it was a particularly satisfying one. It led to a paper I presented at ACSAC later that year. Click here to see the paper (PDF).

FROM: Rick Smith

DATE: 01/31/1996 15:09:50

SUBJECT: Re: Mandatory protection (was: product selection)

I think we`ve covered most of the issues so far in the Type Enforcement (TE) versus Multilevel Security (MLS) discussion pretty well, but there are two remaining issues that need clearing up.

I don`t think the unresolved topics arise from ignorance or a simple failure to communicate; we have a genuine and fully unintended culture clash.

The first is a matter of credibility. Since the relevance of anything else I say probably hinges on this, I`ll start here

"Does Rick Smith have a clue regarding MLS?"

There are several people at the National Computer Security Center and the MISSI Program Office that would be astonished by this question. Before moving to firewalls I was a key designer and the lead systems engineer on the SNS Mail Guard, one of the few MLS systems that comes close to being a turnkey device (I bring this up as evidence and not as a topic of Firewalls discussion - comment privately if you must). I`ve also done a variety of other MLS related analysis, design, and implementation tasks. So I do have some credentials.

But my background is entirely in high assurance MLS systems. Those are systems where MLS has only one meaning: obsessive protection of confidentiality in accordance with the Bell-LaPadula access control rules. Labels define barriers to information disclosure, and nothing in the platform architecture or services is permitted to compromise confidentiality. My statements on what MLS systems can and can`t do are based on the implications of highly assured confidentiality, not on some "strawman" MLS notion nor on "misconfigured" MLS systems.

That`s where the culture clash comes in. My colleagues in this discussion are using B1 MLS systems. These are systems where confidentiality protection is not pursued to such an extreme. This is *not* intended as a put-down, especially in the firewalls environment. Firewalls don`t need obsessively strong confidentiality. They need integrity protection. That`s why we put TE in Sidewinder and left out MLS -- we see MLS as a confidentiality mechanism and that`s not what we needed. But if you`re using MLS for mandatory protection and don`t have an obsessively strong confidentiality objective, then the picture changes a bit.

Here`s how this relates to the last open technical issue:

"Can MLS systems protect Internet servers from one another?"

I`ve always recognized that MLS systems can impose mandatory protection bariers between processes by using levels, categories, and compartments, but I still concluded "No." This is based on my view of high assurance MLS obsessed with confidentiality. The argument goes as follows:

1. Typical Internet TCP/IP traffic does not contain labels.
2. The network interface in an MLS system is always assigned a label.
3. If a network interface receives a packet that does not already contain a label, then the packet must be assigned the network interface`s label.
4. All packets sent or received as typical Internet TCP/IP traffic carry the same label (from 1, 2, 3). Call this label the "Internet Label."
5. If two processes have the same label, there is no way to enforce mandatory MLS protection between them.
6. Every network server process is assigned a label.
7. A network server process can only send and receive packets if the packets` labels are identical to the label of the network server process.
8. Any network server process that handles Internet traffic must be assigned the "Internet Label" (from 4, 7).
9. All Internet server processes must be assigned the "Internet Label" (from 6, 8).
10. You can`t enforce MLS between Internet servers (from 5, 9).

I suspect our misunderstandings are tied to statement 3) above. On Sidewinder we can associate TCP/IP port numbers with separately labeled domains in the TE system. The only way you can get a similar result in an MLS system is to associate TCP/IP port numbers with MLS confidentiality labels. For example, the B1 system might define a category or compartment label for "Mail" and restrict Port 25 traffic to processes with the Mail label. If so, this changes how statement 3) is phrased, and completely changes the conclusion.

The problem is, you can`t assign MLS labels that way if you`re obsessed with confidentiality. I can think of three reasons immediately as to why not:

1) Port numbers aren`t confidentiality labels and aren`t intended to be. There`s no reason to believe that any other system you`re communicating with is going to keep traffic separte according to port numbers. This means you can`t depend on confidentiality, the prime objective. This leads to the next reason:

2) Treating a port number like a label establishes an uncontrolled data channel between processes with different labels, independent of the label enforcement rules. This is because there`s nothing in the TCP/IP operating concept to prevent one such process from opening a connection directly or indrectly to a process on the same system associated with a different port number, bypassing the MLS barriers between differently labeled processes.

3) You can almost certainly construct a nifty timing channel between two processes that have different labels/ports and share the same TCP/IP stack. So even if the rest of the network behaves, there are ways to circumvent the labels.

But the bottom line answer to the question, in the context of *firewalls* and the irrelevance to them of a high assurance obsession with confidentiality, appears to be "Yes, If."

IF the vendor puts in the trusted code to associate different port numbers with different MLS process labels, THEN their firewall *can* enforce mandatory MLS protection between Internet servers. It`s not clear that a firewall is "misconfigured" if this degree of protection is omitted, but a thorough implementation really should include it. So, if you`re buying an MLS based firewall, look for this feature.

Peace?

Rick.

smith at secure computing corporation

This article by Rick Smith is licensed under a Creative Commons Attribution 3.0 United States License.

I first encountered the term cross domain security (or cross domain systems, or cross domain solutions, or just CDS) at a workshop in the late 1990s. We were discussing the problem of how to share information with coalition forces even though different countries had different, treaty-based access to US defense information. Even worse, there were coalitions that contained countries who were not on the best of terms (like Japan and Korea).

These days the term has often replaced MLS in the defense community. Some argue that the term has changed in hopes that the community can lower the assurance requirements, thus putting information at risk. Time will tell if this is indeed true.

For a more recent view of this topic, visit my Security Evaluations page.

Date: 4/20/2005.

In 1999, I tracked down every report I could find of a product that had completed a published, formal security evaluation in accordance with trusted systems evaluation criteria. This led to some preliminary results. At the Last National Information Systems Security Conference (23rd NISSC) in October, 2000, I presented a paper (PDF) that surveyed the trends shown in the previous 16 years of formal computer security evaluations.

I collected all of my data in an Excel 97/98 spreadsheet that contained an entry for every evaluation I could find through the end of 1999. At the moment the spreadsheet includes the reported evaluations by the United States (TCSEC/NCSC and Common Criteria), United Kingdom (ITSEC and Common Criteria), Australia, and whatever evaluations were reported from Canada, France, and Germany by the US, UK, and Australian sites. I am not convinced that this is every published evaluation that took place, but it's every report I could find.

Key Observations

• Product evaluations still take place: There was a big surge of evaluations in 1994 followed by a drop, but the number of evaluations never fell back to 1993 levels, and a few dozen still take place every year.
• Few products actually bother with evaluation: Even the most limited estimates would suggest that hundreds of security products enter the market every year, yet it appears that no more than a tenth of them ever enter the evaluation process.
• Flight from the US: Despite the fact that the US pioneered security evaluation and US companies arguably dominate the international market in information technology, most products, including US products, are evaluated overseas. The trend is increasing in this direction. This is probably because evaluations in the US tend to be far more expensive and time consuming.
• Popularity of middle ratings: The trend in the vast majority of evaluations is to seek EAL 3 or EAL 4 ratings, or their rough equivalent in ITSEC ratings. Very few go for lower or higher ratings. The higher ratings appear to all go to government or military specific products.
• Network security products (including access control) have come to dominate evaluations: originally, operating systems were the main type of product evaluated. Then the trusted DBMS criteria were published, and several DBMSes were evaluated. However, other products like access control products, data comm security devices, and networking devices like firewalls have come to dominate evaluations in recent years.

For additional insight, I'd suggest looking at Section 23.3.2 of Ross Anderson's book Security Engineering, which describes the process from the UK point of view. Ross isn't impressed with the way the process works in practice; while the process may be somewhat more stringent in the US, the US process simply produces different failure modes.

I would be thrilled if anyone interested in a weird research project would use my spreadsheet as a starting point to further analyze the phenomenon of security evaluations. There are probably other facts to be gleaned from the existing data, or other information to be collected. As noted, I stopped collecting data at the end of the last century.

The exclusive or operation - a logical function applied to binary bits, like AND, OR, and NOT - is a fundamental encryption technique. It is often used in stream ciphers, which are widely used in web browsers when connecting to secure web servers.

When used properly, this technique provides strong protection. In fact, it is the basis for the one-time pad, the only provably uncrackable encryption. However, this protection is easily eroded if the cipher is not used correctly.

Xor is a trivial operation for computer logic to perform (click here for the details). The operation often appears as a built-in machine instruction so that software can perform it in a single machine operation.

If Alice wants to send a secret message to her friend Bob, she takes the sequence of bits in the message (the plain text) and a sequence of bits known only by her and Bob - the key. To encrypt, she combines the plain text and the key, bit by bit, using xor.

In a one-time pad, Alice and Bob must use a different set of secret, randomly generated bits for every message they exchange.

In a stream cipher, Alice and Bob share a much smaller number of secret bits and use them to generate a long, hard-to-guess sequence of bits. The stream cipher relies on a cryptographic algorithmto generate that long sequence from a small, shared secret. This generated sequence is then combined with the message using xor.

A Graphic Example

Below we have the handwritten message "Send Cash" embedded in a 128 by 128-bit image. Black indicates no color, so the black text in the image contains zero bits, and the white space contains 1 bits. For a key, we have collected a 128 by 128 matrix of random bits. In fact, the bits come from a web site, random.org, that uses radio noise to generate random data for experiments like this. We will combine the two matrices using xor:

When we apply xor bit-by-bit to the two matrices, we get the following 128 by 128 matrix of encrypted bits:

Yes, this looks like nothing more than a mottled gray block, and it doesn't look a lot different from the gray-block image of the encryption key. If we look closely, the actual bits are different. Here is a closeup of the upper-left corner of the key bits and the encrypted bits. Most of the bits are identical in the two closeups. The bits in the lower-right closeup are different.

In the closeup, most of the image is the same in both the key and the ciphertext. The plaintext "Send Cash" message consists of white space (one bits) except where the black letters (zero bits) appear. The xor operation combines black bits in the key with white bits in the message to yield black bits in the encrypted message. 

The closeup's lower right corner captures part of the letter "S" in the message. The black plaintext combines with black key bits to yield white. White key bits are also reversed by the black plaintext.

Even though the key image and the encrypted message look similarly gray, they contain different bits. That difference hides the encrypted message.

Try it yourself

These example images are 128 by 128 bit maps in GIF format. If you have a program that can read GIF files, save them as bit maps, and apply the xor operation bit-by-bit, then you can easily repeat this operation. The examples here were processed by Matlab, a commercial package, but there are numerous other packages that can reproduce the example.

Download these images:

• "Send Cash" message (m)
• Encryption key (k)
• Encrypted "Send Cash" message (m ⊕ k = e)

If you apply the xor operation to the first two bit maps, you produce the third. If you combine the key with the encrypted message (k ⊕ e), you will reproduce original "Send Cash" message.

Exclusive-Or - ⊕ - xor

The following table shows how the xor operation transforms individual bits. Let m be a bit from the plain text message, and kbe a bit from the key. The ⊕ column shows the resulting bit.

We can also describe the xor operation in terms of traditional logic operations AND, OR, and NOT. Here we use "C" programming language notation: NOT = !, AND = &, OR = |.

(!m & k) | (m & !k)

To decrypt a message, Bob takes his own copy of the key bits, and applies the same xor transformation to the message, bit by bit.

The one-time pad is the only encryption technique that has been mathematically proven to be uncrackable. While hard to use, it has often been the choice for highly sensitive traffic. Soviet spies used one-time pads in the 1940s and -50s. The Washington-Moscow "hot line" also uses one-time pads. However, the technique is hard to use correctly.

To use a one-time pad, Alice and Bob must produce a huge number of random bits and share them secretly. When Alice has a message to send to Bob, she retrieves a number of random bits equal to the length of her message, and uses them to be the message’s key. She applies the exclusive or operation (xor) to the key and the message to produce the encrypted message.

The key must be exactly the same size as the message. The key must also consist of completely random bits that are kept secret from everyone except Alice and Bob.

When Bob receives the message, he retrieves the same bits from his copy of the random bit collection. He must retrieve the same random bits in exactly the same order that Alice used them. Then Bob uses the sequence of random bits to decrypt the message. He applies the xor operation to the message and the key to retrieve the plain text.

When properly used, it is mathematically impossible to crack a message encrypted by a one time pad. This was first described by Claude Shannon in the 1940s as part of the development of information theory. A one-time pad is impossible to crack because knowledge of the cipher text does not reduce uncertainty about the contents of the original, plain text message.

One time pads are not generally practical:

• It’s hard to provide enough randomly-generated bits to both Bob and Alice to protect all anticipated messages.
• It’s hard to keep that much data secret.
• It’s hard to use the bits in the right order at both ends.
• It’s hard to avoid reusing the bits by mistake.

Web browsers and servers use conventional stream ciphers like RC4 instead of one time pads because they are much easier to use and provide very strong, if not provably impenetrable, security.

When Soviet spies used one-time pads, they used a decimal number code instead of binary bits. In binary, the xor operation is essentially an "add without carry" in which we discard the overflow: in particular, 1+1=0. In a decimal code, add without carry just discards the overflow, as in 7+7 = 4, or 8+8=6. Decryption used the opposite "subtract without borrow" with the same set of digits used as the key. 

The one-time pads were printed up in tiny books, and the spies would discard pages of numbers as they were used in messages. Marcus Ranum has a photo of such a book in his One-Time PAD FAQ.

There is a lot of confusion about one-time pads (see the article). Some vendors use the term simply because one-time pads are provably secure, and they hope that the name by itself will convey impenetrability to their product. Such products are called snake oil in the crypto community. Even worse, some people on the Net will try to explain one-time pads and get it wrong. The hardest thing for many people is the notion of entropy or true randomness. No, you don't get random numbers from Excel!

Related Ciphers

Here are some other cipher terms that often appear in conjunction with one-time pads:

• Vigenère cipher - a code in which each letter in the plain text is replaced by a corresponding letter taken from one of several different alphabets. The different alphabets are usually constructed by shifting the plain text alphabet by different numbers of steps. The "key" identifies the sequence of alphabets used. Cipher discs are often used to implement Vigenère ciphers. 
• Vernam cipher - A Vigenère cipher in which the alphabet consists only of the binary values 0 and 1. Vernam's original cipher used a repeating key (reusing the bit stream) but the cipher remained easy to break even with very long keys. He subsequently developed a version where the key did not repeat; this was the first implementation of a one-time pad.
• Stream cipher - a Vernam cipher in which the key is generated by a pseudo-random number generator, to eliminate the repeating bit stream.

References

Ranum, M. (1995) One-Time-Pad (Vernam's Cipher) Frequently Asked Questions. web site.

Shannon, C. (1949) Communication Theory of Secrecy Systems. Bell System Technical Journal 28 (4): 656–715.

Take a look at the following image. You should see two different 'messages' here.

  Two messages

This particular mis-mash of messages reflects the failure of otherwise strong cryptography: the improper implementation of a one-time pad or a stream cipher.

This same mistake let American cryptanalysts decode thousands of Soviet spy messages in the 1940s and -50s. The decoded messages helped uncover espionage at the Manhattan Project. The Soviets made the mistake of reusing the keys for their one-time pads.

The mistake has also cropped up with stream ciphers used on computer networks. If you use the same stream of bits to encrypt two or more different messages, an attacker can eliminate the encryption by combining the two messages. Particularly notorious examples include the tragically misnamed Wireless Equivalent Privacy (WEP) in 802.11 products, and Microsoft's first implementation of the Point to Point Tunneling Protocol (PPTP).

So why does this happen?

The problem is based on the behavior of the add without overflow operation used in one-time pads, which in the digital world involves the exclusive-or operation (called "xor" for short - click here for an explanation).

If used properly, xor is an effective way to encrypt data. However, it leaks data if not used carefully. The leakage arises from the binary logic of the combination (click here for an explanation).

Reusing the Key

In a different example, we worked with a 128 x 128 image containing this message:

 "Send Cash" message

We encrypted this image by applying the xor operation. We used a random 128 by 128 bit map for the encryption key. This yielded the following gray block:

Encrypted "Send Cash"

Let's use the same encryption key to encrypt another 128 by 128 bit mapped image:

⊕

Smiley image              XOR    Encryption Key

Both the key and the encrypted data yield images that look like similar gray blocks. This is how it should be: a matrix randomly scattered with 0 and 1 bits should look gray. The encryption key and the encrypted data should look random, with no distinct patterns.

Thus, the encrypted Smiley yields another gray block:

Encrypted Smiley

Now, let's combine the two encrypted images using xor:

⊕

  Encrypted Smiley   XOR  Encrypted "Send Cash"

Again, each looks like nothing more than a gray block. A closer look (as in this other example) will show that individual bits may differ.

The xor operation eliminates the key from both images, and leaves us with the images themselves:

  Two messages

In real-world cases like Venona, WEP, and PPTP, we aren't usually encrypting images. However, the underlying plain text, whether literally text or encoded network protocol data, has distinctive patterns. Skilled cryptanalysts can identify these patterns and can extract the two messages from the mixed-up data.

Try it yourself

These example images are 128 by 128 bit maps in GIF format. If you have a program that can read GIF files, save them as bit maps, and apply the xor operation bit-by-bit, then you can easily repeat this operation.

The examples here were processed by Matlab, a commercial package, but there are numerous other packages that can reproduce the example. Download these images:

• "Send Cash" message (m1)
• Encryption key (k)
• Encrypted "Send Cash" message (m1 ⊕ k = e1)
• Smiley image (m2)
• Encrypted Smiley (e2)
• Overlaid Smiley and "Send Cash"

Apply the xor operation to the first two bit maps to produce the third. Combine the key with the encrypted message (k ⊕ e) to reproduce original "Send Cash" message.

Use the same process on the Smiley to produce its encrypted form. When you combine the two encrypted messages, you end up with the overlaid images. -

The Logic Equations

If you use the same encryption key for two different messages, then an eavesdropper can eliminate the encryption key (and thus, the encryption) by applying xor to the encrypted messages by themselves. In other words,

Let a, b be plaintext messages,

 

and let A, B be corresponding encrypted messages,

 

with k as the key;

 

If a ⊕ k = A, and b ⊕ k = B,

 

then a ⊕ b = A ⊕ B.

You can work this out from the description of xor provided on this other page. In terms of fundamental digital operations AND (&), OR (|) and NOT (~), the xor operation is defined as follows:

a ⊕ k = (~a & k) | (a & ~k)

If you substitute this definition in the equations above, you find that combining the encrypted messages yields the same result as combining the plain text messages.

References

Borisov, N., Goldberg, I., Wagner, D. (2001) Intercepting Mobile Communications: The Insecurity of 802.11. 7th Annual International Conference on Mobile Computing and Networking (ACM SIGMOBILE). Rome, Italy, July.

Benson, R. (2001) The Venona Story. web page. National Security Agency, Center for Cryptologic History. The NSA's web site has a whole section devoted to  the Venona story.

Schneier, B., Mudge. (1998) Cryptanalysis of Microsoft's Point to Point Tunneling Protocol (PPTP). Proceedings of the 5th ACM Conference on Communications and Computer Security. November.

Smith, R. (1997) Internet Cryptography. Addison-Wesley.

Bob slid his ID card through the reader. There was a click as the dormitory’s front door unlocked. He fished into his pocked and pulled out the key to his suite as he ran up the stairs.

As the door swung open, he felt a chill of annoyance. Someone was sitting in front of his computer. Bob’s own room was so crowded with hockey and lacrosse equipment that he’d moved his computer into the common area. He didn’t recognize the guy at the computer, but then he hadn’t really met all of his suite mates. He marched over to the table and glared.

The guy looked up and said, “Hey.” He resumed his typing.

“That’s not your computer, is it?” Bob kept his voice perfectly level.

“I’m Kevin,” the guy said, holding out his hand.

Bob ignored the outstretched hand. “Okay, I’m Bob. The computer belongs to me. If you don’t have your own, I know there’s a public computer lab somewhere downstairs.” Bob folded his arms and continued to glare

“Okay then,” Kevin closed the application and sauntered into his room.

Bob sat down at the computer, a “tower” system that ran Microsoft Windows, and his heart sank. The desktop background should have been the picture from the Championship last spring. Now it was that boring blue again. Even worse, the notes he’d typed up earlier from class were gone. He needed those notes for the English paper he had to write.

He strode over to Kevin’s room. “What did you do to my computer? The background pattern is changed. Where did my files go?”

Kevin looked up and said, “Nothing, man. That’s the way I found it.”

The suite door opened. Bob turned to see a young man sporting a goatee and wire rimmed glasses.

Pointing to his computer, he asked the newcomer, “Did you mess with my computer?”

The young man stared at him. After a pause, he asked, “And who are you?”

Bob glared and folded his arms. He was proud of his biceps. “I’m Bob. I live here. Now answer the question.”

“I live here too.” The young man peered at the cheap monitor and tiny system unit with obvious distaste. “It’s just sitting there. It’s totally unprotected. Even so, why would I bother?” Unstrapping his expensive messenger bag, he pulled out an ultrathin Apple laptop and strode to his room.

Muttering under his breath, Bob sat down at his (his!) computer. After rummaging around, he found another copy of his background picture. He also found a partial copy of the file he’d typed up earlier. Maybe he could get the rest of the notes from that geek girl in his English class.

There was supposed to be a place in Windows where you could activate passwords. Bob didn’t want to bother with passwords, but he also didn’t want people messing up his computer. Classes would be hard enough as it was. He thought about the geek girl again. Alice. He typed in the password twice to set it up.

Then Bob typed up a small notice. He printed it out, cut it to size, and carefully taped it to his monitor.

If you touch this computer, you’re dead.

Bob balanced the two coffee cups atop a textbook. The other hand carried a jelly donut. He sat down gingerly and handed over the smaller cup. “A tall latte, as requested.”

Alice grabbed the cup and took a long, slow sip. Bob winced at the sound. His eye caught the hem of her denim skirt.

She peered at him over the cup’s rim. “So what happened?”

“I password protected my computer, you know? When I leave it for more than 5 minutes, or hit the ‘Lock’ icon, it demands a password to get back in.”

“That’s a good start.” Alice idly picked up Bob’s freshly printed essay for English as he continued.

“I came back after dinner, and he’d changed my desktop pattern again. And he renamed my Word files to names like ‘hacked1’ and ‘hacked2.’ I yelled at my suite mates, but I can’t tell who did it.”

The English essay now had Alice’s full attention.

“So, what do you think?” Bob tried to keep the edge out of his voice. He wondered if the girl had heard anything he said.

Alice looked up and put the paper down. “The first paragraph sucks, but the instructor will love the part about the trees.

Bob snatched the paper away. “Fine. Here’s what happened to my computer. I came back from dinner, and...”

Alice interrupted him. “It's a matter of control.” she said, as she took off her glasses and gave Bob her full attention. “What happens to your computer if I take away the hard disk?”

“It won't start. That's where all my software is. And my papers.”

“Right. But what if I tell the computer to start from a CD?”

Bob smiled. “Anyone in particular? Dar Williams? Madonna? Billie Holiday?”

Alice continued, “Okay, let’s say you put a new operating system on your PC. You get it on a CD and you start it from there. The existing OS on your hard drive never runs. Now do you get it?”

“You think they replaced my operating system?” Bob felt uncomfortable, as if someone had returned his lost wallet, and all the cards were alphabetized.

“Probably not. But they could run a different OS and use it to change other things on your hard drive. Another OS can easily change file names, and probably your desktop pattern. They just run the OS off the CD. It's their OS, so they can be administrator and do whatever they want.”

Bob looked up suddenly. “Can we make the PC only load from the hard drive?”

Alice’s eyes narrowed and she put her glasses back on. “Maybe you should start by asking why people are messing with you.”

Bob unlocked the door of the suite. He tried to hold it open while Alice squeezed past him. Her backpack grazed the door, pushing it away from Bob’s hand.

Bob followed her in. Alice was already talking one of his suite mates, a woman wearing a black jumpsuit. She was holding an impossibly thick book.

“Yeah,” Alice continued, “It’s no cookbook. Singh talks more ‘how it works’ than ‘how to use it.’”

“Back here,” Bob said. He typed control-alt-delete and entered his password in the box that popped up.

“We need to talk some time,” the jumpsuit woman said.

“You bet,” replied Alice. “Good to meet you, Tina.” The woman stood and left the common room to Bob and Alice.

Alice scanned the room. She noted the suite door, a bathroom door, a picture window, and three doors to private rooms. She sat on the couch, taking the spot Tina just left.

Bob was concentrating on his computer. “Everything seems okay.” This time. He sighed. “Do you want to take a look?”

“What are you trying to protect?”

Bob furrowed his brow. “What kind of question is that? I’m trying to protect my computer!” He paused, then let his voice drop, “Aren’t you going to look at this?”

“I can see fine from here. You have a single room, right? And the others are doubles?”

“So what?”

“So you’re using all of your private room, plus a chunk of the common space. The threat is the ‘disgruntled suite mate.’ Now, you can either get into an arms race with your suite mates on this, or you can defuse things by offering to share your computer.”

Bob paused. He was perfectly in his rights to use a piece of the common space, wasn’t he? And he was perfectly in his rights to exclude people from his computer. After all, it was pretty small and there wasn’t much worth sharing. But Alice had a point.

“How do we share it without other people messing with my stuff?”

Alice smiled. “That’s the easy part.”

Bob sat uncomfortably in the chair and tried to concentrate. The piece of paper contained a long list of numbers. It was the third list he’d had to memorize. The first two were easy. This was tough.

“Turn the paper over.” The voice came through a scratchy speaker in the wall. It was the pencil-necked guy that had shown him in. Bob glanced at the cheap one-way mirror that covered most of the wall.

“Now, I will recite the list to you. If I recite a number correctly, say ‘Yes.;’ If I recite a wrong number, say ‘No.’”

After the slightest pause, the speaker rapidly shouted numbers. Bob yelled “Yes!” and “No!” a couple of times, but finally stopped when he realized he was totally left behind.

He felt sweat dampening the back of his shirt.

“Okay, we’re done!” The speaker squawked, and then the door opened. The pencil-necked guy motioned him out.

“So what are you doing with the results?” Bob tried to sound off-hand. He hated to lose.

“I’ll probably put the results on a poster for the next research show.”

Bob thought of the sports page, with individual player results blown up poster-sized. In a low voice, he said, “I’d prefer you didn’t publish my results.”

Pencil-neck smirked. “Don’t worry, I’m not allowed to publish names!”

Bob walked away, feeling foolish. He stopped short, hearing a female voice shout his name. He turned to see Tina walking towards him.

“Do you have a partner for the sociology project? I have a survey question worked out. We can combine the results on the computer in the suite.” Tina stopped to take a breath.

Bob paused, then said, “Sure, we can use my computer. But we have to keep the results secret. That Professor Chalkey was very firm. The Feds might come down on us otherwise.”

Bob wasn’t sure why the FBI would give a rip about his stupid class project, but that’s what they said.

“I’ll take care of that,” Tina said. “Just give me my own login and password.”

Bob popped the USB drive into the socket. As soon as the “Computer” window appeared, he right clicked on the drive icon, tracked down the menu, and selected “Format.”

“Dangerous,” said Alice, hovering over his shoulder.

“It’s faster,” Bob announced. His fingers were on autopilot as he deftly clicked the “Quick Format” box.

Alice shook her head. “It’s a bad habit. What if you format the wrong drive?”

Bob snorted. “What do you think I am, a doofus?” He clicked “Start” and dismissed the warning alert almost without seeing it.

Chattering erupted from the external hard drive on his desk. The “busy” lamp winked several times and went silent. The computer emitted a soft tone, and an alert popped up saying “Format Complete.”

Bob stared at the hard drive and clenched his teeth. “That had all my photos.”

Alice took pity and said, “Maybe they’re still there. It takes longer than that to wipe out an entire hard drive.”

“What do you mean?”

“All a ‘quick format’ does is wipe out some data at the very start of the hard drive. If you have a lot of files and folders, most of them might still be there.” Alice paused, then yelled, “Kevin!”

A head popped out of a bedroom. “Yeah?”

“Do you still have that recovery CD?”

“Yeah, just a sec.” Kevin disappeared into his room, and returned with a CD. It was marked with skull and crossbones.

Bob stared at the CD. “What’s that?”

“Just a bunch of disk utilities.” He elbowed the others aside and popped the disk into the CD drive. He restarted the system and typed the BIOS password.

Bob suppressed a gasp as Kevin rebooted to the CD.

After a minute of flashing text and incomprehensible color bars, an alien desktop appeared on the display. Then Kevin turned to Bob.

“What happened?”

Alice replied, “He did a fast format on the external drive. It was FAT formatted both before and after.

“Okay.” Kevin smiled. “FAT shouldn’t be a problem. He started a command shell, typed a few commands, and finally typed:

    unformat /dev/disk3

The hard drive started clicking again.

“Leave it for a while and we’ll see what it finds.” Kevin fell into a sort of trance, staring at the display.

“But what’s it doing?” Bob demanded. He didn’t like the idea of running some weird stuff on his computer.

“If it gets your files back, do you really care what it is?” Alice asked. He couldn’t argue with the irritation in her voice.

“The quick format doesn’t really erase your drive,” Kevin whispered, as he watched patterns of text form on the screen. “The actual files are still there. All you did is erase the starting point we use to find them.”

Bob started to relax. “You know,” he said, “this is as bad as anything a hacker might do.”

“As long as the hacker doesn’t get your bank account,” Kevin whispered, almost to himself.

“Yes, I set up the BIOS password.” Bob said. “And the separate admin user. And all that other crap. But they still got in.”

Bob felt defeated. He didn’t like that.

“And when did you last use the admin login?” Alice was starting to sound like a prosecutor on a really bad courtroom show.

“How should I know?” Bob whined. “Isn’t there something else we can do?”

“Well,” said Alice, “they couldn’t bypass the BIOS, and you haven’t left the thing logged in.” Alice paused for a moment.

“I’m sick of passwords. Could we try electrodes in the chair, maybe?”

Alice ignored Bob’s outburst and moved over to the computer. “Here, let me drive.” She nudged Bob away until she was in sole possession of keyboard and mouse.

She lifted up the keyboard. No Post-its with passwords underneath. She felt around under the desk. Nothing but fossilized gum.

Alice’s eyes roamed around the suite. She started typing. Bob looked over and noticed she wasn’t logged in. What was she typing? Passwords?

Bob felt rising irritation. He hated doing nothing. He hated being on the bench. He got up and strode purposefully up and down the room. Then he stopped in front of the computer. He liked the way Alice’s hair draped over her shoulder. Alice paused, then started typing again. Then she growled. Well, part growl and part groan. Bob glanced at the screen. She had logged in.

Alice guessed his password. Bob felt a flush under his skin. She should be flattered by his choice. But she was mad.

“What a stupid password. Am I the only woman who visits you?”

Bob tried to sound unruffled, “Let’s say you’re the only one who helps me with my computer.” There was just a touch of smugness in that.

“Well, it wouldn’t take a psychic to guess it, then,” Alice replied acidly.

Bob sought a relaxed tone of voice and asked, “What’s the big deal? I needed a password and it’s a good one. Nice and short and I’m not going to forget it, am I?”

“A good password is something hard to guess, Mister Einstein. This - I - was probably the first name you suite mates guessed. They won’t know your dog’s name, but they’ll know the names of everyone who visits. Especially the women.”

Blam, bleep, bam. Electronic sounds emerged from the computer. Bob furrowed his eyes. Tense wrinkles formed across his forehead. But his wrist moved smoothly, tracking the alien shapes, dispatching them one by one with a series of deft clicks.

Bob didn’t play a lot of computer games, but this one was fun. It made a nice break while writing up homework assignments. A few days earlier, he found it running on his computer when he came back from class. Now he played whenever he sat down.

As soon as the screen cleared, Bob closed the window with an air of satisfaction. The desktop pattern appeared, showing Bob at a high school awards ceremony. Not as cool as the Championship photo, but Alice insisted. She said the desktop photo for Suitemates had to be different from Bob’s personal login. So Bob chose the ceremony pic.

Gazing briefly at the desktop windows, Bob froze. He looked closer at the files in the Suitemates “Documents” folder. It looked exactly like his own: there were the same Word files, with the same names as his own homework files. He looked closer at an Excel file, titled “g3survey.xls.” It looked just like the file containing their confidential survey results.

Bob opened the file with a quick double click. Yes, it was a copy of their data file. What was it doing here? Bob right clicked on it and chose “Delete.” To make sure, he clicked on the Recycle Bin itself and selected “Empty Recycle Bin.”

He looked up. Large, blue eyes were staring at him.

“Oh. Eve. Didn’t hear you come in.” Bob’s glance lingered briefly on a curl of his suitemate’s hair that grazed her cheek. How could such a pretty girl always give him the creeps?

Eve’s lips betrayed a little smile. “Did you zap lots of aliens?” Bob looked sheepish and said, “Yeah, and then I found an unprotected copy of my secret survey file.”

A snort arose from a doorway. It was Bruce.

“You’re in trouble if Professor Chalkley finds out,” he said. “She was very specific about protecting those files!”

“I did protect them,” Bob argued. “We set up the separate users and set up all the right file protections. There’s no way to crack that without breaking Windows.”

Bob paused, then asked, “You guys don’t know how to break Windows do you?”

“Broke one with a softball,” admitted Eve.

“You need to encrypt your files,” declared Bruce. “Do it right and they’re completely safe, even if someone breaks Windows.”

“And how do I do that?” Bob asked. Bruce’s condescension annoyed him, but he didn’t need trouble with his psych professor.

“That will be $5.36,” the cashier said.

Bob slapped his back pocket and sighed. In his mind’s eye he could see his wallet. It was sitting comfortably on his desk, in his bedroom. He fished in another pocket and brought out three crumpled dollar bills. He tried not to look toward his table, and the girl sitting there. He looked the other way and saw Kevin.

“Hey, Kevin,” Bob said, trying to sound friendly.

“Hey,” Kevin replied. He gave a noncommittal smile.

Bob’s voice dropped, “Er, could you lend me a few bucks?”

“Forgot your wallet,” Kevin asked, his voice normal.

“Yeah, yeah, like three dollars? Okay?”

Kevin opened his wallet and with a flourish pulled out three crisp dollar bills.

“Should we make it five?” he asked.

Bob grabbed the bills. “No, this is fine, thanks, man.”
Three days later...

“That’s weird,” Bob muttered.

“Now what?” Bruce was impatient to get to work.

“I, er, owe Kevin some money. I write little files to remind me of stuff like that. But the file says $7 and I was sure it was only three dollars. I can almost see him waving the bills around.”

“Okay, then, something must have happened to the file. Could he have changed it?” “No, that can’t be it. I encrypted it with RC4. All it said was ‘I owe Kevin $3.’”

“You didn’t use one of your famous passwords, did you?”

Bob flushed, and said, “No way. This was something not even you would guess.” Bruce thought for a moment. “You didn’t happen to show him the file, did you?”

“Yes,” Bob admitted.

“That’s it. It’s trivial to change the contents of a stream encrypted file. That is, it’s trivial if you know what the file says. It’s simple binary logic.”

As Kevin entered the suite, Bob was concentrating on his computer. Kevin moved quietly, not wanting to awaken Bob’s interest.

Bob glanced up, warily, and then returned to staring at his screen. He didn’t look hostile at all. He looked nervous.

Kevin straighten up and sauntered over to the computer. “What’s up?” he asked.

Bob tensed up. Then he sighed. “Okay, I’m trying to look at the directories on this USB drive. And nothing makes sense.”

Kevin looked at the display. The dump window showed nothing but random data. No readable text. No zeroes, even.

“That’s not a directory.”

“But it has to be,” Bob said. “I pulled out the numbers from the boot block, added them up, and this is where I landed.”

Kevin looked at the numbers scrawled on a torn piece of paper.

“That’s crazy,” he said. “FAT never puts the root directory in the middle of the drive. Let’s see the boot block.”

Bob clicked and typed. The first sector displayed.

“That’s not a boot block. For one thing, there’s no volume label. There should at least be blanks there.” Kevin pointed at the display. “Try reformatting and do it again.”

Bob looked sheepish. “I can’t do that.”

“Why not?”

“It’s not my drive.” Bob gestured to the bulletin board. Two USB drives now hung from paperclips. A third paperclip stood empty. “I just wanted to see if I could do what everyone else is doing.”

“Not quite everyone else,” Kevin whispered.

“Am I using the right tools? I couldn’t even get the thing to mount.” Kevin shook his head.

“You’re looking at an encrypted drive,” he explained.

“What do you mean?” Bob asked.

“Instead of encrypting files one at a time, this encrypts everything on the drive. It’s safer in some ways, but not as flexible in others.”

(circa 1970-85, maybe later)

The Forth programming system was developed in the late 1960s by Chuck Moore. It provided a very powerful, text based mechanism for controlling a computer and writing programs when RAM and hard drive space were extremely tight. Early implementations were routinely restricted to 8KB of RAM. Some early implementations relied exclusively on diskette drives that stored less than a half a megabyte of data.

Starting in the 1970s, typical Forth systems treated hard drives as consisting of a linear set of numbered blocks, each 1KB in size. The first block on the drive (block 0) contained the bootstrap program to get Forth started, and a small number of subsequent blocks might also contain binary executable code that was loaded into RAM when Forth started.

Following the blocks of executable code, the remaining hard drive blocks generally contained ASCII text and were referred to by number. If a programmer needed to modify part of a Forth program, he would edit the hard drive block that contained that program, and refer to the block by its number.

Here is an assessment of Forth's file system in the context of the eight concepts noted above:

• File storage - each file was essentially of a fixed, 1KB size. Other measures had to be used to link multiple blocks together into longer sequences of data.
• Locating files - files were referred to by block number, and the number had to be remembered by the programmers.
• Free space management - programmers had to remember what blocks had not been used, or which blocks contained obsolete text that could be erased so the block could be reused.
• Easy to implement - Yes, yes, yes!
• Speed - Very fast at the hardware level, since no hard drive searching had to take place
• Direct vs. sequential - supported both
• Storage sizes - no built-in limit, but this obviously became impractical as drives increased dramatically in size
• Robustness - there is little on-disk structure to destroy, so the robustness becomes a social issue having to do with the reliabilty of the people using the system: will they forget, or resign, or otherwise be unavailable? Can others fill in the gaps left by missing people? Will the hard drive get too big for humans to keep track of its contents without a more conventional file system?

(circa 1973-8)

Boston University (BU) developed its own timesharing system in the 1970s for its IBM 360 and 370 mainframes. The system was based on the batch-oriented Remote Access Computing System (RACS) developed by IBM. McGill University also participated in RAX development, but their version was renamed "McGill University System for Interactive Computing" (MUSIC). Although many of the details are lost in the mists of time, both systems used some text processing tools developed at BU.

At the time, IBM had developed a few timesharing systems, but they were generally expensive and slow. IBM's standard operating systems for the 360 series had a file system; files were referred to as data sets. To put matters as charitably as possible, IBM's data set support was not suited to the dynamic nature of file access in timesharing environments. Frankly, it was a beast. So RAX really needed its own file system.

In accordance with the traditions of IBM data processing, a RAX file looked more-or-less like a deck of punched cards. Files consisted of "records" that carried individual lines of text. Unlike punched cards, trailing blanks were omitted and the individual records (lines) could vary in length. More significantly, files were either read sequentially in a single pass, or written sequentially in a single pass. There wasn't any notion of random access or of modifying the middle of a file without rewriting the whole thing. While RAX did support random access to hard drive files, the function was limited to specially allocated files (standard IBM data sets, actually) and used special operations that were only avaliable to assembly language programmers.

Each file had a unique name and was 'owned' by the user that created it. Users could modify the permissions on files to share them with other users.

The RAX system's timesharing hours were generally limited to daytime and evenings. Overnight, the CPU was rebooted with IBM's OS/360 or OS/VS1 to run batch jobs. Thus, the RAX hard drives had to be compatible with IBM's native file system, such as it was. The RAX library was implemented inside a collection of IBM data sets, each data set serving as a pool of disk blocks to use in library files. These disk blocks were called space sets and contained 512 bytes each.

A complete RAX library file name contained two parts: an 8-character index name and an 8-character file name. While this gave the illusion of there being a hierarchical file system, there was no true 'root' directory. All files not used by the RAX system programming staff resided in the "userlib" index; if no index name was given, RAX searched in userlib. The directory arrangement apparently worked as follows:

There were a small number of IBM data sets that served as library directories (indexes). A file's index name selected the appropriate data set to search for that file's directory entry. These index files were apparently set up using IBM's Indexed Sequential Access Method (ISAM). Such files were specially formatted to use a feature of the IBM disk hardware. Each data block in the file contained a key field along with space for a library file's directory entry. The "key" part contained the file name. The IBM disk hardware could be told to scan the data set until it found the record whose key contained that name, and then it would retrieve the corresponding data. This put the burden of directory searching on the hard drive, and freed up the CPU to work on other tasks.

The directory entry contained the usual timestamps (date created, accessed, modified, etc.), ownership information, access permissions, size, and a pointer to the first space set in the file.

Once the system knew the location of the file's first space set, it could retrieve the file's contents sequentially. A space set address was a 32-bit number formatted in 2 fields:

Remember that the library consisted of numerous data sets that served as pools of data blocks These pools were called lib files, and were numbered sequentially. The data blocks, or space sets, were numbered sequentially inside each lib file.

Files within the RAX library were implemented as a list of linked space sets. The first four bytes of each space set carried the pointer to the next one in the file. The pointer bytes were managed automatically by the system's read and write operations; they were invisible to user programs. The net result was that user programs perceived space sets as containing only 508 bytes, since 4 bytes were used for the link pointer.

A single library file could contain space sets from many different lib files. Since each lib file tended to represent a contiguous set of disk space, file retrieval was most efficient when all space sets came from the same lib file. In practice, however, a file would incorporate space sets from whichever lib file had the most available.

Free space was managed within individual lib files. Each lib file kept a linked list of free space sets. Space sets from deleted files were added back to the free list in the appropriate lib file.

Here is a review of the eight issues listed above:

• File data structure - variable length records that more or less corresponded to lines of text.
• File block structure - uses a linked list to organize randomly located disk blocks into a sequential file
• Directories - effectively a single level directory structure with user permissions and timestamps
• Free space - manages in arbitrary, locally maintained lists. Any block can be in any file, eliminating fragmentation problems.
• Easy to implement - built atop a rich IBM-oriented I/O mechanism - simple to implement in that environment, but hard to replicate in non-IBM environments.
• Speed - Directory lookup is very fast. File data access is rarely optimized, though
• Sequential vs. direct - system really only supports sequential access
• Storage sizes - can combine data sets on multiple drives to store perhaps 2TB of data, assuming 512 byte space sets. Individual files are probably limited to 4GB by the size field in the directory entry.
• Robustness - Links are brittle. System crashes could cause link inconsistencies, and the risk of a file's link pointing to a space set on the free list. However, file replacement consists of not eliminating the old file and its chain of space sets until the new file's chain has been completely built. System crashes during such updates would usually leave the previous file intact.

(Circa 1975-199?)

The PDP-11 computer, build by Digital Equipment Corporation (DEC) in the late 20th century, was a classic machine of the minicomputer era. At the time of the -11's introduction, DEC really had no idea what to do about software for its machines, and wasn't even sure what was appropriate in the way of operating systems. Over the next several years, DEC (and others) introduced a flotilla of operating systems for the PDP-11. Here are DEC's contributions:

• Paper Tape Operating System - name says it all.
• DOS-11 - the Disk Operating System; spent too much time visiting the disk.
• RT-11 - a real time operating system.
• RSX-11 - a resource sharing executive, produced in three flavors.
  • RSX11-S - a single-user or stand-alone version
  • RSX11-D - disk-based, multi-user, a resource hog.
  • RSX11-M - multitasking - a prototype for later systems, notably VMS
• RSTS-11 - a resource sharing, time sharing system.

The RT-11 operating system came in several flavors, but all shared the same, simple file structure. The file system consisted of a single directory configured at a fixed location at the start of the disk volume. The directory could consist of multipe non-contiguous "segments" as defined in the directory's header.

Searching for files was very simple: when the system booted, the boot code would search the RT-11 directory for the name "MONITR.SYS" which indicated the system image to load and run.

An RT-11 directory entry consisted of the following:

1. 16-bit flag word to indicate if the directory entry is permanent, temporary, or currently unused.
2. 6-character file name using DEC's Radix-50 character set (A-Z, 0-9, $, and ".").
3. 3-character extension suffix, also in Radix-50
4. File creation date
5. File's starting block number on the hard drive
6. File's length in blocks
7. Additional data, as configured when the directory was created

When creating a directory, the operator can configure it to contain extra space for application specific file data. It would be the application's responsibility to update the additional data in a file's entry.

To create a new file, even temporarily, RT-11 had to allocate space by updating the directory. If the program specified a particular file size, RT-11 would try to fit that size. If the program did not specify a file size, RT-11 would allocate half of the largest block of free space available on the hard drive.

Once RT-11 had determined the amount of space for the new fiile, and its intended location on the hard drive, it would usually allocate the hard drive space by creating two adjacent directory entries. The first entry would be for the new file, and would contain the number of blocks desired for the new file. The second entry would be for any free space left over after allocating the desired amount of space for the file.

When first opened, a file was generally marked as "tentative" in the directory, and updated to "permanent" when and if the creating program actually closed the file.

Here is an assessment of RT-11's file system in the context of the eight concepts (Challenges and Objecives) noted earlier:

• File storage - each file consists of a contiguous group of blocks on the hard drive.
• Locating files - files were located via the directory, which resided in a fixed location at the beginning of the hard drive. The directory consisted of a single array of entries, each with a 6.3 character file name formatted in DEC's Radix-50 format. A file's directory entry indicated the address of the first block of the file.
• Managing free space - unallocated disk space is represented by "empty" directory entries that indicate the starting disk address and length of the empty space.
• Easy to implement - Yes. Consists of a single directory data structure.
• Speed - Efficient for very small hard drives: to find the last file in the directory you must read every block in the directory.
• Direct vs. sequential - supported both. Direct access simply required the offset to the start of the file and a seek limit based on the file's length.
• Storage sizes - limited to the offset sizes in the directory entries, which were generally 16-bit values.
• Robustness - since files were made up of sequential blocks, accidental deletions were easy to undo. A trained developer could recover an entire directory with a lot of work by looking at block contents to identify the start and ending blocks for individual files.

The RT-11 file system's simplicity led to its being used in various other applications. For example, the microcode disk used by the original VAX hardware used an RT-11 file system. The LOCK trusted computing base used the RT-11 file system for accessing files on its embedded SIDEARM processor.

Saltzer and Schroeder's 1976 paper listed eight design principles for computer security, and noted two additional principles that seemed relevant if more general.

1. Economy of mechanism – A simple design is easier to test and validate.

2. Fail-safe defaults – Figure 2 shows a physical example: outsiders can't enter a store via an emergency exit, and insiders may only use it in emergencies. In computing systems, the save default is generally “no access” so that the system must specifically grant access to resources. Most file access permissions work this way, though Windows also provides a “deny” right. Windows access control list (ACL) settings may be inherited, and the “deny” right gives the user an easy way to revoke a right granted through inheritance. However, this also illustrates why “default deny” is easier to understand and implement, since it's harder to interpret a mixture of “permit” and “deny” rights.

3. Complete mediation – Access rights are completely validated every time an access occurs. Systems should rely as little as possible on access decisions retrieved from a cache. Again, file permissions tend to reflect this model: the operating system checks the user requesting access against the file's ACL. The technique is less evident when applied to email, which must pass through separately applied packet filters, virus filters, and spam detectors.

4. Open design – Baran (1964) argued persuasively in an unclassified RAND report that secure systems, including cryptographic systems, should have unclassified designs. This reflects recommendations by Kerckhoffs (1883) as well as Shannon's maxim: “The enemy knows the system” (Shannon, 1948). Even the NSA, which resisted open crypto designs for decades, now uses the Advanced Encryption Standard to encrypt classified information.

5. Separation of privilege – A protection mechanism is more flexible if it requires two separate keys to unlock it, allowing for two-person control and similar techniques to prevent unilateral action by a subverted individual. The classic examples include dual keys for safety deposit boxes and the two-person control applied to nuclear weapons and Top Secret crypto materials. Figure 3 (courtesy of the Titan Missile Museum) shows how two separate padlocks were used to secure the launch codes for a Titan nuclear missile.Separation of privilege – A protection mechanism is more flexible if it requires two separate keys to unlock it, allowing for two-person control and similar techniques to prevent unilateral action by a subverted individual. The classic examples include dual keys for safety deposit boxes and the two-person control applied to nuclear weapons and Top Secret crypto materials.

6. Least privilege – Every program and user should operate while invoking as few privileges as possible. This is the rationale behind Unix “sudo” and Windows User Account Control, both of which allow a user to apply administrative rights temporarily to perform a privileged task.

7. Least common mechanism – Users should not share system mechanisms except when absolutely necessary, because shared mechanisms may provide unintended communication paths or means of interference.

8. Psychological acceptability – This principle essentially requires the policy interface to reflect the user's mental model of protection, and notes that users won't specify protections correctly if the specification style doesn't make sense to them.

There were also two principles that Saltzer and Schroeder noted as being familiar in physical security but applying “imperfectly” to computer systems:

1. Work factor – Stronger security measures pose more work for the attacker. The authors acknowledged that such a measure could estimate trial-and-error attacks on randomly chosen passwords. However, they questioned its relevance since there often existed “indirect strategies” to penetrate a computer by exploiting flaws. “Tiger teams” in the early 1970s had systematically found flaws in software systems that allowed successful penetration, and there was not yet enough experience to apply work factor estimates effectively.

2. Compromise recording – The system should keep records of attacks even if the attacks aren't necessarily blocked. The authors were skeptical about this, since the system ought to be able to prevent penetrations in the first place. If the system couldn't prevent a penetration or other attack, then it was possible that the compromise recording itself may be modified or destroyed.

Today, of course, most analysts and developers embrace these final two design principles. The argument underlying complex password selection reflect a work factor calculation, as do the recommendations on choosing cryptographic keys. Compromise recording has become an essential feature of every secure system in the form of event logging and auditing.

Today, security principles arise in several contexts. Numerous bloggers and other on-line information sources produce lists of principles. Many are variants of Saltzer and Schroeder, including the list provided in the Open Web Application Security Project's wiki (OWASP, 2012). Principles also arise in information security textbooks, more often in the abstract sense than in the concrete. Following recommendations in the report Computers at Risk (NRC, 1991), several standards organizations also took up the challenge of identifying a standard set of security principles.

Most textbook authors avoid making lists of principles. This is clear from a review of twelve textbooks published over the past ten years. This is even true of textbooks that include the word “Principles” in the title. Almost every textbook recognizes the principle of least privilege and usually labels it with that phrase. Other design principles, like separation of privilege, may be described with a different adjective. For example, some sources characterize separation of privilege as a control, not a principle.

Pfleeger and Pfleeger (2003) presents its own set of four security principles. They are, briefly, easiest penetration, weakest link, adequate protection, and effectiveness. These principles apply to a broader level of security thinking than Saltzer and Schroeder design principles. However, the text also reviews Saltzer and Schroeder's principles in detail in Section 5.4.

The remaining few textbooks that specifically discuss design principles generally focus on the 1975 list. The textbook by Smith and Marchesini (2008) discuss the design principles in Chapter 3. The two textbooks by Bishop (2003, 2005) also review the design principles in Chapters 13 and 12, respectively.

"Generally Accepted Principles"

Following Computers at Risk, standards organizations were motivated to publish lists of principles. The OECD published a list of eight guidelines in 1992 that established the tone for a set of higher-level security principles:

Accountability, Awareness, Ethics, Multidisciplinary, Proportionality,
Integration, Timeliness, Reassessment, and Democracy.

In its 1995 handbook, “An Introduction to Computer Security,” NIST presented the OECD list and also introduced a list of “elements” of computer security (NIST, 1995). Following the OECD's lead, this list presented very high level guidance, addressing the management level instead of the design or technical level. For example, the second and third elements are stated as follows:

“Computer Security is an Integral Element of Sound Management”

“Computer Security Should Be Cost-Effective”

The following year, NIST published its own list of “Generally Accepted Principles and Practices for Securing Information Technology Systems” (Swanson and Guttman, 1996). The overriding principles drew heavily from the elements listed in the 1995 document. The second and third elements listed above also appeared as the second and third “Generally Accepted Principles.”

The OECD list also prompted the creation of an international organization that published “Generally Accepted System Security Principles” (GASSP) in various revisions between 1996 and 1999 (I2SF, 1999). This was intended to provide high-level guidance for developing more specific lists of principles, similar to those used in the accounting industry. The effort failed to prosper.

Following the 1999 publication, the sponsoring organization apparently ran out of funding. In 2003, the Information System Security Association tried to restart the GASSP process and published the “Generally Accepted Information Security Principles” (ISSA, 2004), a cosmetic revision of the 1999 document. This effort also failed to prosper.

In 2001, a team at NIST tried to produce a more specific and technical list of security principles. This became “Engineering Principles for Information Technology Security” (Stoneburner, et al, 2004). The team developed a set of thirty-three separate principles. While several clearly reflect Saltzer and Schroeder, many are design rules that have arisen from subsequent developments, notably in networking. For example:

• Principle 16: Implement layered security (Ensure no single point of vulnerability).

• Principle 20: Isolate public access systems from mission critical resources.

• Principle 30: Implement security through a combination of measures distributed physically and logically.

• Principle 33: Use unique identities to ensure accountability.

While these new principles captured newer issues and concerns than the 1975 list, they also captured assumptions regarding system development and operation. For example, Principle 20 assumes that the public will never have access to “mission critical resources.” However, many companies rely heavily on Internet sales for revenue. They must clearly ignore this principle in order to conduct those sales.

Training and Curriculum Standards

When we examine curriculum standards, notably those used by the US government to certify academic programs in information security, we find more ambiguity. All six of the curriculum standards refer to principles in an abstract sense. None actually provide a specific list of principles, although a few refer to the now-abandoned GASSP. A few of Schroeder and Saltzer's design principles appear piecemeal as concepts and mechanisms, notably least privilege, separation of privilege (called “segregation of duties” in NSTISSC, 1994), and compromise recording (auditing).

The Information Assurance and Security IT 2008 curriculum recommendations (ACM and IEEE, 2008) identify design principles as an important topic, and provide a single example: “defense in depth.” This is a restatement of NIST's Principle 16.   

Co-authors Saltzer and Kaashoek published the textbook Principles of Computer Design in 2009 (Saltzer and Kaashoek, 2009). The book lists sixteen general design principles and several specific principles, including six security-specific principles. Here is a list of principles that were essentially inherited from the 1975 paper:

• General principle: Open design
• Security principle: Complete mediation
• Security principle: Fail-safe defaults
• Security principle: Least privilege
• Security principle: Economy of mechanism
• Security principle: Minimize common mechanism

Here are new – or newly stated – principles compared to those described in 1975: 

• Security principle: Minimize secrets – a thoughtful addition to the list that could be prone to misunderstanding. Secrets should be few and changeable, but they should also maximize entropy, and thus increase the attacker's work factor. The simple principle is also true by itself, since each secret increases a system's administrative burden: a late 1990s fighter jet project required dozens of separately-managed crypto keys to comply with data separation requirements that had been added piecemeal.
• General principle: Adopt sweeping simplifications – a restatement that acknowledges how hopelessly complex modern systems have become. In the 1970s, a Unix operating system could support a dozen separate users with a megabyte of RAM; a single user on a modern desktop easily consumes a gigabyte of RAM, much of it containing software programs.
• General principle: Principle of least astonishment – a concise and much clearer restatement of the “psychological acceptability” principle described in 1975.
• General principle: Design for iteration – an important first step towards incorporating continuous improvement as a design principle.

Neither of the uncertain principles listed in 1975 made it into this revised list. Despite this, event logging and auditing is a fundamental element of modern computer security practice. Likewise, work factor calculations continue to play a role in the design of information security systems. Pfleeger and Pfleeger highlighted “weakest link” and “easiest penetration” principles that reflect the work factor concept. However, there are subtle trade-offs in work factor calculations that may makes it a poor candidate for stating as a concise and easy-to-apply principle.  

The textbook Elementary Information Security presents a set of eight basic information security principles, While many directly reflect principles from Saltzer and Schroeder, they also reflect more recent terminology and concepts. The notion of “basic principles” stated as brief phrases seems like a natural choice for introducing students to a new field of study.

The textbook's contents were primarily influenced by two curriculum standards. The first was the “National Training Standard for Information System Security Professionals,” (NSTISSC, 1994). While this document clearly showed its age, it remains the ruling standard for general security training under the US government's Information Assurance Courseware Evaluation (IACE) Program (NSA, 2012). In February, 2012, the IACE program certified the textbook as covering all topics required by the 1994 training standard. The second curriculum standard is the “Information Technology 2008 Curriculum Guidelines” (ACM and IEEE Computer Society, 2008). The textbook covers all topics and core learning outcomes recommended in the Information Assurance and Security section of the Guidelines.

To fulfill their instructional role, each principle needed to meet certain requirements. Each needed to form a memorable phrase related to its meaning, with preference given to existing, familiar phrases. Each had to reflect the current state of the practice, and not simply a “nice to have” property. Each had to be important enough to appear repeatedly as new materials were covered. Each principle was introduced when it played a significant role in a new topic, and no sooner. Students were not required to learn and remember a set of principles that they didn't yet understand or need.

This yielded the following eight principles:

1. Continuous Improvement - continuously assess how well we achieve our objectives and make changes to improve our results. Modern standards for information security management systems, like ISO 27001, are based on continuous improvement cycles. Such a process also implicitly incorporates compromise recording from 1975 and “design for iteration” from 2009. Introduced in Chapter 1, along with a basic six-step security process to use for textbook examples and exercises.

2. Least Privilege - provide people or other entities with the minimum number of privileges necessary to allow them to perform their role in the system. This literally repeats one of the 1975 principles. Introduced in Chapter 1.

3. Defense in Depth - build a system with independent layers of security so that an attacker must defeat multiple independent security measures for the attack to succeed. This echoes “least common mechanism” but seeks to address a separate problem. Defense in depth is also a well-known alternative for stating NIST's Principle 16. Introduced in Chapter 1.

4. Open Design - building a security mechanism whose design does not need to be secret. This also repeats a 1975 principle. Introduced in Chapter 2.

5. Chain of Control - ensure that either trustworthy software is being executed, or that the software's behavior is restricted to enforce the intended security policy. This is an analogy to the “chain of custody” concept in which evidence must always be held by a trustworthy party or be physically secured. A malware infection succeeds if it can redirect the CPU to execute its code with enough privileges to embed itself in the computer and spread. Introduced in Chapter 2.

6. Deny by Default – grant no accesses except those specifically established in security rules. This is a more-specific variant of Saltzer and Schroeder's “fail safe defaults” that focuses on access control. The original statement is less specific, so it applies in safety and control problems. Introduced in Chapter 3.

7. Transitive Trust - If A trusts B, and B trusts C, then A also trusts C. In a sense this is an inverted statement of “least common mechanism,” but it states the problem in a simpler way for introductory students. Moreover, this is already a widely-used term in computer security. Introduced in Chapter 4.

8. Separation of Duty – decompose a critical task into separate elements performed by separate individuals or entities. This reflects the most common phrasing in the security community. Some writers phrase it as “segregation of duty” or “separation of privilege.” Introduced in Chapter 8.

The textbook's list focused on memorable phrases that were widely accepted in the computer security community. Principles introduced in earlier chapters always resurface in examples in later chapters. In retrospect, the list is missing at least one pithy and well-known maxim: “Trust, but verify.” The book discusses the maxim in Chapter 13, but does not tag it as a basic principle.  

For better or worse, three of the 1975 principles do not play a central role in modern information security practice. These are simplicity, complete mediation, and psychological acceptability. We examine each below.

There is no real market for simplicity in modern computing. Private companies release product improvements to entice new buyers. The sales bring in revenues to keep the company operating. The company remains financially successful as long as the cycle continues. Each improvement, however, increases the underlying system's complexity. Much of the free software community is caught in a similar cycle of continuous enhancement and release. Saltzer and Kaashoek (2009) call for “sweeping simplifications” instead of overall simplicity, reflecting this change.

Complete mediation likewise reflects a sensible but obsolete view of security decision making. Network access control is spread across several platforms, no one of which makes the whole decision. A packet filter may grant or deny access to packets, but it can't detect a virus-infected email at the packet level. Instead it forwards email to a series of servers that apply virus and spam checks before releasing the email to the destination mailbox. Even then, the end user might apply a digital signature check to perform a final verification of the email's contents.

Psychological acceptability, or the “principle of least astonishment” is an excellent goal, but it is honored more in the breach than in the observance. The current generation of “graphical” file access control interfaces provide no more than rudimentary control over low-level access flags. It takes a sophisticated understanding of the permissions already in place to understand how a change in access settings might really affect a particular user's access.

Version:1.0 StartHTML:0000000167 EndHTML:0000001597 StartFragment:0000000502 EndFragment:0000001581

Only a handful of Saltzer and Schroeder's original 1975 design principles have stood the test of time. Nonetheless, this represents a memorable success. Kerckhoffs, a 19th century French cryptographic expert, published a list of principles for hand-operated cipher systems, some of which we still apply to cryptosystems today. But most experts only recognize a single principle as “Kerckhoffs's Principle,” and that is his view on Open Systems: a cryptosystem should not rely on secrecy, since it may be stolen by the enemy. In addition to the Open System principle, both the principle of least privilege and of separation of privilege appeared on the 1975 list and are still widely recognized by security experts.

Perhaps lists of principles belong primarily in the classroom and not in the workplace. The short phrases are easy to remember, but they may promote a simplistic view of technical problems. Students need simplicity to help them build an understanding of a more complex reality.  

ACM and IEEE Computer Society, 2008, Information Technology 2008 Curriculum Guideline, http://www.acm.org/education/curricula/IT2008%20Curriculum.pdf, (retrieved March 1, 2012).

Bishop, 2003. Computer Security: Art and Science, Boston: Addison-Wesley.

Bishop, 2005. Introduction to Computer Security, Boston: Addison-Wesley.

I2SF, 1999. “Generally Accepted System Security Principles” International Information Security Foundation.

ISSA, 2004. “Generally Accepted Information Security Principles,” Information System Security Association.

Kerckhoffs, Auguste, 1883. “La cryptographie, militaire,” Journal des sciences militaires IX.

NCSC, 1985. Trusted Computer System Evaluation Criteria, Ft. Meade, MD: National Computer Security Center.

NIST, 1995, “An Introduction to Computer Security,” NIST SP 800-12, Gaithersburg, MD: National Institute of Standards and Technology.

NSA, 2012. “IA Courseware Evaluation Program – NSA/CSS,” web page, National Security Agency. http://www.nsa.gov/ia/academic_outreach/iace_program/index.shtml (retrieved Feb 29, 2012).

NRC, 1991. Computers at Risk: Safe Computing in the Information Age, Washington: National Academy Press. http://www.nap.edu/openbook.php?record_id=1581 (retrieved Feb 29, 2012).

NSTISSC, 1994. “National training standard for information security (INFOSEC) professionals,” NSTISSI 4011, Ft. Meade, MD: National Security Telecommunications and Information Systems Security Committee.

OWASP, 2012, “Category: Principle - OWASP,” web page, Open Web Application Security Project, https://www.owasp.org/index.php/Category:Principle (retrieved Feb 29, 2012).

Pfleeger, Charles, 1997. Security in Computing 2nd ed., Wiley.

Pfleeger, Charles, and Shari Pfleeger, 2003. Security in Computing 3rd ed. ,Wiley.

Saltzer, Jerome, 1974. “Protection and the control of information sharing in Multics,” CACM 17(7), July, 1974.

Saltzer, Jerome, and Kaashoek, 2009. Principles of Computer Design, Wiley.

Saltzer, Jerome, and Schroeder, 1975. “The protection of information in computer systems,” Proc IEEE 63(9), September, 1975.

Shannon, 1949. “Communication Theory of Secrecy Systems,” Bell System Technical Journal 28(4).

Smith, Sean, and Marchesini, 2008, The Craft of System Security,

Smith, Richard, 2012. Elementary Information Security, Burlington, MA: Jones and Bartlett.

Stoneburner, Gary, Clark Hayden, and Alexis Feringa, 2004. “Engineering Principles for Information Technology Security,” SP 800-27 A, Gaithersburg, MD: National Institute of Standards and Technology.

Swanson, Marianne, and Barbara Guttman, 1996. “Generally Accepted Principles and Practices for Securing Information Technology Systems,” SP 800-14, Gaithersburg, MD: National Institute of Standards and Technology.

Textbooks Reviewed but not Cited

Forouzan, 2008. Cryptography and Network Security, McGraw-Hill.

Gollmann, 2006. Computer Security 2nd ed., Wiley.

Newman, 2010. Computer Security: Protecting Web Resources, Jones and Bartlett.

Stallings, 2003, Network Security Essentials, Prentice-Hall.

Stallings, 2006. Cryptography and Network Security, Prentice-Hall.

Stallings and Brown, 2008. Computer Security: Principles and Practice, Prentice-Hall.

Stamp, 2006. Computer Security: Principles and Practice, Wiley.

Whitman and Mattord, 2005. Principles of Information Security 2nd ed., Thomson.

Jones & Bartlett Learning, November, 2011.

The only textbook verified by the US Government to conform fully to the Committee on National
Security Systems' national training standard for information security professionals (NSTISSI 4011)

ISBN-10: 0763761419

This comprehensive, accessible Information Security text is ideal for the one-term, undergraduate college course. The text integrates risk assessment and security policy throughout the text, since security systems work best at achieving goals they are designed to meet, and security policy ties real-world goals to security mechanisms. Early chapters in the text discuss individual computers and small LANS, while later chapters deal with distributed site security and the Internet. Cryptographic topics follow the same progression, starting on a single computer and evolving to Internet-level connectivity. Mathematical concepts throughout the text are defined and tutorials with mathematical tools are provided to ensure students grasp the information at hand.

• Order from Amazon (hard copy only)
• Order from Publisher (hard copy or soft copy), and sample copies for instructors
• Resources for students and instructors

See below for sample contents. Sample chapters are also available from the publisher's site.

Here is an incomplete collection of reading materials associated with the textbook. Visit the Elementary Infosec site for a complete set of reading and study materials. 

Locating copies of on-line articles and papers

Some links lead to on-line articles published by professional societies like the ACM (Association for Computing Machinery) or IEEE (Institute of Electrical and Electronic Engineers). Serious computing experts often join one or both of these, and sign up for electronic library subscriptions. Many college and university libraries may also provide free access to these for students and faculty.