Accommodating server-side encryption?

  • New Wordpress Plug-In Forum
    Guest:

    Just a note that we have a new forum to contain discussions relating to the Wordpress plug-in which Daniel Persson originated and has been making great progress on. You'll find it under "Server-Side Solutions."

    /Steve.

Carl

Member
May 19, 2018
15
5
I just came to think of sites that offer encrypted storage space to users (like Dropbox), and started wondering if SQRL and the SSP API can offer everything these sites need to encrypt/decrypt things based on users' SQRL IDs?

Could this be done without the server admins being able to decrypt users' encrypted storage spaces? Could such space be accessed/decrypted simply by the user logging in with SQRL, or would a separate query have to be made (where the site issues a SQRL challenge that the user has to handle in order to decrypt things)?
 

Vela Nanashi

Well-known member
May 19, 2018
633
107
I think that in theory you could use what SQRL already has to handle encrypted storage yes.

You would just have the SQRL storage client generate a secret key that it can encrypt and ask the server to hold, that can then be used to distribute the key as needed to the different clients you use to connect to that storage.

Or you could remove that requirement if you tie the encryption directly to the master key, and then the full url of the file to generate the key for said file. If you want the names and sizes of the files to be obscured though you would need to encrypt those and/or implement a file block based cipher and store files as same sized blocks with the metadata (such as filename) inside those blocks too.
 

shanedk

Well-known member
May 20, 2018
317
86
There's an option in the SQRL spec for the server to request that the client generate a cryptographic secret independent of the identity key and it can then use it as an encryption key for the user that it doesn't have to keep stored. I don't know if it's been implemented in the SSP API.
 

PHolder

Well-known member
May 19, 2018
918
124
these sites need to encrypt/decrypt things based on users' SQRL IDs
It's unclear to me what you asked for. If the site is decrypting things, then it's not possible to prevent "admins being able to decrypt users' encrypted storage spaces"... they just have to wait for the user to log in (i.e. put a trap in the software that waits for the user to log in with SQRL then get the password (assuming they didn't already have it) and store it for later.)

If you want TNO (trust no one) type operations, then you just want a server that stores any old block it's given, no questions asked. If you don't have TNO, then the server operator HAS to be trusted at some point... unless you store it and never access it again.
 

Vela Nanashi

Well-known member
May 19, 2018
633
107
As PHolder says to get TNO you need that block storage, as then there is nothing the server operator can actually do. Of course they can use SQRL to determine who to bill for said blocks and to only give access to those to that person, and also the cryptographic functions used in SQRL could be used to implement a TNO block storage system, it is just not part of things currently.
 

Steve

Administrator
Staff member
May 6, 2018
992
290
www.grc.com
Carl: EXACTLY what you are asking for is already built into the SQRL specification at the protocol level. And for precisely the use-case you note: A site wishes to securely encrypt data on behalf of its user which IT has no capability to decrypt. This is not provided by the minimal SQRL protocol since the only thing the server has is a user's public key.

To answer this need, the protocol offers two optional parameters called SIN - the "secret index" - and INS - the "indexed secret". During the authentication interaction a website can provide a "secret index" and the SQRL client will return an "indexed secret" which is securely derived and tied to the user's identity.

There's an option in the SQRL spec for the server to request that the client generate a cryptographic secret independent of the identity key and it can then use it as an encryption key for the user that it doesn't have to keep stored. I don't know if it's been implemented in the SSP API.
This is exactly what Shane noted above... and he's also right that the SSP API does not implement this. And, for that matter, the SSP API also does not implement SQRL's "Ask" facility. Implementing the SIN & INS in the API is tricky since it needs to survive rekeying. This is tricky since the user's secrets are based upon their identity key. The SQRL specification handles this rekeying straddle, but the abstraction provided by the SSP API places this over on the API side.

I've added SIN, INS and ASK to the ToDo / ToThinkAbout list for the API.
 

Vela Nanashi

Well-known member
May 19, 2018
633
107
If that secret is ever sent to the server it can theoretically keep it, and in that case would be able to decrypt things later. However it does provide a secret key that can be used for whatever purpose one might have. Am I missing something Steve?
 

Steve

Administrator
Staff member
May 6, 2018
992
290
www.grc.com
Hi Vela... No, you're NOT missing anything. This facility is not meant to prevent websites from cheating. After all, they could simply not bother encrypting anything that they are keeping for the user. Rather... it is meant to ALLOW websites to protect themselves from hacking/attacks by NOT retaining the ability to decrypt something they are holding on behalf of their visitors.

An example of this is LastPass. They retain a "blob" on behalf of their users which they have no capacity to decrypt. But when the visitor provides the key, then it can be decrypted.
 

shanedk

Well-known member
May 20, 2018
317
86
If that secret is ever sent to the server it can theoretically keep it, and in that case would be able to decrypt things later.
It could, but it doesn't have to. That's the point. In many countries including the USA, the government can issue a warrant requiring a website to turn over all information they have stored about the user, but they don't require them to store anything. If they do have it, they have to turn it over, but they don't have to collect it.

So the server, not having to store the encryption key, could be required to give the government useless things like the SSPK and the encrypted blob, but they can't turn over the encryption key if they don't have it--and that wouldn't do the government any good.

Whether or not you trust the website is a whole other matter.
 

Vela Nanashi

Well-known member
May 19, 2018
633
107
I could see a nice augmentation to SQRL client, that allowed the client to act as a decrypting agent for encrypted blobs kept by a server for the user. Without the key ever having to leave the client (travel to the server), of course this does not really have to be a protocol of SQRL, it is just that it already has the cryptographic tools needed for it. Of course that probably would annoy governments, just like any TNO encryption does.

--- Edit ---

For instance server could send a blob of stuff to the client, the client decrypts it, and then the blob can be accessed by the site via an iframe (for viewing a document or image without dynamic elements) or redirect onto the client's server, where the encrypted content can be interacted with, it can then be re-encrypted when interaction is complete and sent back to the site along with redirecting back to the site. Of course there are issues here with scripts from potentially many different sites being executed in the localhost domain at least if the blob uses scripting for the interactivity, not ideal. I am not quite well versed on how much a script can do with content from another site, like localhost, given the isolation that javascript has for different domains.
 
Last edited:

shanedk

Well-known member
May 20, 2018
317
86
At the moment, there's no way to do a client-only key with SQRL. Once the capability is there to do CPS with cross-device login as well as local, the spec could be updated for SQRL to generate a local key and append it to the CPS link. So if the server returns:

Code:
https://example.com/page.php
Then the client could append the key thusly:

Code:
https://example.com/page.php#<key>
Anything after the # is not sent to the server so it can be used by the page locally to decrypt the data. (Of course, you'd still have to trust the server not to stick in a script to send it back to the server...)

Such a thing could be implemented now, but it would only be available when using same-device login. It wouldn't be available when scanning the QR code.