1. Trang chủ >
  2. Công Nghệ Thông Tin >
  3. An ninh - Bảo mật >

1: Properties of a Secure Channel

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (2.78 MB, 385 trang )


Part II

Message Security

We always talk about transmitting messages from Alice to Bob, and most of

the time our mental image is of two separate computers sending messages to

each other over a network of some sort. Another very interesting application

is storing data securely. If you think of storing data as transmitting it to

the future, then all the discussions here apply. Alice and Bob might be the

same person, and the transmission medium could be a backup tape or a USB

stick. You still want to protect the medium from outside eavesdroppers and

manipulations. Of course, when you send data to the future, you cannot have

an interactive protocol, since the future cannot send a message back to the past.

7.1.2 Key

To implement a secure channel, we need a shared secret. In this case we

will assume that Alice and Bob share a secret key K, but that nobody else

knows this key. This is an essential property. The cryptographic primitives

can never identify Alice as a person. They can at most identify the key. Thus

Bob’s verification algorithm will tell him something like: ‘‘This message was

sent by somebody who knows the key K and who played the role of Alice.’’

This statement is only useful if Bob knows that knowledge of K is restricted,

preferably to himself and Alice.

How the key is established is not our business here. We just assume the key

is there. We will talk about key management in great detail in Chapter 14. The

requirements for the key are as follows:

The key K is known only to Alice and Bob.

Every time the secure channel is initialized, a new value is generated for

the key K.

The second item is also important. If the same key is used over and over

again, then messages from older sessions can be replayed to Alice or Bob, and

lead to much confusion. Therefore, even in situations where you have a fixed

password as key, you need a key negotiation protocol between Alice and Bob

to set up a suitable unique key K, and you must re-run this protocol every

time a secure channel is established. A key such as K that is used for a single

communication session is called a session key. Again, how K is generated will

be discussed in Chapter 14.

The secure channel is designed to achieve a security level of 128 bits.

Following our discussion in Section 3.5.7, we will use a 256-bit key. Thus, K is

a 256-bit value.

7.1.3 Messages or Stream

The next question is whether we look at the communications between Alice

and Bob as a sequence of discrete messages (such as e-mails) or as a continuous

stream of bytes (such as streaming media). We will only consider systems that

Chapter 7

The Secure Channel

handle discrete messages. These can trivially be converted to handle a stream

of bytes by cutting the data stream into separate messages and reassembling

the stream at the receiver’s end. In practice, almost all systems use a discrete

message system at the cryptographic layer.

We also assume that the underlying transport system that conveys the

messages between Alice and Bob is not reliable. Even a reliable communication

protocol like TCP/IP does not form a reliable communication channel from a

cryptographic point of view. After all, the attacker can easily change, remove,

or insert data in a TCP stream without interrupting the flow of data. TCP is

only reliable with respect to random events such as loss of packet. It does not

protect against an active adversary. From our adversarial point of view, there

is no such thing as a reliable communication protocol. (This is a good example

of how cryptographers view the world.)


Security Properties

We can now formulate the security properties of the channel. Alice sends

a sequence of messages m1 , m2 , . . . that are processed by the secure channel

algorithms and then sent to Bob. Bob processes the received messages through

the secure channel algorithms, and ends up with a sequence of messages

m 1 , m2 , . . . .

The following properties must hold:

Eve does not learn anything about the messages mi except for their timing

and size.

Even when Eve attacks the channel by manipulating the data that is being

communicated, the sequence m1 , m2 , . . . of messages that Bob receives is

a subsequence of m1 , m2 , . . ., and Bob learns exactly which subsequence

