[Download postscript version]

Threat Analysis

 

In this threat analysis we will identify possible threats and show how they are handled by SMIF.

1. Mallory blocks key update to Alice and then keeps sending her messages with the old session key.
   Solution: Here we clearly have the problem that an unauthorized sender directly forwards messages to Alice. The simple solution to this scenario is to use the sender authorization described in section 7. Because the sender is always authorized in these architectures, Mallory cannot send bogus messages directly if she is not authorized to send. If she is an authorized sender then she could send a message to Alice anyway.
   In the case where all the senders share a common sender key and send the messages directly to the group, the attack becomes dangerous if Mallory was expelled from the authorized senders and she blocks the key update to Alice. Later Mallory still uses her old sender key to directly send forged packets to Alice. To prevent this attack we can use the server based broadcast scheme. Here only the server can send messages to the multicast group and signs each message with his private key.
2. Mallory steals Trent's private key and forwards forged messages to the group members.
   There's no real solution to this kind of attack. Our assumption is that Trent is a fully trusted server and that his private key is not disclosed. Since our architecture relies on this assumption we can not protect ourselves from this attack.
3. Multiple members collaborate to get more keys or joining the group twice to get more keys.
   Solution: This does not help at all since all the keys in the key hierarchy are distinct. This attack can be powerful if we make multiple keys at one level equal which would simplify the key management but also lowers the security. The attack where a receiver shares its key with an outside person is not a valid attack since the receiver can as well share all the multicast information with that person anyway. In the same way when a valid sender shares his sending key with an outsider we don't try to prevent since that fraudulent person can forward packets to the multicast group for the outsider anyway.

 
• Multicast as a Tool of Threat