The Nature of This Book

This book is written specifically for programmers interested in .NET security and cryptography, not for system administrators. Therefore, we do not attempt to describe more than a small fraction of the skills needed by professional system administrators. However, every programmer must have some administrative skills to be effective software developers, and security programming is no exception. Therefore, this book does explore some aspects of administration as it directly relates to the tasks of .NET security programming. This book is also not intended for professional cryptographers ^[1] or mathematicians, so it does not go too far in that theoretical direction either. However, to gain an appreciation for what goes on under the hood, it can be rather empowering for a programmer to have some understanding of the underlying cryptographic theory and related mathematics, so we provide some light coverage in that direction as well.

^[1] A cryptographer is one who designs and analyzes cryptographic algorithms, not one who merely uses a cryptographic library to incorporate cryptographic and security features into his or her programs.

As a result, this book takes a blended approach, covering fundamental cryptography theory as well as cryptographic and security programming on the .NET platform. We begin in this first chapter with an introduction to some of the more important overarching concepts of cryptography and security on the .NET platform, providing glimpses of the pieces that work together toward implementing secure .NET applications. In Chapter 2, we look at the theoretical fundamentals of cryptography, starting with the designs and cryptanalysis of some historically significant pencil-and-paper ciphers. Building on that theoretical framework, Chapters 3, 4, and 5 describe practical .NET programming techniques in the three main areas of modern cryptography: symmetric cryptography, asymmetric cryptography, and digital signatures. These three chapters provide extensive example code that demonstrates how to work with the relevant .NET Security Framework classes. Chapter 6 continues to explore encryption and digital signatures, but within the specialized context of XML cryptography. Chapters 7 and 8 show how the main programming techniques work for implementing role-based security and code access security features in .NET programs. Of course, distributed applications and the Internet have made many security issues more important than ever before, and Chapters 9 and 10 cover the most important aspects of ASP.NET security and .NET Web services security, respectively.

Risks Are Everywhere

When you start thinking about all the things that can go wrong, you may find yourself wondering if it all becomes a bit silly. The average citizen is, after all, not typically under CIA or FBI investigation (as far as we know) or the target of some espionage plot. If you let your imagination go too far, many of the risks that come to mind may seem rather far- fetched . You may even start to wonder if you should wrap your head in tinfoil just in case the aliens are trying to read your brain waves! Nevertheless, even though it may seem like a paranoid perspective, it is indeed true: Risks are everywhere, and the more important the data is, the more important the data security becomes. It is actually quite surprising how easily and how often dangers can crop up unexpectedly in the world of computing.

THINKING LIKE AN ATTACKER

You may have heard the old angler's advice: To catch a fish, you have to think like a fish. I was never too comfortable with that odd-sounding advice, since it is not at all clear exactly how a fish thinks. However, this advice is very applicable when you apply it to dealing with human adversaries. In particular, to protect yourself from attackers ^[2] and other such enemies, it pays to put yourself in their shoes and try to think the way they think.

^[2] We use the term attacker to refer to someone who gains unauthorized access for the purpose of stealing, forging , or destroying data. Such an attacker is often referred to as a cracker. The term hacker is often incorrectly used as a synonym for cracker, mainly due to the confusion that is so prevalent in mass media reporting on technical topics. The term hacker more correctly refers to a computer expert or enthusiast, often connoting extensive self-taught knowledge and an undisciplined attitude.

Perhaps one of the biggest problems is that nice folks like you and me have a very hard time thinking ultra -deviously, while the enemy often seems to have an endless supply of brainpower, time, energy, and mischievousness. Often, all we can do is try our best to play catch-up. Unfortunately, it is an uneven playing field in that if a single attacker finds just a single weakness, the algorithm is in jeopardy. In contrast, the weary defender must attempt to anticipate and deal with all potential weaknesses. To get a feel for the kinds of things that the enemy may try, let's look at some examples of the potential risks.

EXAMPLES OF RISKS AND PRESCRIBED REMEDIES

There is probably no limit to the number of ingenious tricks and traps that can be conceived of by our potential enemies. Security pitfalls that garden-variety email users might experience are conceptually identical to the security pitfalls that programmers must also be able to deal with. For example, most people do not encrypt their email correspondence, which is somewhat analogous to sending an open postcard rather than sending a letter in a sealed envelope. This oversight could be a risk, since it is quite easy to intercept email packets as they are routed through your ISP and through various routers over the Internet. As another example, an email virus could cause you grief by randomly selecting messages from your previously sent email and forwarding copies of them to contacts found in your address book. This could be very embarrassing if not downright costly. If you encrypted your sensitive correspondence, then these problems would be solved . Intercepted email packets would be unintelligible, and the virus just described would send only copies of gibberish to those unintended recipients. There are even email viruses that make file shares on arbitrarily selected folders, unexpectedly exposing large amounts of your information to others on your network. By simply encrypting those folders that contain sensitive information, such unintended file sharing becomes a nonissue. Of course, you should probably have already updated your virus scanner, defensively configured your email client program, and applied any necessary security patches to avoid the virus in the first place. But then, email and file system encryption provides a nice extra layer of security just in case all other up-front efforts fail. These examples prove the importance of using encryption in the world of email. By analogy, it should be clear that encryption is important to use wherever sensitive data may be exposed in the world of programming as well.

Using digital signatures is another way to avoid security risks. Unfortunately, most email users do not have a personal digital ID for signing their important email correspondence. If you do not digitally sign your most sensitive email messages, then someone could send a fraudulent email in your name to someone in an attempt to frame you with bogus evidence or to commit you to some compromising position. If you make a habit of digitally signing all of your sensitive correspondence, then the recipients of your critical messages will expect a signature that they can verify and thus will be able to discern that such a bogus email was not actually from you. This example shows the importance of using digital signatures in the world of email, and by analogy, it shows that it is also important to use digital signatures where appropriate in your own programming.

A FALSE SENSE OF SECURITY

Unfortunately, people often assume that using a computer in a familiar or routine manner is inherently safe, when in fact it is never entirely safe. Here is a startling example: During the summer of 2002, Microsoft accidentally distributed a copy of the Nimda worm in its Korean language version of Visual Studio .NET. Fortunately, as it turned out, the copy of the Nimda worm was included in such a way that it did not in fact result in any realistic risk of infection to anyone 's system. But who would have ever thought twice about the security ramifications of installing such an application from such an established and trusted software vendor? This news item was certainly a wake-up call ^[3] to programmers around the world! There are many other examples in which our implicit trust and assumption of security turns out to be questionable or even dangerously wrong. How often have you heard of newly discovered security vulnerabilities, followed shortly by the announcement of a corresponding security patch? Sadly, this sort of thing happens on a much too frequent basis. The good news is that the .NET Security Framework and the .NET platform can be used to effectively protect applications and data from many of these potential dangers. Unfortunately, security will never be a completely solved problem, but .NET goes a long way in helping us write programs that can protect users better than ever before.

^[3] Earlier, in the history of Unix, there was another very interesting and convincing wake-up call regarding the risk we take when we blindly trust the security of the software that we use. To read more about it, see what Ken Thompson (the father of Unix) has to say about shaken trust at http://www.acm.org/classics/sep95/. As you will see, the story has a fascinating twist.

Software vendors , system administrators, programmers, and users all need to become much more vigilant of the myriad risks and aware of their prescribed precautions . Everyone must be on guard against falling into a false sense of security. Clearly, security is an important issue that must be recognized by all computing professionals. This is especially true now that our world has become so heavily dependent on computing in almost all facets of our lives, and our systems have become so thoroughly interconnected by way of the Internet.