5 ms·

I have a few friends that run their own crypto nodes b/c they don't trust cloud providers (and their employees) to have access to their private keys (which may

by itake 5y ago

I have a few friends that run their own crypto nodes b/c they don't trust cloud providers (and their employees) to have access to their private keys (which may control millions of dollars). Would this tool minimize the risk of an employee snapshots the disk and RAM of their machine?

danenania 5y ago
Yes, EnvKey uses client-side end-to-end encryption and never sends secrets to the host server in plaintext (whether it's self-hosted or you use EnvKey Cloud). So there would be no way for a cloud provider employee (or an EnvKey employee) to get access from the server side. Even the names of your variables are encrypted and not accessible except on the client.
- koolba 5y ago
  Except for a cold boot style attack right? https://en.m.wikipedia.org/wiki/Cold_boot_attack https://en.m.wikipedia.org/wiki/Cold_boot_attack I’m assuming the client side code isn’t keeping the secrets in some kind of TPM right? ie anyone with root access to the server or the ability to dump the memory could pull them out.
  - danenania 5y ago
    We need to distinguish between the server where EnvKey's API is running, which contains EnvKey's back-end logic, and 'client' servers (or user devices) that are connecting to EnvKey to fetch config for a particular app/environment. (It's possible I misunderstood the distinction the parent comment was getting at.) EnvKey's API server has no access to secrets data. But you're right that a server pulling secrets via an ENVKEY access key would still have to expose those secrets in RAM to the process that needs them. We don't claim to protect user devices or connected servers from endpoint compromise. We do offer some features to help mitigate this though: - You can limit access to an ENVKEY to specific IPs or CIDR ranges. - On a user device, secrets are periodically removed from RAM if they haven't been accessed recently. - On a user device, only encrypted data is stored on disk, and the OS keychain is used on Mac and Windows. - If an ENVKEY's access it cut off, envkey-source can immediately kill the process, making the secrets harder to access from RAM. - Audit logs can help you track exactly what was exposed and when in the event of an incident. - Access to secrets is 'pushed' as far down the stack as possible... so your secrets at least wouldn't be accessible in some cloud provider database--they would need to get access to the running process itself or the machine's RAM.
    - itake 5y ago
      > - On a user device, secrets are periodically removed from RAM if they haven't been accessed recently. I looked at the ruby sdk code and it doesn't periodically remove them from RAM. Storing the ENVs in the `ENV` object makes me nervous, because its an easy target for supply attacks to dump the `ENV` to logs / remote servers.
      - danenania 5y ago
        You're right--another distinction is needed here. For a human user using EnvKey, the EnvKey 'core-process' will run on their computer. Both the EnvKey UI and the CLI talk to this core process to fetch/display data or make updates. This is the process that will periodically evict secrets from RAM if they aren't used. When loading a single environment via an ENVKEY access key, you're correct that there is no RAM eviction (in many cases this could break an app, unless it was designed to handle it). If you don't want to use ENV/environment variables, you could also output your environment to a file and then pull it into your app and parse it (you can easily export to json, yaml, dotenv, or pam format): $ es --dot-env > .env $ es --json > .env.json $ es --yaml > .env.yaml $ es --pam > /etc/environment
        itake 5y ago
        Those cmds write the variables unencrypted to disk? Looking at the ruby sdk, I don't see any decryption libraries being used. I'd imagine a more secure solution would be to give the sdk the decryption key when the variables need to be decrypted, they are only decrypted by the process in RAM. Since its ruby, and everything has access to everything in the process, it might make more sense to key management to exist in another process (thus limiting what access simple supply chain attacks have access to).
        nicoburns 5y ago
        Since it's Ruby, wouldn't any supply chain hacks have access to the source code, and thus the decryption key?
  - itake 5y ago
    +1, ideally, it should only decrypt (and fetch?) the when it needs to use the key. So 99% of the time, the key isn't sitting decrypted in memory. Having to trigger a network call each time the key needs to be used (like to sign a transaction) isn't great though :-/.

by itake 5y ago

danenania 5y ago

Yes, EnvKey uses client-side end-to-end encryption and never sends secrets to the host server in plaintext (whether it's self-hosted or you use EnvKey Cloud). So there would be no way for a cloud provider employee (or an EnvKey employee) to get access from the server side. Even the names of your variables are encrypted and not accessible except on the client.

koolba 5y ago
Except for a cold boot style attack right? https://en.m.wikipedia.org/wiki/Cold_boot_attack https://en.m.wikipedia.org/wiki/Cold_boot_attack I’m assuming the client side code isn’t keeping the secrets in some kind of TPM right? ie anyone with root access to the server or the ability to dump the memory could pull them out.
- danenania 5y ago
  We need to distinguish between the server where EnvKey's API is running, which contains EnvKey's back-end logic, and 'client' servers (or user devices) that are connecting to EnvKey to fetch config for a particular app/environment. (It's possible I misunderstood the distinction the parent comment was getting at.) EnvKey's API server has no access to secrets data. But you're right that a server pulling secrets via an ENVKEY access key would still have to expose those secrets in RAM to the process that needs them. We don't claim to protect user devices or connected servers from endpoint compromise. We do offer some features to help mitigate this though: - You can limit access to an ENVKEY to specific IPs or CIDR ranges. - On a user device, secrets are periodically removed from RAM if they haven't been accessed recently. - On a user device, only encrypted data is stored on disk, and the OS keychain is used on Mac and Windows. - If an ENVKEY's access it cut off, envkey-source can immediately kill the process, making the secrets harder to access from RAM. - Audit logs can help you track exactly what was exposed and when in the event of an incident. - Access to secrets is 'pushed' as far down the stack as possible... so your secrets at least wouldn't be accessible in some cloud provider database--they would need to get access to the running process itself or the machine's RAM.
  - itake 5y ago
    > - On a user device, secrets are periodically removed from RAM if they haven't been accessed recently. I looked at the ruby sdk code and it doesn't periodically remove them from RAM. Storing the ENVs in the `ENV` object makes me nervous, because its an easy target for supply attacks to dump the `ENV` to logs / remote servers.
    - danenania 5y ago
      You're right--another distinction is needed here. For a human user using EnvKey, the EnvKey 'core-process' will run on their computer. Both the EnvKey UI and the CLI talk to this core process to fetch/display data or make updates. This is the process that will periodically evict secrets from RAM if they aren't used. When loading a single environment via an ENVKEY access key, you're correct that there is no RAM eviction (in many cases this could break an app, unless it was designed to handle it). If you don't want to use ENV/environment variables, you could also output your environment to a file and then pull it into your app and parse it (you can easily export to json, yaml, dotenv, or pam format): $ es --dot-env > .env $ es --json > .env.json $ es --yaml > .env.yaml $ es --pam > /etc/environment
      - itake 5y ago
        Those cmds write the variables unencrypted to disk? Looking at the ruby sdk, I don't see any decryption libraries being used. I'd imagine a more secure solution would be to give the sdk the decryption key when the variables need to be decrypted, they are only decrypted by the process in RAM. Since its ruby, and everything has access to everything in the process, it might make more sense to key management to exist in another process (thus limiting what access simple supply chain attacks have access to).
        nicoburns 5y ago
        Since it's Ruby, wouldn't any supply chain hacks have access to the source code, and thus the decryption key?
- itake 5y ago
  +1, ideally, it should only decrypt (and fetch?) the when it needs to use the key. So 99% of the time, the key isn't sitting decrypted in memory. Having to trigger a network call each time the key needs to be used (like to sign a transaction) isn't great though :-/.