A crypto library aimed at auditability

Posted Jan 13, 2014 20:02 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
In reply to: A crypto library aimed at auditability by dlang
Parent article: A crypto library aimed at auditability

> The way client certs work is that the client and server certs are validated at the same time by the PKI handshake.

Yet there's no NEED for this. Client only needs to authenticate the server (by its public key) and it's done both parties can assume that the communication channel is secure, in the sense that there can't be any MITMs.

However, the server side might want to make sure that the client is really whom it claims to be. That can be done in higher levels - in HTTP form-based authorization, for example. It should also be possible to do this by the exchange of signed nonces, except that there is no standard for this :(

to post comments

A crypto library aimed at auditability

Posted Jan 13, 2014 20:10 UTC (Mon) by luto (subscriber, #39314) [Link] (3 responses)

I don't think your protocol works. I think you're saying:

Client connects to server and verifies server cert. All remaining communication goes over the resulting channel.

Server -> Client: server_nonce
Client -> Server: Sign(server_nonce)

This isn't secure without a lot of care -- an attacker could get the client to connect (knowingly) to the attacker, and then the attacker could ask the client to sign the real server's nonce. Game over.

This is why I think that a good protocol would provide nonces that are bound to the session key.

A crypto library aimed at auditability

Posted Jan 13, 2014 20:21 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> I don't think your protocol works.
Well, it does.

> This isn't secure without a lot of care -- an attacker could get the client to connect (knowingly) to the attacker
Client MUST verify the server's public key (either by getting it in some secure fashion or by checking its certificate chain).

>and then the attacker could ask the client to sign the real server's nonce. Game over.
Sure, it's possible.

It can be easily fixed by signing server's public key hash along with the nonce. That is a layering violation, and it shouldn't be necessary if the underlying layers work as they are designed to.

A crypto library aimed at auditability

Posted Jan 13, 2014 20:33 UTC (Mon) by luto (subscriber, #39314) [Link] (1 responses)

It can be easily fixed by signing server's public key hash along with the nonce. That is a layering violation, and it shouldn't be necessary if the underlying layers work as they are designed to.

No, or at least not without great care. If the underlying layer guarantees that the client is talking to who it thinks it is, and the client signs a message saying "I'm XYZ", and the server receives a (validly signed) message saying "I'm XYZ", it does not follow that the client intended that message for the same server that's receiving it.

Remember, the attacker's server can violate the protocol and send a nonce that came from somewhere else, unless the underlying protocol provides some specific mechanism to prevent this, such as session-specific key material

A crypto library aimed at auditability

Posted Jan 13, 2014 20:43 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

>Remember, the attacker's server can violate the protocol and send a nonce that came from somewhere else, unless the underlying protocol provides some specific mechanism to prevent this, such as session-specific key material

Uhm, the server name is definitely going to be a part of the nonce. I haven't mentioned it, thinking that it's self-obvious.

Of course, the server authentication and name resolution becomes a critical part of the chain then. But I think it's a fair trade-off for avoiding layering violations.

And signing the server's public key used for session initialization also allows to avoid this attack as in TLS/SSL, at the cost of layering violation.