5 ms·

I am confused, is private key actually uploaded to server or just imported into client java script?

by adontz 5y ago

spapas82 5y ago
The private key is not uploaded to the server, only the public key. It is loaded to the client javascript (localStorage) as you say. Also both the encryption and decryption are performed client side. The result is that if the server is compromised no data should be leaked.
- upofadown 5y ago
  Then that brings up the question; how is the private key backed up and does it need to be backed up? Or does the loss of the data on a system mean you start over for that system?
  - spapas82 5y ago
    Yes that's right. The backing up of the private key and its passphrase is done out of this application. So if an authority loses access to its private key then they need to generate a new key pair and start over. Of course they will lose access to all the files that are stored in the server and have been encrypted with that key's pair (unless they have already downloaded them and saved then in a different place).
- c22 5y ago
  If the server is compromised what's to stop an attacker from replacing the end-user javascript with a malicious payload and quietly waiting for it to steal the keys?
  - spapas82 5y ago
    Yes you are right, nothing. However that is a different and much more difficult kind of attack than the common one where an attacker retrieves all the files stored on the server and goes away. Also I'm really not sure if such a determined attacker could be stopped somehow... Any suggestions?
    - c22 5y ago
      Whether or not an active attack is much more difficult than a passive one depends on the specific security profile of the entire service. Often a passive data-exfiltrating attack will become possible due to an innocent mis-configuration on the server, but mis-configuration can open the door to active attacks as well. There is no guarantee that any mistake in configuration will only allow passive attacks or that an attacker will choose to just "go away" after retrieving all of your files. With this system, specifically, active attacks will be quite rewarding to any potential attacker because secrets are saved indefinitely and every user-key they steal will allow the recovery of multiple secrets. Since the rewards are high you should expect the chances of active attack to be heightened. In order to mitigate against this you need the enduser to be able to verify the proper functioning of the encryption/decryption apparatus. Usually this is accomplished with separate binaries, checksums, reproducible builds, and etc. Of course any solution will be vulnerable during updates of the encryption/decryption endpoints, often an out-of-band channel is used to transfer the update or the verification checksum. These challenges are particularly fraught when attempting to implement a secure system using in-browser javascript. Not only is the entire encryption/decryption algorithm redistributed frequently, regardless of whether or not it has changed, but the tooling around authentication and validation of browser-resident javascript is currently very weak. In addition to compromise of the server, the system is still vulnerable to local attacks as well as a whole host of in-transit attacks that more static e2e systems don't have to worry about (e.g. someone forgets to enable https, or happens to connect through a suss proxy). Perhaps some sort of javascript pinning could help to alleviate some of the threat-surface, but to my knowledge no major browsers support anything like that.
      - spapas82 5y ago
        Thank you for this great explanation! I understand that the prolem is inherent in in web-ased security systems and not much can be done. However, let's suppose that I packed the client functionality to an electron app (i.e executable with some signature) so the .js files doing the encryption/decryption would not be downloaded from the server each time but they would reside inside the electron app. Would that be better from a security standpoint against the attacks you mention or I'm missing something?

I am confused, is private key actually uploaded to server or just imported into client java script?

by adontz 5y ago

I am confused, is private key actually uploaded to server or just imported into client java script?

The private key is not uploaded to the server, only the public key. It is loaded to the client javascript (localStorage) as you say. Also both the encryption and decryption are performed client side. The result is that if the server is compromised no data should be leaked.

upofadown 5y ago
Then that brings up the question; how is the private key backed up and does it need to be backed up? Or does the loss of the data on a system mean you start over for that system?
- spapas82 5y ago
  Yes that's right. The backing up of the private key and its passphrase is done out of this application. So if an authority loses access to its private key then they need to generate a new key pair and start over. Of course they will lose access to all the files that are stored in the server and have been encrypted with that key's pair (unless they have already downloaded them and saved then in a different place).
c22 5y ago
If the server is compromised what's to stop an attacker from replacing the end-user javascript with a malicious payload and quietly waiting for it to steal the keys?
- spapas82 5y ago
  Yes you are right, nothing. However that is a different and much more difficult kind of attack than the common one where an attacker retrieves all the files stored on the server and goes away. Also I'm really not sure if such a determined attacker could be stopped somehow... Any suggestions?
  - c22 5y ago
    Whether or not an active attack is much more difficult than a passive one depends on the specific security profile of the entire service. Often a passive data-exfiltrating attack will become possible due to an innocent mis-configuration on the server, but mis-configuration can open the door to active attacks as well. There is no guarantee that any mistake in configuration will only allow passive attacks or that an attacker will choose to just "go away" after retrieving all of your files. With this system, specifically, active attacks will be quite rewarding to any potential attacker because secrets are saved indefinitely and every user-key they steal will allow the recovery of multiple secrets. Since the rewards are high you should expect the chances of active attack to be heightened. In order to mitigate against this you need the enduser to be able to verify the proper functioning of the encryption/decryption apparatus. Usually this is accomplished with separate binaries, checksums, reproducible builds, and etc. Of course any solution will be vulnerable during updates of the encryption/decryption endpoints, often an out-of-band channel is used to transfer the update or the verification checksum. These challenges are particularly fraught when attempting to implement a secure system using in-browser javascript. Not only is the entire encryption/decryption algorithm redistributed frequently, regardless of whether or not it has changed, but the tooling around authentication and validation of browser-resident javascript is currently very weak. In addition to compromise of the server, the system is still vulnerable to local attacks as well as a whole host of in-transit attacks that more static e2e systems don't have to worry about (e.g. someone forgets to enable https, or happens to connect through a suss proxy). Perhaps some sort of javascript pinning could help to alleviate some of the threat-surface, but to my knowledge no major browsers support anything like that.
    - spapas82 5y ago
      Thank you for this great explanation! I understand that the prolem is inherent in in web-ased security systems and not much can be done. However, let's suppose that I packed the client functionality to an electron app (i.e executable with some signature) so the .js files doing the encryption/decryption would not be downloaded from the server each time but they would reside inside the electron app. Would that be better from a security standpoint against the attacks you mention or I'm missing something?