Encryption Key Security

[Claus]

The encryption of UltraVNC SC works with a pre-shared session key, which is the key that is included in the executable file. Correct?

Now, if I just simply publish the UltraVNC SC executable on a website anybody can obtain the executable and with it has access to the key. Having the key means that one would be able to decode the communications and thus reducing the effectiveness of the encryption significantly.

With that in mind is it correct to classify the encryption as weak, or did I get something wrong?

[mod=494,1154129743]moved from SC to DSMplugin[/mod]

[scovel]

Encryption is only as strong as the key. You give the key away to the world, then the world has access to your system. Even if the key were somehow "hidden" in the exe, a hacker could use the exe to generate known plain-text over and over again to learn information about the key. Eventually (and not a very long time either!) he would break your key.

Keys and passwords need to be kept secret, changed often, and kept secure.

The newer versions of the plugins use IV and SALT to make each exchange more unique, but IV and SALT are not secret information. They also could be recovered from the data stream.

Sean

P.S. Once the key is broken, its even easier to break the 3DES encryption VNC uses to encrypt the password. The key for that encryption is well known. Once they have your key and your password, you're owned! But wait, SC can't use a password.... Better only give your SC to trusted clients, not to the general public.

[Claus]

Thanks for your reply. You pretty much confirmed what I thought was going on.

It would be nice to mention that the encryption uses a pre-shared key as opposed to a public/private key pair. That would help people such as myself that know a tiny bit about encryption. The uninitiated will still hear encryption and associate security with it. Maybe it wouldn't be bad to explain to them some of the security issues as well.

In any case, thanks for your explanation and the hard work you put into the encryption plug-in. I got SC with encryption working and it's sweet.

Claus

[scovel]

Claus,

The plugin was written for UltraVNC, and used with that, it works as designed and is very secure. The typical viewer/server installation does not require that the key be distributed to multiple people in a public setting. It also uses a pasword for additional security/authentication.

SC is a newcomer and has some different requirements than a typical viewer/server installation. SC, being what it is, CAN'T use a password. Typically it is used by many more people than a single viewer/server setup.

The plugins just happen to work with SC, since its based on UltraVNC. The percieved insecurity is based on the different requirements of the SC application. I suspect that the SC documentation should be updated as you suggest to point out some of the precautions that should be taken.

Sean

[redge]

What warning , comment would you exact text should be added to FAQ SingleClick with encryption ?

[Chromix]

SC, being what it is, CAN'T use a password. Typically it is used by many more people than a single viewer/server setup.

Wouldn't it be possible to add a Diffie-Hellman key exchange to the plugin?
The resulting key could be XORed into the existing RC4 key, or even be used on its own. When using some non-predictable numbers as initialization for Diffie-Hellman, i.e. the mouse position & the processors tick count, it should be pretty secure.

So it'll be more secure to use SC + key then, even if some more users would obtain the "secret" key, as they'd still need to solve the Diffie-Hellman problem to get the cleartext.
On the other hand, a man-in-the-middle attack would still be easy, as an attacker would "only" need to know the key thats distributed with the SC binary.

[scovel]

If it were possible, I would have done it!

The DSM architecture is such that the plugin is just a black box that gets passed some text. It encrypts or decrypts what it is passed. It is called before communication is passed from viewer to server, or server to viewer.

The process of establishing that communication is done by UltraVNC. The plugin has no access to the socket. The plugin would need at least 2 exchanges with the other side in order to establish the keys, BEFORE UltraVNC starts its own RFB protocol exchange. As it works currently, its not possible.

Sean

[mrfisher]

If it were possible, I would have done it!
Sean

How about using an encryption key derrived from a password that is communicated over the phone:

User(A),who runs SC server, is prompted for a password > 10 chars long. SC creates an encryption key based on that password. (Or SC server generates a password on they fly and presents it to the User A)

User A tells Viewer (B) what the password is. Viewer (B) enters the password when prompted. VNC Viewer creates the same encryption key based on the password entered and establishes the connection....

This is not very secure but more secure than using any encryption (RC4, AES) were the key is publicly available...

Michael

[scovel]

That would require a change to UltraVNC.

[mrfisher]

That would require a change to UltraVNC.

Is SC's DSMplugin still trying to read env variable for path to the key? We could have separate MD5 digest program run before SC that would create the key for SC to use. Same MD5 digest program would have to be run before viewer starts in listening mode as well.

Michael

[Rudi De Vos]

How about using an encryption key derrived from a password that is communicated over the phone

Does not work, generating a key from a small password is still a small
key. You need at least a sentence of 100 chars.
This is almost impossible to do by phone.

Run MD5 digest program on server and viewer

This generate 2 different keys..don't work

Why you don't use a offline creator (online is not save, as the zip pass the network unencrypted) and make exe with different keys.
Use exe once and erase.....

The question is, how far did you need to go...You can use a DH that takes 10 minutes to generate and exchange a 4048bit prime, use a 2024 bit encryption and have 1 fp/min as encryption use all cpu.

What's the risk when someone else has the key ?
+Can he take over the PC....NO, session is server initiated
+Can he see what you are doing. Yes, but it's not easy and can't be done in real time. He need to be able to record the in and outgoing data...need to have access to your network or hacked your isp.

Each key you use can be broken in X years...what the value of the information.
If you are realy paraniod....how secure is MS crypto API? We have never seen the code of it and possible have backdoors

[mrfisher]