he received. (A subsequence is best defined by saying that it can be

constructed from the original sequence by the removal of zero or more


The first property is secrecy. Ideally, Eve should not learn anything about

the messages. In real life, this is very hard to achieve. It is extremely hard

to hide information such as the size or the timing of the messages. The

known solutions require Alice to send a continuous stream of messages at

the maximum bandwidth that she will ever use. If she doesn’t have any

messages to send, she should invent some trivial ones and send those. This

might be acceptable for military applications, but it is not acceptable for most

civilian applications. Given that Eve can see the size and timing of messages

on a communication channel, she can find out who is communicating with

whom, how much, and when. This is called traffic analysis. It yields a host of

information, and is extremely hard to prevent. This is a well-known problem

with other secure channels, like SSL/TLS, IPsec, and SSH. We will not solve it in

this book, so Eve will be able to perform traffic analysis on our secure channel.



Part II

Message Security

The second property ensures that Bob only gets proper messages, and that

he gets them in their correct order. Ideally, we would want Bob to receive

the exact sequence of messages that Alice sent. But none of the real-world

communications protocols are reliable in a cryptographic sense. Eve can always

delete a message in transit. As we cannot prevent the loss of messages, Bob will

necessarily have to make do with getting only a subsequence of the messages.

Note that the remaining messages that he does receive are in order. There

are no duplicates, no modified messages, and no bogus messages sent by

someone other than Alice. As a further requirement, Bob learns exactly which

messages he has missed. This can be important in some applications where the

interpretation of the message depends on the order in which they are received.

In most situations, Alice wants to ensure that Bob gets all the information she sent him. Most systems implement a scheme whereby Bob sends

acknowledgments (either explicit or implicit) to Alice, and Alice resends any

information for which she didn’t receive an acknowledgment from Bob. Note

that our secure channel never takes the initiative in resending a message. Alice

will have to do that herself, or at least the protocol layer that makes use of the

secure channel will have to do that.

So why not make the secure channel reliable by implementing the resend

functionality inside the secure channel? Because that would complicate the

secure channel description. We like to keep the security-critical modules

simple. Message acknowledgments and resends are standard communication

protocol techniques, and they can be implemented on top of our secure channel.

Also, this is a book about cryptography, not about basic communication

protocol techniques.


Order of Authentication and Encryption

Obviously we will apply both encryption and authentication to the message.

There are three approaches [7, 82]: we can encrypt first and then authenticate

the ciphertext (encrypt-then-authenticate); authenticate first and then encrypt

both the message and the MAC value (authenticate-then-encrypt); or both

encrypt the message and authenticate the message and then combine (such

as concatenate) the two results (encrypt-and-authenticate). There is no simple

answer for which method is best.

There are two main arguments in favor of encrypting first. There are

theoretical results that show that, given certain specific definitions of secure

encryption and authentication, the encrypt-first solution is secure, whereas

the other approaches are insecure. If you look at the details, it turns out that

authenticate-first is only insecure if the encryption scheme has a specific type

of weakness. In practical systems, we never use encryption schemes with such

Chapter 7

The Secure Channel

weaknesses. However, these weak encryption schemes satisfy a particular

formal security definition. Applying the MAC to the ciphertext of such a

weak encryption scheme fixes it and makes it secure. Having these theoretical

results is valuable. But these theoretical results don’t always apply to real-life

encryption schemes. In fact, there are similar proofs that these problems do not

occur at all for stream ciphers (such as CTR mode) and CBC-mode encryption

when the nonce or IV is authenticated.

The second argument in favor of encrypting first is that it is more efficient

in discarding bogus messages. For normal messages, Bob has to both decrypt

the message and check the authentication, irrespective of the order they were

applied in. If the message is bogus (i.e., has a wrong MAC field) then Bob

will discard it. With encrypt-first, the decryption is done last on the receiver

side, and Bob never has to decrypt bogus messages, since he can identify and

discard them before decryption. With authenticate-first, Bob has to decrypt

the message before he can check the authentication. This is more work for

bogus messages. The situation in which this is relevant is when Eve sends

Bob a very large number of bogus messages. With encrypt-first, Bob saves

the work of decrypting them, which reduces the CPU load. Under some very

special circumstances, this makes a denial-of-service (DOS) attack a little bit

harder, though only by a factor of at most approximately two. Further, in

many real-life situations, a more effective DOS attack works by saturating the

communication channel rather than by bogging down Bob’s CPU.

The main argument for encrypt-and-authenticate is that the encryption and

authentication processes can happen in parallel. This can increase performance

in some situations. Under the encrypt-and-authenticate composition approach,

an attacker can view the MAC tag of the initial message itself. This is because

the MAC is not encrypted (unlike the authenticate-then-encrypt approach)

and because the MAC is not of an encrypted value (unlike the encryptthen-authenticate approach). MACs are designed to protect authenticity, not

privacy. This means the MAC in an encrypt-and-authenticate approach could

leak private information about the underlying message, thereby compromising

the privacy of the secure channel. As with authenticate-first, there are also some

underlying encryption schemes that are insecure when used in an encrypt-andauthenticate approach. With judicious choice of the underlying MAC and the

underlying encryption scheme, and by including additional data like the nonce

in the input to the MAC, the encrypt-and-authenticate approach can be secure.

There are two main arguments in favor of authenticating first. In the encryptfirst configuration, the MAC input and MAC value are both visible to Eve.

In the authenticate-first configuration, Eve only gets to see the ciphertext and

the encrypted MAC value; the MAC input (i.e., the plaintext) and actual MAC

value are hidden. This makes it much harder to attack the MAC than in the

encrypt-first situation. The real choice is which of the two functions is applied

last. If encryption is applied last, then Eve gets to attack the encryption function


Xem Thêm
Tải bản đầy đủ (.pdf) (385 trang)