Setting the Stage: Key Definitions and Scenarios in Cryptography

for RuBoard

Before describing the contents of the .NET Framework's cryptographic libraries, we briefly review and define some of the basic concepts of cryptography: symmetric algorithms, asymmetric algorithms, cryptographic hash functions, and digital signatures. We introduce these concepts in the context of basic two-party communication scenarios requiring one or more features of message security (confidentiality, integrity, and authentication).

NOTE

Cryptography is a rich and active field of ongoing research. It is impossible to provide a strong introduction to the theory and practice of modern cryptographic techniques in only two chapters, so we do not attempt to do so here. We assume that the reader is already familiar with cryptography; our goal in these two chapters is to demonstrate the features available in the .NET Framework to the knowledgeable reader.


To assist in our scenario descriptions, it is helpful to introduce some characters. A large assortment of common characters have grown up over the years in the field of cryptography to help explain scenarios, and the two most common characters are Alice and Bob, shown in Figure 30.1.

Figure 30.1. Alice and Bob.

graphics/30fig01.gif

Alice and Bob are two parties who want to communicate information over an open channel, such as an insecure network. In our first scenario, Alice wants to communicate some sensitive information to Bob in such a way that no one listening to the channel can learn the sensitive information. Alice wants to keep her message secret from everyone but Bob. In particular, Alice knows that Eve, an eavesdropper, has access to the network Alice must use to talk to Bob, so Eve will be able to listen to every communication between Alice and Bob. Figure 30.2 depicts Alice, Bob, and Eve in this scenario; the message M represents the sensitive information Alice wants to communicate to Bob. (Like Alice and Bob, Eve is a common character in cryptography scenarios and always represents an eavesdropper who can passively listen to communications.)

Figure 30.2. The basic secrecy scenario: Alice wants to communicate information to Bob without Eve learning the contents of the communication.

graphics/30fig02.gif

Ensuring Confidentiality with Symmetric Algorithms

Alice wants to send Bob the sensitive information in such a way that Eve cannot learn it, even though Eve will hear everything Alice says. How can Alice accomplish this task? Cryptography provides multiple possible answers. For example, if Alice and Bob have previously met and agreed on a shared secret key known only to the two of them, Alice can use this shared secret key to encrypt message M that she wants to send to Bob. Figure 30.3 shows Alice encrypting message M using the secret key K and then sending the encrypted message to Bob. The encrypted message is represented as E(M,K), the result of encrypting message M using the secret key K using encryption algorithm E. On receipt, Bob uses his own copy of the secret key K to decrypt the encrypt message, applying decryption algorithm D, to obtain message M.

Figure 30.3. Using a symmetric algorithm cipher to securely communicate a message from Alice to Bob.

graphics/30fig03.gif

The algorithms used by Alice and Bob in Figure 30.3 used the same secret key K as input to both the encryption and decryption functions, and the encryption used in this scenario is known as a secret key cipher or a symmetric algorithm ("symmetric" because Alice and Bob use the same key K to encrypt and decrypt). The K key must be kept secret between Alice and Bob to preserve the secrecy of any information encrypted using K. In the .NET Framework, these types of encryption and decryption algorithms are represented by the SymmetricAlgorithm class and its subclasses; these classes are described in detail in the "Using Symmetric Algorithms" section later in this chapter.

Symmetric algorithms are a key tool in the cryptographer's toolbox, but using them properly requires that Alice and Bob already possess a shared secret key K before any information can be encrypted. Pre-shared secrets are acceptable in situations where Alice and Bob have some out-of- band mechanism for sharing the key (perhaps they met previously in person), but if Alice and Bob have never met before, they will not share any secret information between them that could be used as a secret key or to generate a secret key. For such scenarios, we turn to the other major class of encryption algorithms in the cryptographer's bag of tricks ”asymmetric algorithms.

Ensuring Confidentiality with Asymmetric Algorithms

