multiple keys?

[jjgalvez]

I've searched the forum and found only a single reference to this so I'll ask again. Is here an easy way to use multiple keys for a viewer? I'm currently using the tabbed viewer which is really cool with its favorites and everything, but I noticed that it wants to use the same key file for all connections? Basically I want to use one key on my work computes and a different on on my home computers

Thanks for any and all help

[markvp]

I am wanting to setup using muliple keys as well. Same reason one for work, and one for home.

Some might want to use a different key for each machine. . . for the security freaks.

[redge]

There a solution for your request available at vnc-related products but is not free.

[scovel]

One solution is to not use any keys. You don't NEED to use a key anymore.

If you still want to use keys, I'm not sure how you could do it with the tabbed viewer.

With the standard viewer you could put a copy of the viewer EXE in seperate directories with a copy of the plugin and a key file. The plugin will find they key in the "current" directory and use that one.

Sean

[markvp]

One solution is to not use any keys. You don't NEED to use a key anymore.

What do you mean you don't need keys anymore. Does it still use the 128-bit security?

With the standard viewer you could put a copy of the viewer EXE in seperate directories with a copy of the plugin and a key file. The plugin will find they key in the "current" directory and use that one.

I thought about using this technique, but was going to wait and see if anyone had any better ideas?

Thanks,
Mark P.

[scovel]

If you don't have a key file the following happens:

The plugins generate a 128 Bit random IV (Initial Vector) and exchange them. The password is hashed using 128 MD5 hash. A random 128 Bit SALT is generated and added to the key.

The 128 Bit hashed/SALTed password and the IV are used to start the encryption stream. This is effectivly a 128 bit session key that changes with each connection. No real need for a key file anymore. The only way this process could be improved is if UltraVNC supported more than 8 characters for the password.

If you DO have a key, the 128 Bit key is used instead of the password, but all of the above still happen.

That is the BIG improvement of 1.2.0 over 1.1.8.

Sean

[scovel]

There IS another way...

You could create multiple batch files to start the viewer. Each batch file would set the environment variable:

Code: Select all

set msrc4pluginkey=c:\program files\ultravnc\myrc4.key

And then start the viewer. When the viewer starts up it checks the environment variable, and if it is set it attempt to load the key specified.

Sean

[Phred]

I am also trying to manage multiple keys, running a server, and running some clients on the same machine. The server 'assumes' the current rc4.key file is the correct one, and you used to be able to specify the key program manually in version 1.01. It also locks the file, and the viewers try to use the same key.

I have the latest version of both UltraVNC (1.02) and the RC4 plugin (MSRC4Plugin v1.2.2), and when I leave both machines without any keys and have the plugin enabled, it refuses to connect. I even re-configed the server to make sure it saw that it had no key.

1. How do I make things run keylessly? Is it the same level of security as a private 128 bit key, besides the obscurity of not everyone having the key?

2. Is there any way to specify which key to use for the server only manually besides the universal (for server and client) environment variable? Is there a command line option or .vnc file entry for it?

3. Is there a decent reference for the options in the command line and for the .vnc files? I haven't found one yet.

Thanks in advance for any help.

[Setsunaaa]

One solution is to not use any keys. You don't NEED to use a key anymore.

This is nonsense, the connection itself is secure once initiated, but the password is the only barrier then. The pre shared key makes it sure no other can connect to the machine since the key is missing.

It is a step for more insecurity.

Best would be both, pre shared key so only the intended machines can connect + salted pw so only the people who are allowed to connect can do so.

If you still want to use keys, I'm not sure how you could do it with the tabbed viewer. With the standard viewer you could put a copy of the viewer EXE in seperate directories with a copy of the plugin and a key file.
Sean

I simply renamed the .exe viewer files so I have both of them in the same dir and switch whenever my mood says so.

Set

[Setsunaaa]

There IS another way...

You could create multiple batch files to start the viewer.

Sean

That is what I did a few days long, and then I switched back to RC4 plugin V 1.18 + Ultravnc 1.02 which lets you select the key right from the viewer GUI, just type in the right xxxxxx.rc4 filename. A drop-down box which lists the keyfiles in the directory where the last keyfile was would be a dream to have BTW.

