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 )
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.
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 veriﬁcation 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 ﬁxed
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
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 ﬂow 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.)
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
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 deﬁned by saying that it can be
constructed from the original sequence by the removal of zero or more
The ﬁrst 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 ﬁnd out who is communicating with
whom, how much, and when. This is called trafﬁc 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 trafﬁc analysis on our secure channel.
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 modiﬁed 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
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 ﬁrst and then authenticate
the ciphertext (encrypt-then-authenticate); authenticate ﬁrst 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 ﬁrst. There are
theoretical results that show that, given certain speciﬁc deﬁnitions of secure
encryption and authentication, the encrypt-ﬁrst solution is secure, whereas
the other approaches are insecure. If you look at the details, it turns out that
authenticate-ﬁrst is only insecure if the encryption scheme has a speciﬁc type
of weakness. In practical systems, we never use encryption schemes with such
The Secure Channel
weaknesses. However, these weak encryption schemes satisfy a particular
formal security deﬁnition. Applying the MAC to the ciphertext of such a
weak encryption scheme ﬁxes 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 ﬁrst is that it is more efﬁcient
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 ﬁeld) then Bob
will discard it. With encrypt-ﬁrst, 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-ﬁrst, 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-ﬁrst, 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-ﬁrst, 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 ﬁrst. In the encryptﬁrst conﬁguration, the MAC input and MAC value are both visible to Eve.
In the authenticate-ﬁrst conﬁguration, 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-ﬁrst 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