Potential new SQRL feature

[jvgagliardi]

Hey all,

I am a Security Now podcast listener and am new to security. I do web development and after hearing about SQRL I had an idea for a feature I think would be neat.

The idea is to remove web server data security management by leaving it to the SQRL clients. Let's say the a webpage wants to send secure data back to the server. The process would work like this:

1) The webpage makes a call to a SQRL API client side that does the following:
- accepts the plaintext data as input
- returns the ciphertext (how the data gets encrypted with the user's identity is beyond my knowledge)
- from my understanding, the SQRL clients register the sqrl:// protocol, so adding a new route should be possible
2) The webpage then sends the encrypted data to the server. This allows the server to care far less about securing that data because even if it gets out it is worthless to anyone but this specific SQRL user.
3) When a webpage wants to get the plaintext data back they can make a second SQRL API to reverse the process

I think SQRL alone is awesome but an additional feature like this, I believe, would give developers an even greater reason to start using it, as securing data is one of the most difficult things to manage in organizations. Furthermore, using SQRL to manage secure data both forces users to use SQRL more and puts a user's data security in their own hands instead of having to depend on organizations.

Let me know if this is even possible to do using a SQARL identity,

Thanks,

John Gagliardi

 

[PHolder]

remove web server data security management

This feature already exists. It may not be well covered in the docs, but you can see it mentioned in https://www.grc.com/sqrl/SQRL_On_The_Wire.pdf on page 10

Client Secrets

ins = INdex Secret
When the immediately previous server reply contained a Secret Index (sin=value) name & value parameter, the output of the user's identity key forming HMAC256 is passed through the EnHash function and used to key to a secondary HMAC256 which is used to hash the server's provided sinliteral value without modification. The secondary HMAC's 256-bit output is base64url encoded and returned to the server as the value for this INS parameter. This allows servers to obtain user-tied secrets, typically for decryption, which they do not need to store.

pins = Previous INdex Secret
Whenever the INS parameter, above, is being returned to the server, and if the user's identity also contains at least one previous identity key (PIDK), that previous identity key is used, as above, to also produce and include the matching PINS parameter and value. When more than one previous identity key exists, and while the server continues indicating that it does not identity the user by either of the two presented identity keys, the client will successively iterate through each of the previous identity keys, producing and returning synchronized PIDK and PINS name=value parameters.

 

[Paul F]

As I understand it, the "sin"/"ins" feature in SQRL is designed to work as follows:

User initiates log-in using SQRL button or QR code
SQRL client sends a "cmd=query" to SQRL server
SQRL server recognizes the user and sends an "sin=<value>" request in its reply to the SQRL client
SQRL client sends a "cmd=ident" to SQRL server with an "ins=<key>" response.
SQRL server encrypts the user data with the ins key, saves the encrypted data and deletes the ins key, making the encrypted data secure.
To recover the encrypted data, a user login sequence with the sin value must be repeated to obtain the ins key from the SQRL client

This is not quite what @jvgagliardi was requesting. While the intended result is the same (securely encrypted data on the server), the encryption/decryption is done on the server side, not the client side.

 

[jvgagliardi]

@PHolder @Paul F Thanks for the feedback. I agree with Paul that one of the goals I would hope for is that users never need to send valuable data unencrypted away from the local machine.

 

[Dave]

@PHolder @Paul F Thanks for the feedback. I agree with Paul that one of the goals I would hope for is that users never need to send valuable data unencrypted away from the local machine.

As expected/hoped, SQRL never sends anything of value, ever. The SQRL user is identified by their public key (public, by definition) and the proof of identity challenge is simply a server-generated nonce that the client is asked to sign using the corresponding private key and return the signed nonce. Nothing of any value leaves the client.

 

[jvgagliardi]

As expected/hoped, SQRL never sends anything of value, ever. The SQRL user is identified by their public key (public, by definition) and the proof of identity challenge is simply a server-generated nonce that the client is asked to sign using the corresponding private key and return the signed nonce. Nothing of any value leaves the client.

My mistake. I misunderstood the Clients Secrets section. Is there some documentation of how a webpage might use a SQRL client in this way?

 

[Dave]

My mistake. I misunderstood the Clients Secrets section. Is there some documentation of how a webpage might use a SQRL client in this way?

Presumably, you have read the SQRL ESSENTIALS forum. For a real "deep dive" there is always SQRL Explained.