Security is important to us; it’s an issue of reputation.  Part of the attraction of Open Source software is the fact that it will be scrutinized by very clever independent people which provides confidence that no (deliberate or unintentional) security “back doors” exist.  We do not claim to have found the holy grail or to be delivering a perfect product with absolutely no security issues.  We do however take these things very seriously as a matter of professional pride and keeping Cloak up-to-date will be an ongoing effort.

Quite often security is inconvenient.  A lot of people use short passwords that are easy to remember and easy to type.  Every product is a balance between security and convenience and we have made some practical compromises between the two with Cloak.  The following sections details these compromises – apologies in advance to non technical readers for any geek speak below.

Cloak Itself

Some will argue (quite properly) that the Cloak device is in itself is a compromise.  In a perfect world every internet user would know exactly how to configure their software to protect their personal information and nobody would need a Cloak. They argue that because no user friendly hardware device can protect identity in the teeth of carelessness, using such a device could provide a false sense of anonymity to a grossly incompetent user. For example, if you use the cloak while logging into a web-site over an unencrypted http connection while your browser is configured to supply location data, or if you use your real name and/or address, using Cloak won’t help you ( the British intelligence agency GCHQ refer to this sort of user error as an “epic fail”).

We believe that a product such as Cloak is nevertheless justified and that user limitations can be addressed through a modest amount self education. If users are at least able to understand that the process of signing in to Facebook, Google or similar reveals their identity whether they are Cloaked or not, they are capable of learning enough to stay private to a high degree.

SSH Access

Cloak is supplied with a running SSH server.  Access to this SSH server is only possible from the LAN side of Cloak and until the owner of Cloak has supplied an administrator password, no access through SSH is possible. This trade off forces sensible behavior on the user and therefore sacrifices ease of use to functionality.

HTTP Access

Cloak is supplied with an administration GUI (known as Luci) and access to this GUI is through an unencrypted HTTP connection.  HTTP Access is however only possible from the LAN side of Cloak.

There are two reasons we use HTTP rather than HTTPS.  We could enable HTTPS using a self-signed SSL certificate.  This would result in alerts in most modern browsers and would make it hard to use for inexperienced users.  Alternatively we could implement a properly signed and trusted individual certificate in each Cloak device.  This would make the manufacturing process complex and would significantly increase the cost of each device.

In the light of these issues we feel that using HTTP is a reasonable compromise since access to the GUI can only take place from the LAN side using an encrypted WiFi connection (WPA2 PSK/CCMP). A malicious attack would have to be made from within Wi-Fi range of a device. All access to the Web GUI from the Internet is blocked by the Cloak’s built-in firewall.

Root Password & Wi-Fi Keys

It’s a well known fact that many people do not change default passwords.  We believe we should deliver a product that protects users from themselves in this regard.

Cloak will be supplied with a randomly generated administration password and set of Wi-Fi keys. These default keys will be stored in a read-only part of the flash memory and printed (exactly once) on a label on the device case.  It will be possible to change the password and the Wi-Fi keys through the Web GUI, but since the keys are individual for each device they can be left as they are reasonably safely.

Protecting physical access to the label can be achieved by simply keeping it out of sight – in a safe for the really conscientious. Pen and paper is about as secure as it gets for plaintext password storage.

The default keys are stored in an area of the flash chip marked as read-only by the kernel in a read-only file system (squashfs).  The only way the keys can be written is through the boot loader. We do that it in the factory; subsequently you would have to open the Cloak up and solder a serial console onto it.