Set

[scovel]

I think you mustundertand keyed vs. keyless connections. Either way no one can connect to your machine, unless of course, they already have your password...

Here is how that works keyless:

On both sides, the password is retrieved. On the server, from the registry. On the client, from the password prompt. The passwords are transformed into 128Bit keys (MD5 hash, random SALT, random IV, shaken, not stirred...), and the communication channel is encrypted in both directions using these keys. IF the passwords match, then the encryptions keys match, and everything goes as planned, and VNC does its thing over the encrypted channel. If the client got the password wrong, you get a PROTOCOL ERROR. The server cannot decrypt the communication from the client, so the protocol negotiation fails. It never gets as far as the password exchange.

Less secure. Well, technically, I guess so. With a key you have two factors, the key and the password. OWNED? I think not, not unless you chose a bad password...

Sean

BTW, since the whole RFB protocol is wrapped by the encryption it makes it nearly impossible for "scanners" to detect that its VNC answering on any given port. Much less chance that a script kiddie is going to select you for a brute force password cracking session, or a VNC-3DES password crack.

[Setsunaaa]

I think you mustundertand keyed vs. keyless connections. Either way no one can connect to your machine, unless of course, they already have your password...

Exactely this is my problem. It is not the "my password is weak" problem alone, it is that other people than me HAVE to know the password used there (by law and documentation enforcment).

Here is how that works keyless:

I understood how the keyless version works, but your explanation is nicely worded.

BTW, since the whole RFB protocol is wrapped by the encryption it makes it nearly impossible for "scanners" to detect that its VNC answering on any given port.

I can confirm that, I used netcat/ethereal (by that time somewhat 0.8x) to see what is going on the wire, and it is pure "junk" data from the first bit on, something I like a lot.

Well, maybe with 1.23 RC4 plugin or next AES 128/256 Plugin version we get the "reg" version back with usable GUI, using salted PW as fallback if keyfile not found or according chekckbox selected.

Set

[scovel]

please respond in this topic:

[topic=8202][/topic]

Sean

[cfuller]

One solution is to not use any keys. You don't NEED to use a key anymore.

There are two reasons to use multiple keys. The first is a second level of authentication. Authentication and encryption are two completely seperate tasks. Helps to defeat keyloggers, for one thing.

The second reason is to have more direct control. UVNC uses the microsoft crypto libraries, which aren't transparent/inspectable/auditable. I could foresee a desire, perhaps even a requirement in some circumstances, to use some verifiably hard random bits from some physical source for encryption.

I use VNC on about ten computers at four sites. An extra level of authentication makes a lot of sense vs some error prone human typing in just a password.

By all means, dump the registry, but include some mechanism to select some other keys, even if the choice is lost for each session.

[CAOgdin]

I, for one, am eager to see this. Ideally, I'd like it to be an entry in the *.vnc file.

My assumption is a given server should have a single, particular rc4.key (with a more liberal name not restricted soley to exactly rc4.key), and a Viewer might have several to select from. (That's my need; YMMV.)

We've got an entry for which protocol ("DSMPlugin=MSRC4Plugin-122.dsm").

How about a new key:
DSMKey=myrc4.key

Step 1: Implement the new option in the *.vnc file, so it is recognized.
Step 2: Implement the Viewer code to recognize that option, and substitute the named file for the default rc4.key
Step 3: Create a GUI for specifying which key name to use in the Viewer

Step 4: Implement the same option in the ultravnc.ini, so the Server doesn't have to use exactly rc4.key name. (This is to simplify key management, so the name can include relevant usage information.)
Step 5: Duplicate GUI in Server configuration so I can specify which key name to use.

Rationale

I have many clients. I don't want to have just one rc4.key used at all sites, because that compromises their security. I'd like to have separate rc4.key files like

• Joe.key
  Frank.key
  Alice.key

Then, the key would exist only on my computer(s), and at the client(s) computer(s). The key would not be shared among clients, thus closing another avenue of attack from an unscrupulous employee at Client #1 trying to guess the password at Client #2. They'd need both the key file and the password for the other Client.