[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Perfect forward SECURITY (uni- vs bi-directional impersonation)'
> From hugo@watson.ibm.com Mon Jan 9 12:33 PST 1995
> From: hugo@watson.ibm.com
> Is impersonation in the other direction possible? That is:
> Will the adversary E be able to impersonate B when exchanging a key with A
> (by just knowing A's private key but not B's private key)? Two answers:
>
> 1) In the case of DH authenticated with RSA (or any other digital) signature
> the answer is: NO! (When B sends g^y he authenticates it with B's private
> key).
> 2) In the case of DH authenticated with the SKIP master key a^ij the answer is:
> YES!
>
> No doubt that the first case has a (significant) advantage over the second.
> For example, if A's private key was exposed it does not mean that I
> want the adversary E to be able to impersonate myself to A. By doing that
> E could have A giving her information that A is supposed to release ONLY
> if I authenticated myself to A.
> (Notice that the knowledge of A's private key does not mean necessarily
> that the adversary has access to all information kept by A).
I disagree. In virtually any circumstance that IPSP is likely to be
used in, E having A's long term authentication key will mean that
to the network E *is* A, and therefore E can access any information
that A can access.
I cannot imagine an IPSP scenario (through any combination of operating
system or security policy) where there is information that is under
the legitimate control of A, that A will not provide to A (i.e to itself)
but A will provide this information to B.
The point is, rather than impersonating as B to break into A's
resources, it will almost always suffice to become A to do the
same thing (something that is clearly possible in case of compromise
of A's signature key).
Whereas I am having difficulty understanding a legitimate security
concern based on the scenario you have outlined, I don't have any
difficulty imagining the very real possibility that wily hackers
will use the strategy of bypassing the system's security apparatus
in order to break in. In attempting to do this, they will almost
certainly try (sometimes with success) to subvert a channel that is
invitingly named a "bypass" channel, something that you have just
re-introduced using the signature approach.
To summarize: a) your concern doesn't reflect a real security concern
likely to be encountered in the context of IPSP b) it has additional
computational overhead by introducing two signatures in the protocol
(a significant overhead for underpowered devices as we have seen in
the numbers even for the marginally secure 512 bit RSA operations)
and c) to the extent it makes real attacks more likely to succeed it
diminishes security (while adding overhead).
Regards,
Ashar.
Follow-Ups: