The ‘Safe’ in Safe Network stands for secure access for everyone, of course, but a Safe is also a strongbox where you can lock up your valuables. Put the two together and we can picture a network of Safes swimming in a sea of perpetually available information. It’s a nice picture.
No-one can lock anyone out of the public network—there’s secure access for everyone after all—but neither can anyone hoover up our personal data, our secrets and our stash of tokens when they’re tucked away in our Safe, protected by our painstakingly-memorised password and passphrase.
But hang on a second… what if we suffer a bump on the head? What if our paper backup copies are destroyed by fire or flood? What if we get old (it happens) and … just forget? Our precious stuff could be lost forever.
There has to be a better way—and thanks to the miracle of threshold cryptography there is! @JimCollinson explains more below.
Team news
We are in the last stages of appointing a finance officer (thank God) who will have a Fintech focus. This will add to the work Sharon did for us, but be a bit more detailed on launch, onboarding and token economics.
PROMOTION - @JimCollinson has accepted the position of Chief Strategy Officer. We all know Jim and we all know what he is capable of. This releases him to reach a larger audience with authority. Jim will work with others, including finance, to reach towards launch and beyond. We don’t need to tell you how good he will be at this, we already know 
PROMOTION - @joshuef Has accepted the role of Chief Technology Officer. Josh as you know is as cool as cats and handles conflict, debate and team spirit in a way I have never seen before. A calming influence that is super focussed on progress. We are lucky to have him and again the focus is on launch where Josh will have a lot of interaction with the launch team. Like Jim, still on the tools and still plugging away, but with that extra authority to get things done even quicker.
Both promotions have been really welcomed by the whole team, which is super cool to see.
It’s all coming together folks 
General progress
Last week we said we were tantalisingly close to removing Connection Pool from qp2p and taking it into Safe Network, and we’re happy to announce that @chris.connelly has now put this milestone firmly behind us. Sounds technical - and indeed it is technical, but in a way that simplifies things a great deal.
@yogesh is working on implementing another simplification, this one planned for some time but not rolled out yet to the testnets. When a node wants to join the network it has to do the work of aggregating the elders’ votes and then resubmitting them if it has enough.
Designing secure, resilient and usable credentials
The act of creating your own Safe is the act of creating some credentials. They are effectively one in the same. You make a set of keys that allow you, and only you, to access and use your own data; opening the door to your own conceptual secure space that starts on a single device but ends up on the Network, and spanning many.
So the first task for these credentials to be entirely unique. They won’t be stored on the Network, or on some server somewhere, like a traditional online account. So they must have enough entropy, or randomness, not to be stumbled upon, collide with someone else’s credentials, or suffer from a ‘brain wallet’ style attack.
More than that, there are another set of qualities which these credentials must imbue:
- They should be able to be created offline.
- Reliable to write down, and store on paper.
- Have a recovery mechanism.
- Can be changed, without breaking access.
- Should not rely on a human to create randomness.
- Can be used on any device. I.e. does not require me to manage separate credentials or passwords for each device I use.
- Can be used in a way to remotely revoke access to my Safe from a device I’ve lost trust in, without breaking access via others.
- Should not be stored online, on the Network, nor need to be transmitted.
- Should not contain any publicly identifiable or discernible information about me.
Going further, and making a system that is usable for people, means they should also have desirable features such as being:
- Memorable
- Multilingual
- Ergonomic and usable on a variety of devices
- Allow for additional factors to be used in future depending on my needs and hardware resources. E.g. allow me to use a hardware key, or biometric factors on my phone.
It’s quite a wishlist isn’t it? We could deep dive into each of these, but let’s just take a walk through a solution shall we, and I’ll explain on the way.
Safe Credentials using threshold cryptography
So can we do it? Well, here’s a proposal for how we can take a Multisig approach to credentials using BLS. Let me explain through the medium of wireframes.
Creating a Safe for the first time
Onboarding, creating a Safe for the first time, as I mentioned, involves making a set of credentials. To start I choose a password, and then I’m given a generated passphrase to take down, or print out:
This passphrase would be a BIP39 style phrase, with a checksum at the end.
So with these two elements, we have something you know, the Password, and something you have the passphrase; and in combination, we can generate a suitable amount of entropy.
This is the base, default, pair of credentials for a Safe. Both are required for access, so it’s strong and unique, but let’s make things a bit more usable shall we?
The next step, which is optional, allows me to create a device key if I trust the device I’m using. This is a third access key to my Safe which brings some handy features.
Firstly, it allows us to create a 2-of-3 key scheme (Multisig FTW), which means if I forget my password, I can still gain access using my phone and passphrase. Or perhaps I don’t want to enter be Passphrase each time I unlock my Safe; on this trusted device I can just use my Password and the device key, maybe utilising some inbuilt biometrics too, for an element of something you are.
I’m then ready to finish and open the Safe locally for the first time, using this set of three credentials, two of which are always required to unlock.
Mo’ Keys, Mo’ options
But I don’t need to stop there. I can create additional access keys, to provide more flexibility and resilience. From the options screen, I create additional Passphrases, perhaps a backup, perhaps one to store in different physical locations. And I can set up additional devices here too (including dedicated hardware keys like a YubiKey in future), or revoke access to any device or Passphrase I’ve lost trust in or no longer have access to.
From this suite of keys I have the ability to create a scheme to suit my own particular circumstances and threat model.
For example I can have 3-of-6 setup, or progress to k-of-n of my choice. Plus I can choose to always require a Password or Passphrase to unlock my Safe, denying access to anyone who happened to have access to two or more of my devices.
Unlocking on another device
So, I’ve created my Safe, but I want to open it on another device I’ve not used before. Let’s take a look at how that works.
I’m presented with an unlock screen, where I tap to enter an access key.
I’m then given a screen which allows me to scan a QR (which are on printouts of passphrases, or in the device key usage we’ll get to later) or I can simply start typing in a passphrase in the text input at the bottom.
If I start typing I go into Passphrase entry mode, in which we use things like type ahead, and suggestions from the phrase dictionary to speed the process. I can also rearrange the words in the phrase, or swipe to remove them if I make a mistake.
So here, we can make an interface that, while not super fast, can still be smooth and feel pretty easy to use when it comes to entering a long phrase.
When I get to the end of the phrase and enter the checksum correctly, I can proceed.
Note here that only after I have successfully entered that first key (either a passphrase, or a device key) am I prompted to enter a Password.
Here we see the Password being successfully entered and the Safe is unlocked.
After successfully unlocking, I’m prompted to create a device key on this phone, should I trust it. This would allow me to unlock without the need to enter the Passphrase each time, or get in if I forget my password.
And on that note…
Unlocking without a Password
…what do I do if I forget my Password? It’s a common occurrence, and overall one of the most significant threats to the security of our data on a decentralised Network. After all, there is no central authority to appeal to, no server to send a password reset request to, no list of usernames with password hashes. It’s down to me, and the tools at my disposal.
Thankfully, we can use those Multisig chops to get back in, should I go blank on my password, as I have a tendency to do.
I’m using a new device that doesn’t have a device key stored on it, and gosh darn it, I just can’t think what that password is. So I start by entering a Passphrase:
I’m returned to the unlock screen, and I can see the Passphrase I’ve just entered. I can’t enter a password here, because I’ve forgotten it of course, so I’ll need to use my other device to get in. I tap to Enter another Access Key and I’m ready to scan a QR I’ll produce via my other device.
Using my other device, which I’ve used before and have a device key saved on, I open the unlock screen:
By tapping the Device Key listed here, or via the meatball menu top right, or perhaps even just double tapping the lock icon I can produce a Device key screen which has a QR code to scan on the new device (or if I want to, I could show it as a passphrase and enter it more manually. Or down the line we could look at other options like NFC easy, but you get the idea).
It should be noted that the Access Key (the keyshare to be more specific) represented by the QR displayed here is generated when the screen is opened. This is passed over to the new device and, used in combination with a second key, allows the Safe to be unlocked. This avoids exposing/passing around the device key itself, rather it’s a process of creating a key specifically for the destination device, via an existing one.
So I scan the QR on the new device…
…and I’m in. At this point I can add a device key on the new device, and of course go and reset my Password too.
And depending on my particular key setup, I could even regain access to my account using only a set of devices, should I need to.
So how does this proposal stack up?
What do you think? Will this fit the bill? A Multisig approach that gives us a system of credentials that:
Can be created offline
Are ergonomic
Allow for memorability
Are human readable and pronounceable, enabling them to be written down and reliably entered
Are resilient to credential loss
Can be changed without breaking access
They don’t rely solely on humans for entropy
Can be used across a multitude of devices
Can be accessible in multiple languages, and readily expandable
Allow me to revoke access to devices I’ve lost trust in
Need not be stored on the Network, online, nor transmitted
And require no publicly identifiable or discernible information.
Is that a clean sweep?
There will be kinks to work out, undoubtedly, such as recognising and handling password typos, and syncing credential changes across multiple devices that are moving between on and offline. But we have the basis here for a strong system that should be a win for usability and security overall.
Dig in to all the detail
If you’d like to take a closer look at the wireframe user flows for this proposal, you can jump right in to the fully documented Figma file below. There’s a fair bit more nuance to it than we can cram into a dev update, so feel free to have a poke about, and as always, we welcome your feedback and comments.
Useful Links
Feel free to reply below with links to translations of this dev update and moderators will add them here:
Russian ; 
German ; 
Spanish ; 
French; 
Bulgarian
As an open source project, we’re always looking for feedback, comments and community contributions - so don’t be shy, join in and let’s create the Safe Network together!
.
