Let’s be honest, not a lot of news has not been showing up in this section. It’s not to say, though, that nothing has been happening. Far from it, actually. Code has been committed on a regular basis for quite some time, but looking at blog posts, you wouldn’t know it.
The server code has been making steady progress and recently reached some development milestones. It is now possible to create an account and log in. Although that may sound like nothing special, an enormous amount of design work and learning went into it. Prior to Anselus’ founding, I didn’t know much about cryptography. The login process is a three step process. First, the client submits the workspace ID, which is just a UUID without any personally-identifying information. The server checks to see that the workspace ID even exists. Assuming that workspace ID checks out, the client is permitted to submit the user’s password. Nothing particularly special here. Once the password has been verified as authentic, the server performs an encrypted challenge-response request phase that the specific device must pass. Only then is the login complete and the device can access the workspace freely.
Although in most cases a simple username and password combination might suffice, the Anselus platform is intended for more than just everyday situations. Multifactor authentication is becoming more and more necessary, but to be honest, it’s inconvenient and really annoying. The third login phase enables a much more elegant form of MFA. Each device is uniquely identified for a workspace. If the server discovers a new device, it can send a message to other devices on the workspace to request authorization for the new device. The user can allow or deny the new device. Assuming that the device is allowed, it is added to the workspace’s device list. In this way a user can instantly know if their password has been compromised because somewhere else in the world, someone has their workspace ID and password. It also provides a form of multifactor authentication that requires the second factor only when adding a device, and the second factor can utilize any device, not just a smartphone.
The server also provides administrators a number of different ways to create an account. The default mode, private, only permits administrators to register a new workspace. In order to account for the device encryption key handling, the new workspace must be preregistered. The administrator runs a command and the server generates a one-time-use Diceware registration code. The administrator then gives the user the workspace ID and registration code. The user can then finish registration, setting his/her password and the first device can add its device key to the workspace. At no time does the administrator have the user’s password, and because the registration code can only be used once, if a malicious actor does use it, the user will know because registration won’t work. Public mode, the most lenient of the registration modes, allows anyone to create an account. As such it is not recommended, but there are situations where it would be very helpful. Two other modes which will be implemented in the future are moderated, where the user creates the account and an administrator approves it, and network, which functions just like public registration but only for a specific subnet. Although Anselus draws a hard line about end-to-end encryption, it gives service providers ways to manage a service while maintaining the user’s privacy. Getting the design for registration and logins just right has been challenging but worth the effort.
Once registration and logins were running as designed, identity services became the focus. The Anselus platform borrows a number of ideas from the concept of signets, developed for the Dark Internet Mail Environment, to implement keycards. Keycards are digital certificates which do not require a Certificate Authority. They also provide only the minimum necessary identifying information needed to ensure two parties can connect without concern. Anselus servers provide a DNS-like lookup service that also facilitates key exchange. John Doe’s Anselus address,
john_doe/example.com, is translated into his workspace address,
38499ed3-92af-4f9b-99f4-7727dbedafa5/example.com. This is so anyone can exchange an easy-to-remember contact identifier. At the same time, for those who want or need extra privacy, a person can simple opt out of creating a user ID and simply use his/her workspace address for communications. Each keycard contains a series of digitally signed entries which contain encryption keys. These keys are only used for key exchange, and the user’s keys for daily communications are never exposed to the outside world. To prevent malicious servers performing man-in-the-middle attacks, keycards are kept in a blockchain which can be altered only by authenticated users, but freely available for anyone to download. Servers are actually required to download full copies of keycard databases from other servers, which reduces synchronization complexity and still provides an easy way for a malicious change to be detected quickly – a user’s client can download a keycard from his/her organization’s server and from the recipient’s server and compare the two. Moreover, those users who would prefer having a local copy of a server’s database will have that option, and considering that each person’s keycard is just a few kilobytes, the entire database wouldn’t be huge except for the largest of organizations.
The potential of Anselus’ keycard service is immense. In addition to the encryption and signature keys used to establish communications between two parties, each keycard also has an extra general purpose encryption key which is public. This means that passwords could be a thing of the past. How? A person enters his/her Anselus address into a form on a website. The web app retrieves the person’s public encryption key and sets up an encrypted session which could only be authenticated properly by that user and no one else. The boost in security and usability cannot be understated: I go to a website, punch in my Anselus address, and I’m logged in. That’s it, and it’s secure, too. While it is true that there are other identity frameworks available, possibly dozens, this has the potential of gaining traction because the security is a side benefit, not the main goal. All in all, this project gets more and more exciting as it progresses. Until next time, friends.