Asymmetric algorithms differ from symmetric algorithms in that an asymmetric algorithm uses different keys to perform encryption and decryption operations. In Figure 30.3, Alice used secret key K to encrypt the message she sent to Bob, and Bob used the same key K to decrypt the encrypted message. With an asymmetric encryption algorithm, the encryption and decryption keys are different (but mathematically related ). Each party wanting to receive encrypted communications generates a pair of keys: a public key that is used to encrypt information to the party and a private key that is used to decrypt encrypted messages. Asymmetric algorithms are also known as public key algorithms. Figure 30.4 depicts a sample scenario in which Alice uses an asymmetric algorithm and Bob's public key to encrypt information for Bob.

Figure 30.4. Using an asymmetric encryption algorithm to securely communicate a message from Alice to Bob.

graphics/30fig04.gif

On receipt, Bob decrypts the information he received from Alice using his private key. Notice that in contrast to the symmetric encryption sample shown in Figure 30.3, Alice and Bob do not share any common secret key. Anyone wanting to send Bob encrypted information can do so if he or she holds a copy of Bob's public key and, because the public key is not used for decryption, it need not be kept secret. Indeed, it is common for users' public keys to be made available through an online directory or other database so that potential correspondents can easily find copies of them.

NOTE

When Alice and Bob use a symmetric algorithm to communicate securely, they mutually agree on a secret key to use and know that each other has a copy of that key. The situation is different when using asymmetric algorithms because Bob generates his pair of public and private keys without input from anyone else. When Alice obtains a copy of Bob's public key, she needs to know that the public key claiming to belong to Bob really does and matches Bob's private key. For example, if Alice downloads a copy of a public key claiming to belong to Bob from an online directory, she needs to obtain sufficient evidence to convince her that the public key really does belong to Bob.

There are many different techniques for conveying trust information about Bob's public key to Alice. Ultimately, the specific evidence that is necessary to convince Alice to use the public key depends on Alice's particular trust policy. The situation is very similar to the operation of the CLR Security Policy described in Chapter 8, "Membership Conditions, Code Groups, and Policy Levels: The Brick and Mortar of Security Policy." The policy system decides what permissions to assign to an assembly based on presented evidence. Trust management systems for public key cryptography, including public key infrastructures (PKIs), are an active area of research and development. An in-depth discussion of various PKIs is outside the scope of this book. When dealing with asymmetric algorithms, we will assume that parties using public keys have been successfully convinced of the identities of the owners of their corresponding private keys.


Classes implementing asymmetric algorithms in the .NET Framework are represented by the AsymmetricAlgorithm class and subclasses of it. The section, "Using Asymmetric Algorithms," later in this chapter, discusses asymmetric algorithms in greater detail.

Using Cryptographic Hash Functions for Message Integrity and Authentication

Encryption algorithms are the bread-and-butter of cryptographers and, when used properly, can keep your data secret from unauthorized parties. However, encryption algorithms themselves do not provide the two other key features of message security ”integrity and authentication. To provide these features, we need to discuss another fundamental building block used in security protocols ”the cryptographic hash function. Cryptographic hash functions accept as input an arbitrary amount of binary data and compute from that data a "hash value" ”a fixed-length value that is mathematically related to the input data. Hash functions are sometimes called "message digest algorithms" because they compute a "digest" (the hash value) of whatever data they are given.

NOTE

Obviously, any function that maps a binary string to a fixed-length value could be considered a hash function, but for a hash function to be useful cryptographically , it must additionally be a one-way function that is collision-resistant.

  • A one-way function is a function that is easy to compute but computationally unfeasible to invert. Let H(x) be a hash function, M an input message, and h = H(M) the hash value of M. Then we say that H(x) is a one-way hash function if it is (a) easy to compute h given M, but (b) for any given h', hard to find an M' that satisfies H(M') = h'.

  • A collision-resistant function H(x) is a function for which it is computationally unfeasible to find a pair of distinct inputs M and M' that have the same output H(M) = H(M').

