A few years ago, the servers of my favorite online game went down for a few days and I was already afraid that my game character would be lost and die with all his achievements. Fortunately they fixed his problems and a few days later everything was back online. I wanted to be prepared for the next such incident, so I logged into your 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 gained and get all my stuff back. Then I looked at my screenshot and realized that I could just as easily modify it for even better in-game items. So basically it was worthless. Digitally signing it myself wouldn’t improve that.
This scenario is not limited to online games. Being able to prove that an order has been placed, a violation has been committed, or some task has been accomplished seems worth investing in overall consideration.
Obviously, you cannot make and sign such a screenshot yourself. One needs the help of a trusted third party, but often the problem is too trivial to involve or even pay for a “real world” lawyer. Your first thought might be to check if some archive websites like archive.org might happen to have a copy of that page. Often they don’t. And even if it was, they could never have accessed 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 can bypass it. This has to be done by hand and by a web browser. So some people try to use plugins to digitally save and sign all data sent from the server.
Once again, this is not the solution. It’s relatively easy to manipulate the DNS or routing on your machine so that another computer or even a virtual machine plays the role of “server”. Browsers protect against this type of fraud through the use of SSL and certificates, but this only applies to encrypted traffic and installing your own “root certificate” to allow manipulations by intermediaries is common practice.
Careful verification of the keys used could expose such methods. If all transmitted data were encrypted by asymmetric codes like RSA, this could even be considered already signed by the origin server, almost killing the problem. But for performance reasons in SSL, asymmetric methods are only used to pass key phrases for faster symmetric encryption. So faking a record of the encrypted code of the data actually transmitted is theoretically possible for the client, since it knows that symmetric key (although it’s probably still more difficult than reverse engineering some plugin).
To avoid all these problems, the browser should not be run on your own 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, sending only a video stream of your windows to the client and only accepting a limited set of commands. This remote browser can perform all login and sign operations as it cannot be manipulated by your user.
What attack paths against this system should be considered? First, there is the possibility of hacking the entire ReCoBS. Having a browser controlled by a remote and possibly unknown user is a risk in itself. The browser has to run inside a tightly locked sandbox, not only protecting the system against hacking, but also preventing interdependencies between parallel or subsequent sessions on the same computer.
When it comes to faking web session results, DNS cache poisoning seems to be the most dangerous option. This can be addressed by using DNSSEC when this one day includes the entire web, or possibly by having a network of machines around the world and routing the DNS request through a random one. Script injections into visited websites are a second way to get manipulated results, but there can be no functional countermeasure by ReCoBS if the injection comes from a fourth party, and being open to such an attack in the first place should be a bigger problem. to the affected site than the records created by it.
Even considering these issues, ReCoBS seems to be the only option that offers at least a theoretical chance of credible evidence. If they are implemented correctly, they can work. Most other technologies have design flaws and it is only a matter of time until public vulnerabilities become available.