Does not work, generating a key from a small password is still a small
key. You need at least a sentence of 100 chars.
This is almost impossible to do by phone.

If it's good enough to secure passwords it's good enough for me. AFAIK to bruteforce 8 random char MD5 can take years.

Run MD5 digest program on server and viewer


This generate 2 different keys..don't work

From the same password? 8-10 char password communicated over the phone...

Why you don't use a offline creator (online is not save, as the zip pass the network unencrypted) and make exe with different keys.
Use exe once and erase.....

That would work. I think a better way would be to create a webpage which authenticates the user so I limit access to the binary and the key. Than have a user associated with a binary key (sc distribution) based on security level (so the users cannot read their bosses VNC stream).

The question is, how far did you need to go...You can use a DH that takes 10 minutes to generate and exchange a 4048bit prime, use a 2024 bit encryption and have 1 fp/min as encryption use all cpu.

The system is as weak as it's weakest link. Since VNC is like a virtual desktop I don't want to compromise anything that is being worked on remotely that is configured to be and is considered secure. So VNC has to be harder to break than any other application running on that desktop.

What's the risk when someone else has the key ?
+Can he take over the PC....NO, session is server initiated
+Can he see what you are doing. Yes, but it's not easy and can't be done in real time. He need to be able to record the in and outgoing data...need to have access to your network or hacked your isp.

Each key you use can be broken in X years...what the value of the information.
If you are realy paraniod....how secure is MS crypto API? We have never seen the code of it and possible have backdoors

See above.

[redge]

I think a better way would be to create a webpage which authenticates the user so I limit access to the binary and the key. Than have a user associated with a binary key (sc distribution) based on security level (so the users cannot read their bosses VNC stream).

PCHelpWare should do the steps you requested from 2 partners but not available for VNC (as my knowledge)

authentication and connection work like instant messenger
[topic=7542][/topic]

[Rudi De Vos]

Yep, the successor of SC (pchelpware) will have DH (512bit) and 254bit
buildin encryption. (takes about 4sec)

As this version is a rewrite, i was able to play with the protocol and preview encryption and other stuff. Adding it to SC would break any
compatiblity.

[Rudi De Vos]

If it's good enough to secure passwords it's good enough for me. AFAIK to bruteforce 8 random char MD5 can take years.

Only a week....
I did some tests with the unix passwd file (that contain the password hashes), on a Sun 32xCPU using a password hacker.

From the 20 passwords in the file 18 where hacked within a week.
The first even popup after an hour...(passwords only containing chars)
Running >1.000.000 md5 checks per hours

[badmofo]

So how is the AES or ARC4 encryption even useful or "secure" using the password to generate the session key? I agree that a DH key exchange would be very useful... from what I can glean from this discussion and others, anyone sniffing at the beginning of the session can get the session key without too much difficulty.

My intention was to use static passwords on a variety of servers counting on the uniqueness of the session keys. Frankly, I didn't care if someone cracked the 3DES of the stored password because I figured it was just being used as a seed. Without public/private keys, the method is flawed... in this case, we are using encryption as a deterrence not a security mechanism. I did a little sniffing and at least confirmed that nothing is being sent plaintext... but I presume the viewer sends the password as 3DES with itself as the key. Presumably, the server responds with the session key encrypted with the password... if this is the case, anyone breaking the 3DES has full access to all communication.

Looks like I'll have to use private key files and change them frequently. This might annoy me enough to modify UltraVNC to actually support true SSL sessions.

[scovel]

The session key is never exchanged over the wire with the plugins. The session keys are derived from the password, a random IV, and a random SALT. The SALT and IV are not "secret" information and are exchanged over the wire. These parts are used to derive a session key on both ends. The keys are then used to begin encrypting the data over the wire. If one of the sides cannot decrypt the data, then the session keys don't match, and something is seriously wrong. At that point the connection is closed. The password and the session key never go over the wire.

Part of the RFB protocol communication is to send the key over the wire 3DES encrypted. This occurs AFTER the plugin has already established the encrypted channel. Thus, the weak 3DES password exchange is encrypted within the AES or RC4 stream, and is completely unidentifiable.

Sean

[scovel]

I've completely lost track of the problem we're trying to solve. The plugins use a very secure method of encryption.

The only recent vulnerability that came up was that with a pre-shared key, and the fixed RFB protocol exchange, the encrypted data for the first 12 (I think?) characters was always the same. That was bad on two fronts: 1. it leaks key information (not much, but it does) and 2. its easy to detect the VNC exchange since the characters were always the same.

This problem was solved with a random IV (initialization vector). The IV changes for each session. That changes the key for each session. That makes the session nearly impossible to detect, and doesn't leak key information.

If the problem you are trying to solve is stopping someone from accessing your server after you post your key and password on the Internet, well, there is nothing the plugin can do about that. DH key exchange isn't going to solve that either.

Sean

[badmofo]

Right, but what WOULD solve it is a private key. It has been said that the salt and IV are not "secret"... well, with UltraVNC encrypting its password in the registry with 3DES, that isn't secret either. This may be enough to thwart a third party with no access to the machines just sniffing, but what if I want to use the same password on a 100 servers and I don't necessarily trust people who have access to those machines... I have to assume that the password at that point is public knowledge, albeit disguised. What is needed is a true asymmetric public/private key implementation where a single trusted individual (ie, me) has the private key. It's the only way to avoid a different password on every machine while maintaining both paranoia and ease of use.