[ad_1]
A few years ago the servers of my favorite online game went down for a few days and I was already afraid that my character in the game was lost and dead with all his achievements. Luckily they fixed their issues and a few days later everything was back online. I wanted to be prepared for the next such incident, so I logged into their website and took a screenshot of all my character properties.
For a moment I was happy. Next time, even if all data was lost, I could prove what I had won and get all my stuff back. Then I looked at my screenshot and realized that I could just as easily tweak it to get even better in-game items. So basically it was useless. Digitally signing it alone wouldn’t improve on that.
This scenario is not limited to online play. Being able to prove that an order was given, that an infraction was committed, or that any assignment was performed seems worth investing some general considerations.
Of course, you cannot create and sign such a screenshot yourself. One needs the help of a reliable third party, but often the matter is too trivial to engage or even pay for a “real world” lawyer. Your first thought might be to check if some web archive site like archive.org by any chance might have a copy of that page. Often they don’t. And even if they did, they would never have access to the login-protected parts.
No automated tool can master the steps of the login process, and if website owners consider using a captcha, there is little hope that a program will ever get around it. This must be done by hand and from a web browser. So some people try to use plugins by saving and digitally signing all the data sent from the server.
Again, this isn’t the solution. It’s relatively easy to manipulate the DNS or routing on your machine to make another computer or even a virtual machine act as a “server”. Browsers protect against this type of fraud using SSL and certificates, but this only applies to encrypted traffic, and installing your own “root certificate” to allow for man-in-the-middle manipulation is common practice.
Carefully checking the keys used could expose such methods. If all transmitted data were encrypted by asymmetric codes such as RSA this could even be considered already signed by the origin server almost eliminating the problem. But for performance reasons in SSL asymmetric methods are only used to transmit keyphrases for faster symmetric encryption. So forging a log of the encrypted code of the data actually transmitted is theoretically possible for the client, since it knows that symmetric key (although probably even more difficult than reverse engineering some plug-ins).
To avoid all these problems the browser should not be run on your computer. What is needed is a so-called “remotely controlled browser” (ReCoBS) as it is used – for entirely different reasons – in high security facilities. This is a browser running on a different computer controlled by a third party that sends the client only a video stream of its windows and accepts only a limited set of commands. This remote browser can perform all registration and signing operations as it cannot be manipulated by its user.
What attack paths against this system need to be considered? First there is the ability to actually hack the entire ReCoBS. Having a browser controlled by a remote and possibly unknown user is a risk in itself. The browser must operate within a tightly locked sandbox, not only protecting the system from hacking, but also preventing interdependencies between parallel or successive sessions on the same computer,
When it comes to spoofing web session results, DNS cache poisoning seems to be the more dangerous option. This can be fixed by using DNSSEC when this will one day include the entire web, or possibly by having a network of machines around the world and routing the DNS request from a random one. Script injections on visited websites are a second way to get manipulated results, but there can’t be a working countermeasure by ReCoBS if the injection comes from a 4th party, and being open to such an attack in the first place should be a bigger problem to the affected site than the logs created by it.
Even considering these issues, ReCoBS still appear to be the only option that offers at least a theoretical possibility of credible evidence. If implemented correctly they can work. Most other technologies are flawed by design and it’s only a matter of time before public exploits are available.