[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A hole in esp-stream-01
Hello everybody,
in the beginning of September, Angelos Keromytis pointed out a fundamental
weakness of esp-stream-01 to me. This weakness is similar to one described
in Steve Bellovin draft for the DES-CBC cipher, bute even more dangerous.
In the current form, esp-stream can only be used if certain risks are taken
into account, or are actively countered.
The attacks of Angelos all rely on the fact that there is no strong integrity
check in esp-stream. Due to the fact that current MACs are too slow to be used
in applications that need stream ciphers for performance purposes, we either
need a (about 10 times) faster MAC, or esp-stream has to be enhanced to provide
inherent integrity protection...
I would like to present the problem here, and then go into possible solutions,
being interested what the group thinks of them. Please note that substantial
parts of this originate from Angelos.
> Host1 communicates with Host2. They use IP tunneling, ESP stream and
> no authentication. The format of the packets would be:
>
> [External IP header] [SPI] [Offset] [Internal IP header] [Payload]
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Encrypted
>
> Assume: attacker in the middle who also has login access to
> Host1/Host2 OR (if Host1/Host2 are firewalls) has access to some
> machine(s) behind those firewalls, OR Host1/Host2 don't do any sort of
> filtering and have their IP forwarding turned on.
>
> In any case, attacker does:
> Internal_IP_header.destination_address = Destination_Address
XOR Attacker_Address
> and recomputes the checksum. Now, this might seem hard, but it
> actually isn't; the attacker knows in fact all the information on the
> Internal IP header except the ip_id field and the checksum. The ip_id
> field however is predictable (and in fact, in most IPsec
> implementations would just be External_IP_header.ip_id - 1). So the
> attacker actually knows all the fields in the header (since he knows
> all the other fields, he can compute the checksum). Knowing the
> checksum, he can compute the new checksum (with the new destination
> address) and then do:
> Internal_IP_header.checksum = Old_Checksum XOR New_Checksum
>
> and then just let the packet go. If attacker has access to the
> machine, he can use an alternate local address that the one the
> particular application is listening to.
>
> If UDP is used as the transport protocol (very probable, considering
> multicast), the destination port can be changed instead, simplifying
> things, if UDP checksums are disabled. If UDP checksums are enabled,
> then the value of the (decrypted) checksum should not be reported when
> the kernel reports the failed checksum verification, otherwise the
> packet can be corrected and resent.
Another attack:
> [...] i think you can also do it even
> if attacker has no access to hosts, unless the destination host is
> very very careful: change BOTH source and destination addresses in the
> internal IP header to make the packet look like it originated from
> some internal host (or the firewall) and destined to some other host
> on the Internet (the attacker). So the attacker doesn't *need* to have
> access to the machines/networks actually. If he does, there's another
> attack which i came up with: just toggle the lowest order bit in the
> destination port and in the UDP/TCP checksum; this will allow the
> packet to still be valid, but go to another port which the attacker
> could be monitoring.
Conclusion:
> Under the assumptions you gave, all pure encryption algorithms which XOR
> the data stream to a key stream are implicitly broken.
Possible reactions:
> 1) Security Concerns need to be updated that this type of attack is
> easy and bound to succeed for any attacker that has access to these
> hosts.
Attacks are possible if the attacker can actively access the wire. So
this is not a good way to go anymore. The algorithm has to be changed!
> 2) IPSEC definitively **needs** a fast symmetric MAC. This might be a MAC
> with limited strength, as long as it holds longer that reception of data
> is perceived as valid. I am working on this, but until now no reasonably
> strong and fast MAC has turned up. This would be the best and most
> generic counter measure.
Still nothing in sight. It is a very strange phenomenon. As soon as you
create a fast-enough MAC, breaking it can be done even faster... sigh...
> 3) The operation to apply a key stream to the data may be changed. Use
> something different from XOR. (e.g. ?)
Comments on this one? I was thinking of e.g. a permutation table, where
the key stream and the plaintext denote an index, to an entry.
> 4) Chain the data such that modification of one byte affects all data (or at
> least everything afterwards. This would be the easiest counter-measure
> for now.
So I said. But how to do it?
The best approach IMNSHO is 2). But I see the following alternatives:
a) do a CRC over everything but the last 4 bytes, then XOR this CRC to the
last 4 bytes before encryption. This just hopes that something different
will do the error detection, including the last four bytes...
b) Add preceeding plaintext byte and cypertext byte to current byte before
encryption. C(n)=C(C(n-1)+P(n-1)+P(n)). This should deny changing plain-
text unless you know the plaintext anyway.
Comments on this one?
Friendly greetings,
Germano Caronni
--
<...cookie space for rent...>
Germano Caronni caronni@tik.ee.ethz.ch http://www.tik.ee.ethz.ch/~caronni
PGP-Key-ID:7B7AE5E1 gec@acm.org 997C6DC4AF930A5D2D5D6AEAA196C33B