[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bellovin's and Ashar's attacks



    The attacks we've been talking about for the last few days are 
    unrealistic.  As pointed out by Steve Bellovin, a simple replay is 
    difficult to counter because the the legitimate user and the attacker 
    can occupy the same end point at different times. I think the situation 
    is worse that indicated by Steve.  If the attacker has access to a 
    machine behind the firewall, then that attacker can simply listen to 
    the plaintext traffic as it is sent from that host to the firewall. 
    There is not reason to mount a complex replay attach -- just listen.  I 
    do not want to add a huge amount of complexity to protect against an 
    attacker who can read the traffic before it even gets protected.  If we 
    want to protect data from other users of the same host, then the 
    encryption better be applied before it is tranmitted at all.  In other 
    words, not firewall crypto.

  Router crypto can be used in several different ways; depending on your 
  assumptions, different attacks may be possible.  Consider, for
  example, an Internet service provider who offers shell acounts.  
  (There are many such.)  They may have a cluster of machines with a 
  single high-end crypto box -- indeed, users may be assigned to an 
  arbitrary box at login time.  In this case, though, the users have no 
  access to the physical cable plant -- but they can park themselves on 
  arbitrary ports.

They can also run arbitrary programs, including sniffers.

  Looked at more generically, the attacks we've been discussing involve 
  two different shared resources:  the host (for my CBC cut-and-paste 
  attack, and the cable/router complex.  If your enemies are only on the 
  local machine, as above, the wiring isn't at issue.  If your enemies 
  are only outside the crypto box -- which is the case for many 
  departmental LANs -- then router-based crypto is perfectly acceptable, 
  and the risks we've been exploring here don't apply.  (This case -- 
  which I regard as common -- is why I use the term ``router-based 
  crypto'' instead of ``firewall''.  My departmental LAN is, as I've 
  said before, a single multiprocessor machine with a funny backplane.  
  (In deference to those who've switched to other physical media, I'll 
  delete my usual description of ``long skinny yellow backplane.)) If 
  your wiring is exposed, you have to move the crypto back to the host.
  
In the case of the shared host, we need to ensure that the protocol 
conveys information necessary to prevent leakage when the enemies 
serially reuse the same resource, a port in the recent examples.  
discading the key when the port is closed sounds great.  Better yet, 
Discard the key and tell the other key management daemon that you did 
it.

In the shared comms case, I have a real hard time.  If your enemy is 
sharing the comms between you and your crypto, then you shouldn't bther 
with the crypto at all.

Russ
Follow-Ups: