[Cryptography] Secure VNC implementation

[Jerry Leichter]

> ...VNC is a pretty simple design that
> sends a stream of keyboard and mouse events from the client to the
> host, and a stream of frame buffer updates from the host to the
> client.  It's described in RFC 6143.
> 
> It has no meaningful security built in, but it can run over anything
> that looks like a virtual circuit.  People usually run it over ssh, so
> whatever you think of ssh's security, that is VNC's security.
It's interesting to consider this statement in the light of our recent discussion of leakage via things like message lengths and timings.  VNC doesn't send entire frame buffers each time; it sends frame buffer updates.  Can the size of a sequence of these updates be used - as in published attacks against HTTPS - if a particular set of images is being transmitted?  There are multiple encodings of updates - including a very small update to copy a client-side value from one place to another.  This suggests attacks similar to those based on LZ-style compression, where the attacker can effectively query whether a particular sub-image appears somewhere on the screen.

This is not a criticism of VNC or SSH!  It's just an indication that once you start thinking about the possible attacks enabled by the metadata leakage of current cryptographic algorithms and protocols, you start seeing the possibilities in unexpected places.

I'm not aware of any published work attacking VNC this way.  Since VNC isn't particularly common - and certainly not over the greater Internet - relative to the biggies like HTTPS and encrypted voice, the payoff from such an attack wouldn't be great (though one could imagine targeted situations in which it could be).  Still, if someone (probably some small group, this feels like a bigger project than one person would want to take on) is interested in a nice paper....

                                                        -- Jerry