These two properties distinguish cryptographic hash functions from other types of checksums, such as CRC-32 or the algorithm for computing the check digit for a credit card number.


For a good cryptographic hash function that generates hashes of length n bits, the probability that any input message has a particular hash value h is 2 -n . This makes hash values extremely useful when trying to detect whether a message M has been tampered with in transit. If h = H(M) is the hash value of M, changing a single bit of M has a 50/50 chance of independently changing each bit in the hash value h. (The "Using Cryptographic Hash Functions" section later in this chapter discusses the classes implementing cryptographic hash functions in the .NET Framework; the base class for all hash function implementations is the HashAlgorithm class.)

Cryptographic hash functions are the cryptographer's weapon of choice to protect the integrity of data in transit. Unlike message secrecy, in which Alice and Bob are concerned about protecting their data from Eve the eavesdropper, in a message integrity scenario, the threat is that data in transit will be modified by a malicious, active attacker. Figure 30.5 shows a typical message integrity scenario and introduces a new character ”Mallet. Mallet represents an active adversary that not only listens to all communications between Alice and Bob but can also modify the contents of any communication he sees while it is in transit. When Alice sends message M to Bob, Mallet intercepts M and may choose to change any of the bits in the message, creating message M'. Mallet then forwards M' to Bob. Bob receives M' and must determine whether M' differs from the original message M Alice sent.

Figure 30.5. The basic integrity scenario: Alice wants to communicate information to Bob so that any tampering performed by Mallet will be detected .

graphics/30fig05.gif

Cryptography hash functions are a fundamental building block of message integrity protocols, but they are not by themselves sufficient because Mallet can also calculate hash values. If Alice sends Bob the message M plus the result of hashing M, H(M), Mallet could replace M with M' and calculate a new hash value H(M'). Bob would receive M' and H(M') and believe that the message was unaltered.

What can Alice do to guarantee that any tampering by Mallet of her message will be detectible by Bob? One possibility, if Alice and Bob share a secret key for a symmetric encryption algorithm, is to send the message M and its hash to Bob encrypted. Figure 30.6 shows this approach. First, Alice generates the message M that she wants to send to Bob. Alice then calculates the hash of M, H(M), using an agreed-upon cryptographic hash function. Alice concatenates the message with its hash, creating M H(M), and then encrypts the entire package to Bob using the shared secret key K. (The operator denotes concatenation.) The message that Alice sends, and that Mallet sees, is E((M H(M)), K).

Figure 30.6. Using symmetric encryption and a hash function to provide message integrity between Alice and Bob.

graphics/30fig06.gif

Now, Mallet cannot tamper with Alice's message without being detected with high probability, because Mallet sees only ciphertext and does not know the secret key K. If Mallet changes any of the bits in the ciphertext corresponding to the encryption of message M, those changes will impact Bob's decryption of the received message.

Bob will decrypt the message from Alice and see an M' different from M, which (again, with high probability) will not have the same hash value M. (Depending on the type of encryption used, Bob may also see a modified hash value H(M'') which corresponds to neither M nor M'.) As a result, Bob will detect the tampering. This technique, hash-and-encrypt, is used in the sample functions shown in Listings 30.8 and 30.9 to protect a file stored on disk from tampering.

NOTE

The key to making the protocol depicted in Figure 30.6 work is that Alice protected the hash of the message using a piece of secret information shared with Bob, namely their secret encryption key. If Mallet can break the encryption, he could see the plain text M, change that message into M', change the hash value from H(M) to H(M'), and re-encrypt the altered package M' H(M') for Bob.


Keyed Hash Functions

The protocol depicted in Figure 30.6 provides message security and integrity but depends on encryption to provide both of those features. We can remove the encryption requirement, however, by changing the type of hash function we use in the protocol. By replacing the hash function with a keyed hash function, we can provide message integrity without also requiring encryption.

