Qbix Platform 2.0

Interacting with people in the SAFE network project has given me a lot more clarity on what is needed for security. Kademlia, for example, is a great addressing layer for resilient backend server selection. And joining sections / periodic churn makes it harder to collude.

I wanted to share our roadmap to turn Qbix Platform 1.0 (which lets any community easily assemble and maintain its own social app) to Qbix Platform 2.0 where we reduce the power of servers to something approaching the SAFE network. The Qbix Platform may be a layer on top of the SAFE platform in the future, which allows all kinds of front end and social aspects, including realtime messaging.

https://qbix.com/blog/2018/04/03/onward-to-qbix-platform-2-0-serverless/

One question I have is about identity. It seems to me that the SAFE network cannot allow anonymous identities, for the simple reason that some clients may become compromised and a user will have to repudiate them. But these clients will have keys to some resources, and now they shouldn’t be able to access them. Thus, there has to be a userKey which is rotated whenever a client (user agent) is repudiated and all requests by the user should include the latest userKey. I don’t see another way. True, the userKey may be different for different files, but at the end of the day, the NETWORK must know the user id (public key) of the user making a request, and a proxy won’t change that.

To summarize here is how it works:

ON CLIENT (threat model is ONLY client side):

TouchID -> Passcode -> passKey -> sessionKey

ON CLIENT AND SERVER:

sessionKey -> userKey -> resourceKey

When a client is compromised, the new userKey must be regenerated and signed by the M of N other clients. This is a special case of a stream, we call it a “keychain”. The governance in that stream type is that a change is valid if M of N clients sign it. A valid change is propagated to all participants’ clients in the stream (in this case there is one user on a domain and many clients). They then encrypt the new userKey using their sessionKeys so it gets placed in the userKeyBox (basically a key box is a key encrypted several times by multiple keys).

Such a change is done on all domains.

It seems to me that a resourceKey by itself cannot be enough to access a resource, because compromised clients will still be in possession of a resourceKey. They must ALSO have a valid userKey to get servers to send back that resource, or really process any request.

This is why the server MUST know about userKey public keys and everything can’t just be anonymous. So if a request is sent with a wrong or outdated userKey it is rejected early in the server (or server farm) request handling pipeline.

Almost all session-related info is kept client-side. Bearer tokens are just used (if at all) to represent capabilities that the server signed. Since the server knows about user ids, it may as well use an ACL locally. Bearer tokens may eventually be replaced with transferrable crypto tokens (so only one user at a time can use a resource) leading to a form of crypto-currency. And so on. But either way, we use sessionStorage INSTEAD OF cookies. Cookies become irrelevant here.

1 Like

Have you read how self encryption and account retrieval works Greg?

I don’t have time to critique your assumptions, but I don’t think you are correct in thinking that account retrieval breaks anonymity. So I think there may be something you’ve missed. Perhaps somebody else will spot this if so.

Got a link to the explanation of account retrieval? How does a server know to reject a request when a user’s device has been repudiated?

Have you read the https://primer.safenetwork.org/? I’m sure it should be covered in there - I’ll have a look later.

But the network doesn’t know about devices, no servers, no stored credentials, no record of who is accessing what. So nothing to repudiate.

The questions that raises should be answered in the primer.

So what happens if a device has one of my keys to my files…

And then someone steals it?

Greg, sounds like you haven’t read about self encryption yet? Keys aren’t stored on your device - apart from in memory while you are logged in.

EDIT: watching Nikita’s DevCon talk (just finished) might also be relevant as he talks about how application permissions can be revoked - handling errors during this multi-step process - and that some issues remain to be solved (surprisingly this error handling for apps). See towards the end before he starts taking questions (video will be posted later). It isn’t the same issue you are asking about, but I think it still might help understand how the network operates.

Do you have a link? And also maybe a time in the video to look at?

I am still a bit confused on this point. How does self-encryption handle the problem of a stolen device? I wish you had an answer to the question that could fit in a forum post and used for FAQ later :slight_smile:

I gave you a link to the primer - have you read that for info on self-encryption? I’m pretty sure it is covered there.

This is really a fundamental part of the SAFE network and I am sure after you read the SAFE primer you will see how SAFE handles this (non) issue.

It is a non issue because the network stores all the keys you need to access files. The keys are never stored on any device you use unless you physically copy the key onto the device itself.

When you log onto the network the credentials create an address (to retrieve you account records) and also the key to decrypt the account record. Your credentials, which you enter are never transmitted anywhere nor stored anywhere other than RAM while needed.

From your account record any keys needed for file access are retrieved from the network itself (directly or indirectly) and again only stored in RAM unless you physically copy the keys to the device’s storage.

Read the primer which contains your answer and so much more. https://primer.safenetwork.org/ The primer is the

1 Like

I read the primer but I still have some questions.

So if computers on the network have keys to access the files, what’s to prevent them from accessing those same files when you are not around?

Basically decryption happens on the network and not in your client?

How do we prevent the decrypted stuff from being sent somewhere? Or for the network to impersonate you and sign statements as you, if the keys are not in your client?

How can they? There is no keys on the computers for someone to use.

If you remain logged onto the SAFE network and walk away then obvious someone else could use your account where you were logged on. That occurs with any system and doesn’t mean the keys are held on the device’s permanent storage. If the device is turned off then there is nothing for anyone to find since it was all in RAM and not in storage on the device

Turn off your device and its all gone. nothing for anyone to find. Unless ypu copied something to your device’s storage.

You cannot have read and fully understood the primer. This is incorrect. The files are decrypted on your computer using self encryption algorithm. The keys are also not stored on the computer in order to do the operation. The keys are only ever in the RAM and discarded immediately after use.

If you store the decrypted content then there is nothing preventing you from sending the file you stored on the device to anywhere you please. You could also take screen shots and send them anywhere. SAFE is not trying to stop you copying content you can decrypt.

Because the way to create the keys is in your head. Your credentials allow your device (in RAM) to decode your account and gain access to the keys which are only ever stored in RAM. The network cannot decode your account record because it is encrypted with your credentials which never leave the RAM of your device.

It may take a while for all this to sink in but basically the process is

  • start client
  • enter your passphrases (secrets)
  • the passphrases generate an address and decryption key (in your devices RAM)
  • the client retrieves the data at the address generated by your passphrase
  • the client then decrypts the account info (in your device’s RAM)
  • then your client can access whatever you request and allowed access to. Files are then decrypted using the self-encryption system.

Your credentials never leave your RAM, nor the decrypt-key it generates. Your account info is only ever decrypted in your device’s RAM and never sent decrypted elsewhere or to the network.

1 Like

So based on this I am guessing one of the following is true:

  1. Your password is used to derive a key to encrypt those keys and store them on the device

  2. Your password is used to derive a key to encrypt those keys and store them on the network

If the second, then your password-derived key is sent to the network and the network can later use it to get your access keys.

So it must be the first, right?

Number 2 is right but not the way you see it.

The key is never sent onto the network.

If you read carefully I said the password generated key is kept on your device in its RAM to decrypt the account data. The client uses the key to encrypt anything needed to be stored back in the network copy of your account data which is always encrypted when sent from your device. And any account data or the password generated key is lost when the device is powered down or you log out of the network. It is only kept in RAM after all

So the key is never sent to the network and the unencrypted account info is never sent to the network and cannot ever be decrypted by the network.

1 Like

Maybe the Primer is not clear enough on this, so once you have understood this Greg it would be useful to hear feedback on ways it could be improved, or any information that was missing etc.

I’m glad you are able to persevere and @neo has time to help you get to grips with this.

1 Like