Addonics CipherUSB Review – Portable Encryption Made Easy

In a business environment, FDE can be useful but not nearly as much as being able to encrypt at the file level. After all, to encrypt a disk requires that it be external (and thus usually not backed up properly to the servers in a work environment) and limits the usefulness of that disk aside from the files you want encrypted. Transmitting the file to anyone else will require either giving them the whole disk, or removing the file from its encryption first. In all, it’s hardly a perfect solution – and it’s a big part of the reason why encryption policies in smaller corporate environments can get lax.

In a big office, chances are that there is an IT team creating a secure portal, active directory services, group policy and other tight file controls that allow fine-grained protection. However, small offices routinely utilize a simpler file server or NAS box… and encryption, if used at all, is a basic FDE. Most of the time, careful planning of user rights doesn’t even enter into the plan, much less actually materialize, so employees develop the habit of keeping “in process” and sensitive work on their desktops or USB drives that can be lost or stolen.

The CipherUSB FLE versions are designed to target this problem. By allowing you to encrypt specific files wherever they may reside (on USB, on your HDD or on the server), you can protect your file when you’re done using it, without having to encrypt an entire drive. Need to email a very sensitive document to another office? No problem. Want to make sure your more sensitive files get into the server backups? No worry. You can even share the same dongle between different people by having them re-encode the device when they use it, rather than spend bunches of money on multiple sticks. Change passwords for one-off file security to share between offices. The possibilities are endless on this front.

All of this is accomplished through the auto-mounted tool that initialized the device in the first place (kudos to Addonics for keeping it simple – there is exactly one EXE). What it lacks in attractiveness (really, this is about as horrible of a GUI as far as aesthetics go as you can get), it largely makes up for in simplicity. There are really only a couple things of note – a big pair of icons (lock and unlock) in the upper left, a directory tree on the left and a files window pane on the right. Navigate through the left to the directory you want, drag the files on the right to the big lock icon, and watch them be appended with an “.Addonics” extension. Want to do a whole folder at once? No problem – right click on it on the left pane, select “Folder Encrypt” and it will encrypt all of the files in the directory. It’s worth noting here that for some reason, this process is not recursive and will not encrypt files in subsequent directories contained in this one.

That’s it. The file is encrypted and won’t be able to be opened without a similarly encoded CipherUSB.

What, you were expecting more? The point was simplicity… and Addonics NAILS it.

For extra safety, inserting the two-factor model will require the password used to initialize it each time before you can begin using the device at all.  However, the same thing can be accomplished on the single-factor models simply by changing the password to something generic after you’re done using it.  Personally, I’d rather the convenience of single-factor with the ability to switch it up on-the-fly than having to do passwords every time.

You can’t please everyone…

What Addonics nails in simplicity, it misses in polish. The software is outright painful to look at, and for its effort to include one or two highly unusual operating systems for any type of business environment (Windows 98-2000 and Mac), it has sacrificed one of the greatest things available on the desktop today – Drag and Drop.

File encryption could (and should) be seamless and not require the horrendous tree navigational system that this software has. It could be even simpler than it is – a hot-spot “widget” on the desktop that you can drag a file onto one part of to encrypt, or another part to decrypt. The software demands local administrator privileges to run (presumably because you’re hooking the Windows File API), so it could easily have a cleaner interface… it’s hardly like Addonics is using TK bindings for tons of cross-platform support (No FLE Linux support, even as a command-line… which also makes very little sense given what’s here). All of the password changing functions could be accessible from the Windows taskbar while the software is open. I’d say it’s just poorly thought-out, except that I’m not sure it even WAS thought of… aside from one logo change, the interface is identical to the reference software which Enova designed.

An additional interface annoyance is the “Encrypt folder” issue. If my project has lots of subdirectories (which most of what I do does), I want to drag a parent folder to a “lock” icon and have everything in that folder encrypted. I don’t care how you go about it: recurse the subdirectories and encrypt every file individually, or zip the whole directory and encrypt the zip (less optimal but still functional). Again, if you already have API hooks that require administrative privileges, this just isn’t hard.

Going further down that little rabbit hole, why not just create a small installer with a right-click context menu as “Encrypt… “, or at least present that as an option? We’re looking for simplicity for the user here. Any person using a device like this is liable to use it multiple times on the same system. I detest clutter on my OS and I love the zero-fingerprint that the CipherUSB leaves behind… but if you’re already calling administrative privileges every time the device is inserted, why not just let an Administrator install a small program or service so that it doesn’t need the autorun (which is an annoying, annoying “feature,” by the way)? Leave the self-contained “No install” version on there for systems that the user doesn’t want to clutter.

If you really want to push driver-less, self-contained hardware decoding with a multi-platform interface, I’m all for it… but then there is simply no reason to not include a very simple bit of Linux CLI connectivity. And if it’s not going to be platform agnostic, then pick your biggest platform and do it right (preferably without requiring admin privileges every time, which is a security risk unto itself). I love multi-platform functionality, but in the business world there exist two major types of systems: Windows desktops, and Linux Servers. I am a Mac user and a Linux desktop user, and even I have to come to grips with that. A Mac interface is nice, but it’s probably 5% of the audience at best – and that 5% would probably be willing to front the cost to have a better looking interface with tighter integration anyhow (since we’re already being charged $10 extra).

I’m also not a fan of the “.Addonics” extension added to encrypted files. Sure, it seems like harmless (if a little shameless) self-promotion, but let’s consider this from a security perspective. If I get a hold of one of your encrypted files, the first thing I’m going to do is Google for what the blankity-blank an “Addonics” file is. That’s going to pull up the company name, instantly. I know the file is encrypted, so I go to the “Products/Encryption” area of the page. There sits the CipherUSB and a bunch of hard drive enclosures, and I know I’m looking at an individual file and not an HDD. So in about thirty seconds of effort, I’ve already nailed down your encryption to a CipherUSB FLE pass-through device. My only decision left is ECB vs CBC, and if I order one of each then all that’s left is scripting a simple link to brute-force passwords. We’ve suddenly turned AES256 encryption into nothing more than a very rudimentary password-cracking, all because someone wanted to do a bit of brand promotion. This extension should default to some nebulous string that is user-modifiable and can be changed with the password, both to help ID files internally encrypted by different passwords (if the company so chooses), and to protect the encryption device from being known to an outside agent.  Yes, the user could rename the extension afterwards… but what a pain, particularly for lots of files! 

Finally, the device takes a full 20 seconds on two different machines before it is actually functionally active (due to mounting the autorun partition and initializing the X-Wall chip), and the USB drive behind it tries to connect first. Depending on when in the cycle Windows polls the USB drive, the dongle sometimes tells Windows that the drive is unformatted (as if expecting FDE). I think this is because the same chip allows both FDE and FLE – it needs to initialize fully to determine which mode it’s in. Granted, this is minor in the grand scheme of things, but is another little thing that maybe could (and probably should) be polished.