I have been thinking about how accounts and permissions are setup in Maidsafe.
It would be really nice to be able to have multiple identities, with different access rights all managed by a single account.
My idea is persona trees. When you first create an account on the network, you use a username and password to create a root persona or identity. From this root, you are able to create children persona, and children from those children. Each persona gets their own private keys, access rights, can have their own private and shared files, and has their own public ID.
A persona can impersonate any of it’s descendants and has full access to their private data, keys, and rights. In this way, you can login with a single username and password and have access to all your data and credentials.
For very sensitive data, you may encrypt a persona with a secondary password. For an ancestor to access this persona, the secondary password must be used as well as the parent credentials.
There is no publicly visible link between personas. No one can tell any two persona reside on the same tree, unless the owner provides that information out of band.
Some use cases:
Isolating data for different applications. Your banking information is stored in it’s own persona. Your facebook-like application cannot access it, unless you authorize it through the root persona. Even though data is isolated, you still have a single username and password to access all of the applications and all of the data. Because login and persona management is handled by the core application, you can be confident that potentially malicious apps cannot use your single sign on credentials to conduct privilege escalation type attacks.
You are able to login to my Maidsafe account once on my phone. The phone should retain private keys to access the network. You can isolate what it can access in this manner (allow IM and contact information, but not banking data for instance), then you must enter my password to gain temporary access to more sensitive information.
The private keys stored on your phone are unique to that device. If it is lost, you are able to revoke those keys individually without affecting the persona(s) it had access to directly.
On a social network, isolate relationships with your friends from your work relationships and your family relationships.
My idea is persona trees. When you first create an account on the network, you use a username and password to create a root persona or identity. From this root, you are able to create children persona, and children from those children. Each persona gets their own private keys, access rights, can have their own private and shared files, and has their own public ID.
A persona can impersonate any of it’s descendants and has full access to their private data, keys, and rights. In this way, you can login with a single username and password and have access to all your data and credentials.
Nice idea. Anyone thinking about this should look at hierarchical deterministic wallets as defined in bitcoin improvement proposal BIP 0032.
The proposal is certainly already supported by the passport structure in the code (Main anonymous account, public IDs and share IDs). It’s a great discussion to push forward though. What are the most secure structures? What is most natural way forward? the most user-friendly way?
This is a question that relates to the first SAFE clients (SAFEspace, and others) though.
From what I understand, the code currently has support for multiple public ID’s, but only one primary anonymous ID tied to user/pin/password credentials. The problem with this is that, if you login to a node or app with your anonymous ID, I believe you are giving that app access to all your private data, and public/shared ID’s. I would like to be able to ringfence data so that I can do things like: leave private keys for an anonymous ID on my phone so I don’t have to login with a long secure password all the time, restrict what data a given app can access, revoke specific private keys, etc.
My idea to provide this is to allow a tree of anonymous ID’s to grow from the single anonymous IDs. @happybeing has a good idea to use deterministic wallets as inspiration. However, I think there are attack vectors where, if you know the tree structure, one private key within the tree, and a number of the public keys, it is possible to derive other private keys within the tree.
You might be able to do something similar using just shared IDs within the current structure (and not actually sharing the ID with anyone else).
Either way, I think the challenge will be in the UI design to make this sort of thing usable to a regular user. Maybe it shouldn’t be directly exposed to the user. They just define access rights to data and the application figures out how to make that happen.
@happybeing has a good idea to use deterministic wallets as inspiration. However, I think there are attack vectors where, if you know the tree structure, one private key within the tree, and a number of the public keys, it is possible to derive other private keys within the tree.
This is both the benefit - the user can recover all logins from a single “seed” that is kept the and only used in emergency.
And a risk - but in practice a very small risk - if the seed is compromised then an attacker can access the whole set of keys. This is similar to the situation as now, except that one would not expose the"seed" in the essay one does does now - just for general logins.
Using this approach makes it much less likely the user would lose access to all our part of their data through forgetting a password, which could be a big problem with many passwords for multiple access control.
So for this application, I think hierarchical deterministic keys would be a good model if it can be adapted.
A main SAFE client (a trusted client that gives access to the SAFE apps) could additionally encrypt datamaps to specific parts of your data. That way, your general login still blocks apps from accessing data they shouldn’t supposed to be reading. A client can also warn the user when an application tries to access data it normally shouldn’t. These are some advantages of running SAFE apps within SAFEspace (like a good webbrowser can shield you from certain threats).
For very sensitive data, I would personally store it in a separate MAID account. Money, and medical records for example. In particular, for stand alone SAFE apps maybe it would be a good caution to start a new MAID account, as you’d have to trust this application not to go snooping around where it shouldn’t.
It falls short of what you are proposing with the master key for parents of a branch. But firstly, I don’t know how to securely implement it, and secondly, it inevitably breaks the current property that different ideas are unlinked to each other - I think. This is why I propose to consider such a structure at client level, not network level. It’s sort of like trusting your webbrowser to store your password for easy login.
The fact that you can derive descendant private keys from a parent key (or a seed) is an asset. I am talking about attack vectors where children private keys can derive parents, which is not always desirable. This post describes the vulnerability in the section, “An Understated Problem.” I am not all that knowledgeable about ECC, so I can’t vouch for the accuracy of this information.
With Maidsafe, we have a secure and synchronized data store, so I don’t know if deterministic public/private keys are really necessary. Obviously, if we want to go in the direction of persona trees, more research would be needed.
If the network can provide this protection itself, without requiring me to remember additional usernames and passwords, I would see this as a pretty nice feature.
Implementing this securely is not trivial, but I think it can be done. I trust 1Password to store my passwords for easy login (through a webbrowser plugin). They are fully encrypted and secure behind a single strong password. Maidsafe could provide the same sort of interface, without all of the messy multiple account maintenance requirements. This is the true promise of “Single SIgn On.” You don’t trust the apps that use the SAFE network, you trust a network management tool that administers privileges and identities to the client apps.
I agree. A single account with deterministic keys would potentially be secure and easy to use.
Multiple accounts could be an option if there was a way to pull them all together in a user friendly way though.
Ultimately, we want apps firewalled from one another in a simple way, that requires little or no knowledge from the user. How can this be implemented is the question.
Edit: to add, being able to share data with other child branches would be useful too. For example, you could have parent app plugins in child branches, etc.
I apologise for my misunderstanding - yes I agree we need to take into account the Buterin warning you reference here. From memory, it is I understand not an argument against using deterministic hierarchies of keys - the weakness only arises if attackers have access to multiple private keys (not public keys). Buterin is warning over giving out the private keys in the hierarchy, which he believes will happen due to people not understanding the limitations of this scheme.
Agreed. No point using it unless needed! I think anyone looking at this area should though look into BIP32 as I suggest, because the capabilities it offers might suggest features and abilities that would otherwise not be considered.
Thanks for pointing out the vulnerability. That is also essential reference material!
Brilliant thread. One underlying issue we have as an advantage is that we do not expose keys via apps, this is a good difference from bitcoin etc. So we can use this strength to allow determinism if we wished. The advantage is that its easy to remember only a seed. The disadvantage is coupling of ids via a deterministic algorithm. The alternatives seem to require additional user inputs which is a tricky one. There may be some further ideas though to help this. If the determinism was based on something unique to you like typing speed or maybe biometrics or similar. I am way out left field here though and need to think this through much more.
I do like the idea of sandboxing or app isolating though. I should also add that a secure way for apps to share session keys would also be neat from a usability perspective. We should also remember that when you are using an app from a secured public drive (i.e. a drive you trust) then its immutable except by the owner. So if an app store had a very high clean score you may not need to sandbox apps as much as we do now. You also would not need to install them at all.
Just a couple of points for the convo, hope it helps a little.
I want a way to “appear” as an unlimited number of personas with a single account, but which cannot be linked together by someone or some app interrogating SAFE, or monitoring SAFE traffic, nearest nodes excepted (I presume).
This is a limiting case of persona trees, and I think essential to allow a user to participate in different contexts, while protecting their personal identity from being linked to views or activities they don’t wish to be public.
The uses for these might be anything from researching birthday presents for a family member without them finding out beforehand, to disclosing vital information in the public interest without being persecuted for it (e.g. whistleblower faced by a powerful state surveillance adversary).
I am currently focused on the log-in/authentication portion of “My Health SAFE” app. I have found several threads in regard to logging into the SAFE network, and I love all the ideas, but for someone who is designing an app to be a reservoir of someone’s entire personally controlled health information record I have persistent anxiety with regard to authentication. I have been looking at ways for someone without the cognitive function to authenticate with the app; someone in a coma, brain injury, children, developmentally delayed, etc.
Electrophysiological bio-marker (Like the Nymi) added with some form of Quantum-Secure Authentication seems to be the best route. I think a persona tree (for care-taker type people) is absolutely necessary. Do I also need to worry about protecting this app’s data from other apps?
I noticed this thread is pretty old. Is there a more recent discussion?
We are currently working on the details, but we want to make a log-in once system, even for desktop apps. So the user logs into the SAFE launcher with a password, and then selects from a list of identities (or creates a new one) when launching an app. The SAFE launcher then passes information about the identity the user selected, so that each SAFE app launches can began “doing work”, without requesting a password from the user. A similar process would be done in Android and iOS, but the details are likely to differ slightly.
The primary goal is to reduce accidental (bugs, etc.) exposure of sensitive data (SAFE password, and other identities) through process separation. Initially users WILL have to remain vigilante that an app could steal credentials intended for another app. This is difficult to stop if a user runs multiple applications under the same local OS account, any mechanism we use to pass data from SAFE launcher to app can be seen by apps with the same privileges. Its the same problem that running local apps with oAuth have. Saavy users will be able to run as different local OS accounts (hopefully someone will have time to write a how-to on this). Long-term it would be nice to launch the apps in a container (which is currently only possible in *BSD and Linux systems), so that applications are even further restricted in what they are allowed to do. This is nearing on the SAFE-OS dream a few people have had, which would be nice for less technically saavy users.
This has not been something we considered. Since everything is open source, you can obviously create a unique login system just for your application. However, incorporating this into the existing SAFE launcher is likely ideal. How would a user in this situation login, with a fingerprint?
I like the unique electrophysiological (heart beat) biomarker for accessing health information. Not everyone has a finger, eye, hand, etc. Although every living person (Except a few people with temporary artificial hearts and transplants) has relatively the same unique heart beat template; from ~13-14 years and older. There will have to be a way to reset the password (ECG template) though, probably with predefined parent/guardians and/or next of kins. Also an ECG is very difficult to use for mass surveillance.
With the SAFE network everyone will finally be able to have a complete personal health record that can be entirely controlled by the individual; no matter the cognitive or physical ability of the individual. So the trick is creating tiered data privilege system. So if I am found unconscious the emergency service providers will be able to access a certain level of information about me, but they necessarily shouldn’t have access to my entire genetic code.
As a health care provider and a creator of health documentation, I think I should also have permanent access to the documents I create for patients; although it should be near impossible for someone to forge my identity since there is no central authentication authority.