A keyed hash function is a hash function that computes a hash value for some data mixed with a secret key. That is, the hash value computed for some data depends on both the data and the secret key; change a bit in either the data or the key value, and the output value will change. Implementation classes for keyed hash functions are described in the "Using Keyed Hash Functions" section; all keyed hash functions are subclasses of the KeyedHashAlgorithm class.

Figure 30.7 shows a message integrity protocol based on a keyed hash function.

Figure 30.7. Using a keyed hash function to provide message integrity between Alice and Bob.

graphics/30fig07.gif

Alice and Bob share a secret key K, but in this protocol, K is a key for the keyed hash function H, not a symmetric encryption algorithm. For message M, Alice computes the keyed hash H(M,K) corresponding to her message and secret key and sends Bob both the message and the hash value. Mallet sees both the message and the hash value on the network, but he cannot make undetectible modification to either of them. If Mallet wants to change M into M' undetected by Bob, he must also change the hash value H(M,K) into H(M',K). However, Mallet does not know K, so he cannot easily recompute the hash value to account for his changes in the message. Any tampering with message M will be easily detected.

The keyed hash function Alice used in Figure 30.7 not only allows Bob to verify the integrity of message M, but also authenticates that M was generated by Alice. Assuming that only Alice and Bob know secret key K, only Alice could have generated the hash value H(M,K) and sent it to Bob. When a shared secret exists between two parties, it may also be used to provide data origin authentication (the message must have originated with Alice because only she and Bob hold secret key K). Bob knows that the message he received originated with Alice because their shared secret was used with the message to produce the keyed hash value.

Digital Signatures: Authentication and Integrity Using Asymmetric Algorithms

It is also possible to use asymmetric algorithms to provide authentication services, in particular, digital signatures. We saw how the asymmetry between the public and private keys in a key pair can be used to allow anyone to encrypt a message to Bob that only Bob can decrypt (refer to Figure 30.4). In that scenario, any party wanting to encrypt information to Bob used Bob's widely available public key to perform the encryption. Bob decrypted such encrypted information by applying his private key to the encrypted messages. We now demonstrate data origin authentication using an asymmetric algorithm that works by leveraging the asymmetry in reverse. Figure 30.8 shows a simple digital signature protocol between Alice and Bob; Alice sends Bob message M along with a digital signature for M that she creates using the hash of M and her private key. (The digital signature is denoted SIG(H(M), K PRIV_A ) because it depends both on the content of the message and Alice's private key.) Bob (or anyone) receiving the message can verify the signature by applying Alice's public key, K PUB_A , to the signature to obtain the signed hash value. Bob then computes his own hash of M and compares his result with the signed hash value. Any discrepancy indicates that the message has changed since it was signed by Alice.

Figure 30.8. Using an asymmetric algorithm and a hash function to digitally sign a message from Alice to Bob.

graphics/30fig08.gif

NOTE

Asymmetric algorithms tend to have size limits on the amount of data that can be signed or encrypted using a particular key pair; typically these limits are associated with the size of the public key parameters. Thus, in Figure 30.8, the signature is computed using the hash of message M instead of M itself. Signing a hash of the message still preserves the integrity of the message and avoids the length limits inherent in the algorithm. Asymmetric algorithm size limits are discussed in more detail in the section, "Using Asymmetric Algorithms," later in this chapter.

Whether an asymmetric algorithm can be used for encryption or generating digital signatures depends on the particular algorithm in question. Both asymmetric algorithms that ship with the .NET Framework SDK, the RSA public key cipher (named after its inventors, Ron Rivest, Adi Shamir, and Leonard Adleman) and the Digital Signature Algorithm (DSA), can be used to create and verify digital signatures. However, only the RSA algorithm supports encryption.


This concludes our brief review of asymmetric algorithms, symmetric algorithms, cryptographic hash functions, and digital signatures. In the next section, we begin a detailed discussion of the classes and objects in the .NET Framework that implement these algorithms.

for RuBoard


. NET Framework Security
.NET Framework Security
ISBN: 067232184X
EAN: 2147483647
Year: 2000
Pages: 235

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net