>> Scott mentions the difficulties of revoking a compromised key. In the
>> context of VNC, how difficult does this have to be? Initial host-key
>> exchange is done using a "key password" which can be changed by the
>> user by physically sitting at the server (or by controlling it).
>
> What I meant to say was...a bit more wordy. :) It goes
>something like this: suppose that, upon installation, the VNC server
>auto-generates a pub-priv key pair. For every client you want to
>connect to your server, you give them the generated public key (this
>is very similar to SSH using its authorized_keys scheme for
>authentication). You can now use this key-pair to increase the
>security of VNC authentication by having the VNC server encrypt
>its transmissions to the client using the private-key (presuming
>some long-term storage ability of every client).
> Fairly straightforward, and the pub-priv key pair can be
>a sufficient 'pre-shared secret' to foil MITM attacks. The problem
>is...suppose you install the decryption key into 100 clients for 5
>different servers. And you learn after a month that the fourth
>private key has been stolen, and you have to revoke it. It's easy
>enough for machines you have physical control over, but for remote
>clients that you only know via email....how can they verify it's
>you emailing them? :) Really, digital-identity competition is
>terribly messy.
OK, that's for a general case, but VNC is largely designed for individuals'
use. So, if I decide to change the password(s) on my personal computers, I
need tell nobody but myself. For a tech support department running
Windows, they send the update using those funny boot/login scripts and tell
the rest of the support team. For a UNIX mainframe it's slightly more
complex if the users themselves use VNC to log in, but it's often easily
solved using a tightly-controlled e-mail system that is accessible while
not using VNC. If, as I believe is the case at AT&T, all the users are
normally on-site and use personal-type computers at the desk and VNC to log
into the mainframe, e-mail can be sent across the internal network to the
personal workstations without being a security risk. (Unless the cracker
has got inside the network itself, in which case you have bigger problems
anyway...)
>> In summary: the client is authenticated to the server by correct
>> decryption and use of the session key (implying knowledge of the
>> shared secret - the key password) and by regular VNC
>> authentication. The server is authenticated to the client by a valid
>> host key being sent using the shared secret.
>
> If I follow...you're suggesting that an extra password
>authentication step be added before 'regular VNC authentication'.
>That is, use some pre-shared secret to encrypt the random sequence
>that starts the authentication process. I can't see this working if
>the client cannot verify (by at least a digital signature) the
>integrity of a server first, which requires the client have some
>form of long-term storage. If not, a valid authentication exchange
>from one session can simply be 'sniffed' and used again in an invalid
>reply attack.
Actually, you're right there. If the encrypted key from the server was
sniffed (or retrieved by connecting to the server), it could be replayed to
a client which (if it knew the key password) would then think the cracker
was the real server. However, decrypting the subsequent exchange would
still be impossible without actually compromising the key itself. Is this
good enough? Only if it takes a "significant" amount of time to crack the
key and thus discover the key password. After that, the cracker could
listen in on future conversations and discover the VNC password as well.
How long is long enough? Never.
OK, so we're back to the question of server authentication at the client
end. A user-entered password is not good enough, because any password
short enough for a user to remember can be cracked in a relatively short
amount of time by any recent personal computer, given that the algorithm is
known (and it is, because we're open source). If the user cannot remember
the server authentication token, then when he goes to a new machine (or one
which has no fixed storage), he must write it down, put it on a floppy or
have it transferred over the wire.
Let's consider the ideal case first: a single user using a single
workstation or a small set of workstations, all of which have *secure*
permanent storage. This case is very rare in practice. In this case, it
is sensible to have the client store the server key locally, and to have it
big enough to take an infeasible amount of time to crack when encountered
on the wire.
Now let's consider the worst-case scenario: one or many users accessing the
system mostly from public-access terminals or from stateless clients such
as Java. At a public-access terminal, any local storage is extremely
insecure and the client should *not* store the server key anywhere. For a
Java applet, the client is incapable of storage. For this case, the server
authentication token has to be small enough for the user to type in at the
terminal and changed regularly (for maximum security, this should be more
frequently than some Mean Time To Crack).
For the most common case, we have a number of servers, each of which is
accessed by a single user, mostly from a limited number of relatively
secure workstations but also occasionally from a public-access terminal or
from a mildly-untrusted personal computer. I fit neatly into this
category, as do most users of VNC. Clearly, the secure workstations can be
handled as in the ideal case, where the key is stored neatly away and need
be transferred only once per station. However, for the unsecured
terminals, a means of transferring the key without compromising it is still
needed. Writing it down or putting it on a floppy is not a good idea,
because both paper and disks can be mislaid and/or stolen. Allowing the
server to send out the key to anyone, however obfuscated, may be asking for
trouble, as Scott rightly points out. In other words, the server needs to
authenticate the client before sending the key, the client needs to verify
the server before accepting the key sent, and then everything proceeds as
for the secured workstation WITH THE EXCEPTION that the server key is never
stored by the unsecured client.
So, now we have a different use for a "key password". Instead of being
used solely to encrypt the key before transmission over the wire, it is
also used as authentication to allow said key to traverse the wire.
Verification should be performed by the user by visually comparing the
fingerprint of the key obtained and that of the real key - this fingerprint
should be short enough to be easily recognisable by the average person. As
for the format of the authentication? How about standard
challenge/response, in the same style as has been used up to present? This
ups the security to the point where a MITM attack as described in the
advisory would be necessary to retrieve the host key, and then cracking
would have to be done afterwards to actually locate the host key to
continue the connection with. A subsequent connection would then have to
be sniffed (and decrypted) to retrieve the following authentication steps
and the VNC password. The initial MITM attack would have to be carried out
when the user was about to use an untrusted terminal, the location
(topologically and geographically) of which can be unpredictable. The
subsequent second-phase sniffing attack could be carried out on any
connection.
I believe the above is a significant improvement over the current situation
and over my previous suggestion(s). Any (dis)agreements?
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: [EMAIL PROTECTED] (not for attachments)
big-mail: [EMAIL PROTECTED]
uni-mail: [EMAIL PROTECTED]
The key to knowledge is not to rely on people to teach you it.
Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/
-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+
-----END GEEK CODE BLOCK-----
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
