Skip to content

Home

Jump to bottom Edit New page
Gary Bilkus edited this page Jun 17, 2013 · 4 revisions

Tricki - a very small encrypting wiki written in javascript

What is it?

Tricki is a tiny application which implements a wiki for storage of confidential information. tricki itself consists of a single page of javascript and a single page of html, and is free software. Of course it relies on a number of third-party free software javascript libraries and assumes that you have the necessary infrastructure on which to install it.

Like other wikis, tricki allows you to create and link pages from the browser. Unlike most other wikis, the data in those pages is encrypted on the browser and stored on the server already encrypted. Tricki adds an extra layer of security ( discussed in detail below ) but it does not remove the need for ssl or a properly configured server to run it on.

Tricki is intended primarily as a proof of concept. It's certainly usable ( I use it myself ) but if you aren't comfortable with the instructions below, I wouldn't risk trying to use it for anything important. If there is sufficient interest in Tricki then I plan in due course to turn it into something more suitable for general use.

Installation

Tricki runs on a standard webserver which has been configured to support ssl, webdav, and javascript. All my testing uses Apache on Ubuntu, but I would be amazed if it didn't work on pretty much any flavour of Unix and probably Windows as well.

In the instructions below, I assume that you have already set up the following:

Please ensure that the webdav directory is password protected as otherwise anyone at all would be able to access and modify the data it contains. Although the data we store is encrypted, we still don't want strangers messing with it! Also, if you know how, you may want to be doubly paranoid and encrypt the webdav data on the server side. See later for why this may be a good idea.

Once the webserver is set up, go to http://github.com/bilkusg/tricki to obtain the latest source code and follow the instructions in the INSTALL.txt file.

Basically, all you need to do is copy the javascript files into your javascript folder, put tricki.html on your website and edit tricki.html to reflect your local site setup.

Then browse to tricki.html and get started.

Using

If you have installed tricki as above, then simply go to https:///tricki.html You will see a minimal screen which asks you for a password and then to click on a link below. At this point, if you are paranoid, you might wish to view the page source to check it hasn't been tampered with, and even download the javascript files to check they look OK.

Once you're satisfied, ( and assuming you trust the machine you're on! ) enter your password. This can be anything you like and will never leave the webpage. If you forget it, you will lose access to all your pages. There is no safety net.

At this point you will see a small menu at the top of the screen, and an html page representing the 'main' page of the wiki. You can now:

  • go directly to any other page if you know its name, including a brand new page you can then create.
  • click on links on the page which may send you to other pages in the wiki or to external pages ( be careful..... )
  • see and edit the page source
  • update the page with the edited source, which will persist an encrypted copy of the page on the webdav server.

If you want to refer to another page in the wiki you use: Link Display Text Everything else is standard html. That's all there is to it.

Rationale

Apart from the pleasure of showing that you can build on existing code to produce a usable wiki in so few lines, what problem is tricki intended to address? Well, like most people, I have lots of information relating to bank accounts, web passwords and so on, which I can't be certain to remember, and which I need to be able to call up - potentially when I'm out and about.

I don't want this data to be stored in the clear anywhere, not on my laptop or phone, not even on my server, and certainly not in the cloud on someone else's server. But I do want it to be easy to back up on the cloud and to be accessible from anywhere.

The accessible from anywhere requirement more or less forces this to be a web application. The security requirement makes ssl along with some level of access control essential. And obviously the data has to be encrypted somewhere. So there are three possibilities:

  • Encrypt/decrypt on the server using a server-side library
  • Encrypt/decrypt in the browser using a client-side library
  • Both

The case for doing server-side encryption if you really care about your data is convincing. Servers can do much stronger encryption using much better understood techniques, and there are any number of ways of setting up webdav so that the files it serves are stored encrypted on the server. However, even if you have ssl and server side encryption in place, there is still a good case for also doing browser-side encryption as well to protect against a number of plausible risks:

  • If the server is in the cloud somewhere, then there are third-parties who can access it. Your secure keys and or passwords must live somewhere on the machine (even if only in ram for short periods of time), so anyone with root access to your machine can in principle find a way of getting at your data. If you are using well-known software, the chances are someone already has an apparent work-alike with a backdoor which they could deploy and you'd be none the wiser. So your encrypted data may not be quite as secure as you'd like to think. And if you're busy travelling the world, you probably don't have the time to check that your server is uncompromised.
  • If you are using a third-party's infrastructure, you can't be sure that your ssl session is as secure as you think it is. To protect themselves, many corporations are modifying their web proxies to allow the interception of ssl traffic for limited inspection in a way which the locally deployed browser infrastructure does not notice. So if all decryption is done server side, your data might end up being captured inside the corporation's proxies. From where some malicious third-party employee could potentially get at the data.
  • If however, the unencrypted data and password/key never leave the browser, then even a malicious third-party server-side would be unable to retrieve the data without breaking the encryption which we are assuming is infeasible.

