[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Security Problems in Photuris #3
Summary of this message: The issue of this note is how to fix
the signature message of Photuris.03 in order to avoid the security
holes discussed in my previous notes (mainly, the signing of the
shared-secret) as well as the lack of clear specifications for
the Certificate field as discussed below. I start by a lengthy
discussion of the subtle cryptographic issues behind the protocol, and
then present a solution based on this discussion. The length of the
present note does not represent the complexity of the solution but
the complexity of its rationale. The Photuris changes required
by this solution are minimal (both in terms of specifications
and implementation). The solution can be read in sections
"The signature message using Digital Signatures" and
"The pre-shared key signature option", below.
How to sign in the Signature_Message
************************************
To really understand this solution and the real problems it comes to solve
(which are more involved than the sole issue of signing or not the
shared-secret), one needs a good understanding of the cryptographic
subtleties surrounding this protocol. I will make an attempt
to explain some of the issues here, though a complete treatment
of this would require an even more detailed discussion.
Notice that the way I presented the Photuris signature bug is by
explaining that information on the shared-secret can be leaked
by a signature. One could wonder why, in the first place, is
the shared-secret signed. A (partial) answer is that:
* the signature message in Photuris has dual cryptographic functionality *
It serves to
(1) authenticate the DH exponents
(2) to prove possession of the shared-secret (ie. DH key) by the parties,
and to bind this shared-secret to the identity of the parties.
The first item is mandatory to prevent traditional man-in-the-middle attacks aga
The second is far more subtle and its need was pointed out in the
(excellent) paper on the STS protocol (that paper is referenced as [DOW92] in
Photuris, and is a must to read to understand the issues discussed here).
It turns out that without (2) the protocol would be insecure.
I elaborate on this after the following note.
[Note on STS vs Photuris: STS and Photuris are different protocols as a
whole. However, they have a lot in common and many of the cryptographic
aspects of STS are applicable to Photuris. This allows us to apply
(where relevant) the lessons learned from the STS protocol to Photuris.
I note that the issues discussed in this message apply to Photuris.03,
and may or may not apply to STS.]
To see the need to involve the shared-secret into the authentication of
the protocol, let's take Photuris.03 as defined but remove the
shared-secret from the signed information. We assume for simplicity that
no anonymity-encryption is in place (such encryption is optional in
Photuris). An attacker, Eve, can now act between A and B (which
represent Initiator and Responder, respectively) as follows.
Eve leaves all the Photuris messages
flowing between A and B unchanged except that she replaces two fields in
A's signature message: she replaces A's certificate by her own, and
changes the signature field to Eve's signature. Since all
information being signed is public Eve can easily do that.
The result of such an attack is that Eve does not know the shared
secret, however while A believes to have exchanged the key with
B, B believes to have exchanged it with Eve. The actual effects
of such an attack depend on the particular scenario where the
protocol is run; see [DOW92] for an example of possible consequences.
The abstract problem behind this attack is the lack of cryptographic
binding between the identities of the parties and the shared-secret.
There are several possible fixes to this problem. The idea is that
any party, say Eve, that does not know the shared-secret (i.e. the DH
key) should not be able to trick B to believe that he (B) was communicating
with Eve.
The STS protocol uses encryption of the signature message under the DH key
to avoid this problem. I have observed that encryption, in general,
is not a good enough protection here.
[In particular, if a stream cipher mode of encryption is
being used I can present two weaknesses of this solution (this applies even
for ideal one-time pad encryption), other modes of encryption may suffer
of similar weaknesses as well. I will not elaborate on this here.]
For Photuris this means that even if encryption of the signature_message
is used for anonymity, this encryption does not solve the above problem.
Photuris.03 uses the signing of the shared-secret to solve the above
impersonation problem. This is a tricky solution.
Reason 1: As pointed out before, if the signature does not provide secrecy of
the signed information then the shared-secret (or information about it) can be
disclosed.
Reason 2: Even if a signature with secrecy protection is used but the
identity of the signer is *not* included in the signature, the protocol
becomes insecure.
To see the latter, consider the example of a signature performed with RSA
and MD5 hashing.
In this case, Eve doesn't need to find the shared-secret in order to
replace A's signature with her own. She just uses
A's public key to recover the hashed information, and then sign it herself
(no need to know the shared-secret)!
By including the identity of the signer in the signed information this
problem is solved. (The need to sign the identity of the signer may seem
counter-intuitive -- why wouldn't be the use of a private key enough? --
but essential for security here.)
Therefore, we have learned that we need to
(1) sign the DH exponents
(2) prove that the parties know the shared secret (DH key)
(3) bind the identity of the signer to the shared-secret.
Notice that Photuris.03 provides this binding through the inclusion of the
Certificate field in the signature. What the current draft fails to make
clear is the mandatory need to *always* include the identity of the
signer in the certificate field (current language in Photuris.03,
implies that an implementation could not include a certificate at all,
and then, in particular, no identity into the signature). This issue is
further clarified below.
Given all this background on these subtle protocol issues, and Photuris
deficiencies in addressing them, here is my proposed solution.
For concreteness, I first present the solution assuming the use of a public
key-based digital signature, later I will show the solution for
the case of parties that have a previously-shared key (e.g., a manually
installed master key, a Kerberos key, etc), and use this key to authenticate
the DH exchange. As we'll see, the solution to the second is a "particular
case" of the former.
The signature message using Digital Signatures:
**********************************************
Most of the signature-message is unchanged from the specification in
Photuris.03. The changes are in the signature-choice, the signature
computation, and the certificate specification.
The Signature-Choice variable will specify the following attributes
(1) Digital signature algorithm (e.g., RSA, DSS), and a corresponding
certificate method (e.g., X.509, DNS, PGP, private formats, etc).
(2) a keyed MAC algorithm (e.g. keyed-MD5 a la RFC-1829, envelope SHA,
DES-CBC-MAC, etc.).
[(1) is identical to what Photuris.03 specifies; (2) is an additional
specification here]
The Certificate MUST include at a minimum the identity of the signer, and
may include additional information binding the public key of that signer
with the identity (as in traditional certificates).
[This is different than what's specified by Photuris.03 in the sense that
we add the "MUST requirement" that the Certificate field includes at a
minimum the identity. This mandatory inclusion is not clear in Photuris.03
which states
> Certificate variable precision number. When the Signature-
> Choice indicates a certification method, such as
> X.509, PGP or DNS-SIG, the certificate is included.
>
> The content is outside the scope of this
> specification. Although the field is depicted as
> 32-bit aligned for convenience, the size may be
> shorter or longer, as indicated by its integral Size
> field.
For example, an implementation that does not use regular certificates, but
just uses the sender's IP address to retrieve the public key of the sender
(from a local data base, a directory, etc), may interpret the above
specification as saying that in such a case the certificate field may not
be included at all. This would be insecure; instead, the IP address on
which the public key search is based must be included in that field.]
The signature field is computed by
(1) key the MAC function using the computed shared-secret (the MAC
function is as specified by the Signature-Choice variable);
apply this keyed MAC to the information as stated in Photuris.03
with the exception of the shared-secret, namely, MAC the information:
+ the Offered-Schemes,
+ the SPI Owner (receiver) Exchange-Value,
+ the SPI User (sender) Exchange-Value,
+ the SPI Owner (receiver) Offered-Attributes,
+ the SPI User (sender) Offered-Attributes,
+ the Type, LifeTime and SPI,
+ the Certificate
+ the contents of the remainder of the message following the
Certificate.
[Notice that I erased the phrase "(which may be specially handled)"
appearing in Photuris.03 after "the Certificate" in the
above list. I do not understand what does it mean. By the
requirement that the certificate field must contain the identity of the
sender we guarantee that the MAC computation includes this identity]
Note: I would like to eventually change the structure of the
above list (e.g., put the Offer-Attributes at the end,
have all the message signed instead of parts of it, etc.),
but this is a secondary issue and would distract us from the
more essential issues.
(2) Apply the Digital Signature, as specified by the Signature-choice variable,
using the sender's private-key and computed on the result
of the MAC computation described in (1).
The pre-shared key signature option
***********************************
An important scenario to support is that of communicating parties that
share a key before the execution of the Photuris key-exchange.
We call this key a pre-shared key.
This pre-shared key could have been shared via a previous execution of
Photuris, or it can be a manually installed key -- e.g., between a user's
laptop and the user's workstation --, or via Kerberos distribution,
and so on. In such a case the parties may use the pre-shared
key to authenticate the DH exchange, thus avoiding the need and
cost of the digital signature.
The above solution to the Signature_Message will work in this case
by performing the MAC computation as explained above but with the key
to the MAC being the pre-shared key (instead of the shared-secret).
The digital signature computation is omitted.
Notice that in this case the sender needs to specify the pre-shared key in
use. This can be done by including a "pointer" to this key (e.g., an SPI, a
key-identifier, etc.) in the certificate.
Issues:
******
* how long should signature-choice be to include the specification of
the MAC function (are 16 bits still enough?)
* need to provide attribute codes (or types) to be used as
signature-choice when a pre-shared key is used for authentication
(namely, these codes would specify a MAC function, and the omission
of a digital signature). Implementations need to be careful in this case
to use the specified pre-shared key for keying the MAC, and not
using the shared-secret for that purpose.
* Another subtle issue for future treatment: since MAC functions
are not guaranteed by definition not to leak (partial) information
on their keys, one should not use the shared-secret directly to
key the MAC but a key derived from the shared-secret; alternatively,
one can use the Key-Generator function as a MAC. Since all the
issue of deriving keys from the shared-secret is not well resolved
in Photuris.03, I'll leave this issue for future discussion.
* Non-repudiation (if you are not a real crypto fun, skip this):
the solution of signing a MAC value contradicts the traditional
property of non-repudiation provided by digital signatures.
If such non-repudiation would be a requirement for Photuris,
my solution wouldn't be acceptable. [The point is that for some
MAC functions (e.g., DES-MAC) the party knowing the MAC key can
find different messages mapping to the same MAC value and then
could argue that its peer signed a different stream of information
than it really did.] I find this perfectly acceptable for Photuris:
Not only should non-repudiation be a non-goal of Photuris; ideally,
complete repudiability of communication should have been a property
of key-exchange for IP. I explained this privacy-related issues
in the past (related to my "Photuris variant").
If non-repudiation had to be provided then some slight modifications
of the above solution could achieve that (e.g., hash with a collision
resistant function before MAC-ing, or use a collision-resistant MAC;
MAC-ing a signature instead of signing the MAC is another possibility,
however it requires an extra field and accomodates less naturally the
pre-shared key case).
Hugo