hamachi p2p vpn nat-friendly protocol details

Alex Pankratov ap at hamachi.cc
Fri Feb 24 16:08:22 EST 2006


I replied to Tero privately, then realized that I was
not the only recipient of his email. So here's a copy
for everyone's reference.

Alex

Tero Kivinen wrote:

>> Travis H. writes:
>>
>
>>>>http://www.hamachi.cc/security
>>>>
>>>>Based on a cursory look over this, I'm impressed by both the level of
>>>>detail and the level of security apparently afforded.  Too bad I can't
>>>>see the source code.
>
>>
>>
>> I can see couple of problems in the system. Firstly it seems it uses
>> same key for both directions for the encryption and for
>> authentication, i.e. the KEYMAT is only split to Ke and Ka keys, which
>> are used for encryption and authentication. In general using same keys
>> for different directions is bad.


The description on a page was not updated properly. Recent clients
use per-direction keys after they complete P2P KE.


>> Secondly I cannot find where it
>> authenticates the crypto suite used at all (it is not included in the
>> signature of the AUTH message).


Crypto suite is essentially just a protocol number. It requires
no authentication. If the server side responds with HELO.OK, it
means that it can comprehend specified protocol revision. Similar
to what happens during the SSH handshake.


>> Also it seems that the identity itself
>> is not authenticated at all, as it (or it's MACed form) is not
>> included in the signature.


It is not.


>> There might be (I am not sure whether AUTH
>> packet is encrypted and MACed) a MAC over it, but the MAC key is not
>> yet authenticated as it is generated from the anonymous
>> Diffie-Hellman. That might give it some protection, but I am not sure
>> if that is enough.


A protection against what kind of attack ?

Identity is used to specify which public key the client wants
to be authenticated with on the server side. Assuming it is
swapped in transition by a man in the middle, it would still
require an attacker to re-sign authentication hash in the
message.

Assuming he has a private key to do that, he will effectively
succeed in authenticating under substituted ID. He then will
need to re-sign server's auth hash to complete the attack,
which is not going to happen.

There is an off chance that the attacker might swapped the
identity to one that has the same public key. The chances
of this happening are infinitely small unless an attacker
also has an access to victim's keypair, which becomes a
trivial attack case.


>> The protocol description is missing some details, so cannot say
>> anything about them (things like what is the format of Ni, Nr, Gi, Gr
>> when sent over wire and when put to the signatures etc, are the Gi, Gr
>> always the lenght of modulus (2048 bits) etc).


What would you like to know exactly ? The page was not meant to
be a bit-level description of messages, merely a description of
the security framework.


>> The protocol is also tied to use SHA1.


If you are referring to HMAC-SHA1 for authentication hashes, it
is a part of a crypto suite (protocol revision) spec.


>> In general it would be much better to use standard protocol, instead
>> of generating your own.


This is the second revision of Hamachi system. First revision
was using SSL for cli-srv and IKE/ESP for p2p security. It was
a prototype and it soon become obvious that both SSL and IKE
were overkills for our purposes. We did not need certificate
authentication of SSL, we did not want to run our own auth
protocol over SSL/AnonDH, which would've increased the number
of packets per login sequence. We didn't need the flexibility
(ie complexity) of IKE either.

After stripping down IKE (ie removing SA negotiation, reworking
ID payloads and not doing quick mode), we essentially ended up
with a protocol that was also fit for securing cli-srv session.
It was further tweaked and replaced SSL.

I should probably add that I implemented IKE (v1) keying daemon
from scratch with all bells and wistles (NATT, extended MODP
groups, etc) at some point in the past. Some remnants of it
are still floating around, the library name was libike.


>> Designing security protocols is hard...


Yes, it is. This is why I like it.



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list