Wheels within wheels

Now if I were an evil admin on your server, and I wanted to get at your tricki data, the easiest way to do it would be to nobble your javascript libraries, at which point the attacker can do whatever they want. You might think that if your server is compromised, you're in deep trouble anyway, so why bother with client-side encryption? It turns out that even in this deeply troubling scenario, the client-side encryption approach can provide extra opportunities for protection.

  • You can choose to inspect the javascript files as text to satisfy yourself that they are as they should be. Any serious hacking is likely to be fairly obvious.
  • You could set up a completely independent machine somewhere else to pull down the site and validate it on a regular basis.
  • If you are using your own laptop or tablet to run tricki, you could serve the javascript locally instead.
  • You could retrieve the javascript from a third-party trusted location which many other people also use, and will notice if it's hacked.

The key point is that if your server is compromised in a way which breaks the security of tricki's client-side encryption, it can only be done in a way which is visible on the client ( because some of the files downloaded to the client will be changed ). Whereas if your server-side encryption is compromised, you almost certainly need to be logged in on the server to discover the fact.

So, to cut a long story short: If I run tricki on my tablet or pc or mobile phone, over ssl, to a server in the cloud, and I check that the javascript I'm being served is as it should be, then my data should be safe from network snooping or hijacking, and from my server being compromised by anyone without the ability to decrypt by force. And if my tablet or phone is stolen, the data I care about won't be anywhere on the device unless it's stolen while actually browsing to the secure site.

What about running tricki on someone else's PC such as in an internet cafe? Well, it goes without saying that if the PC you use has malware on it, such as a keystroke logger or screen dumper, then whatever you type and whatever you see can be compromised, and nothing, however clever, can prevent that. That's why if the data you retrieve is seriously confidential, you should never access it on a machine you don't completely trust.

Notes

Tricki is intended to be a personal wiki for confidential information and as small and simple as possible. So there's nothing in the application to protect you from yourself. If you overwrite a file, it's gone unless you have a backup somewhere else. If you add markup to a file which hijacks the browser, you can do that. You can do anything in a tricki page that you can on any web page. If a tricki page contains a browser-side script, it can be run.

Room for improvement

  • There is currently no way to change the password on a tricki site.
  • It would be nice if tricki supported some standard wiki markup rather than just native html.
  • The same webserver can run as many different tricki sites as it wants, but each one needs a separate webdav location and a separate customized copy of tricki.html. It would be nice to add a tool to do the setup automatically, to allow tricki to run as a service somewhere....
  • Because of the way tricki works, such a service could be audited to ensure the scripts weren't corrupted or compromised, and the auditing could be done by anyone on the web - they just need to download and check the javascript and .html file. Even if the service were attacked, the attacker couldn't get at the data of people who hadn't used the site since the attack, and if those people took the right precautions, they'd know the attack had happpened.

Technical details

The solution I came up with involves less than a page of javascript and html, together with a few very nice libraries written by others:

The resulting program, called tricki, uses webdav to retrieve encrypted pages from a server ( over https if properly configured ), and a locally entered password to decrypt and encrypt these pages inside the browser using sjcl. This offers the following:

-No unencrypted data is stored anywhere.

  • The decryption key is never sent over the wire, not even as part of an ssl connection. Even someone who could snoop server side would never get the key.
  • Although a third party who had compromised the ssl connection could potentially gain access to the webdav-served files, the worst they could do would be to delete or damage them. Without the password they couldn't either read them or change them effectively.
  • And it's OK to keep backups of the webdav files somewhere else, like in a public cloud, because they are useless without the key.
  • If someone steals my laptop or home PC, and manages somehow to guess my personal login, they still don't have the ability to obtain my confidential information.
Add a custom footer
Add a custom sidebar
Clone this wiki locally