How do I secure secrets in memory?

[Sage Gerard]

I got sloppy here in a Stripe integration: https://github.com/zyrolasting/stripe-integration/blob/master/main.rkt#L31

I'm not an InfoSec expert, but I know I'd like to secure the secret key used here in memory instead of using a parameter.

I'd probably encrypt the value provided by a client module and store it (write-only from the client's perspective) using set-box!. But I have several other questions:

1. Does the garbage collector keep a clear text copy of the secret in memory before I encrypt it? If so, how can I make it easy for a client module to set the secret key AND make it such that a garbage collection pass will remove the clear secret from RAM?

2. Are there any existing cross-platform Racket projects that can proactively keep secrets away from the garbage collector and swap space? Nothing relevant comes up for "secret", "security" or "swap" on the package index.

3. Are there any other intermediaries in a Racket process that might keep a copy of a cleartext secret?

~slg

[George Neuner]

On 9/27/2019 12:56 PM, Sage Gerard wrote:

I got sloppy here in a Stripe integration: https://github.com/zyrolasting/stripe-integration/blob/master/main.rkt#L31

I'm not an InfoSec expert, but I know I'd like to secure the secret key used here in memory instead of using a parameter.

I'd probably encrypt the value provided by a client module and store it (write-only from the client's perspective) using set-box!. But I have several other questions:

1. Does the garbage collector keep a clear text copy of the secret in memory before I encrypt it? If so, how can I make it easy for a client module to set the secret key AND make it such that a garbage collection pass will remove the clear secret from RAM?

Obviously the plaintext must be kept until the crypttext exists.   I assume you are asking if the plaintext will persist AFTER encryption, and that answer is "yes".  The plaintext string will persist until the collection following the point where the program abandons it - but program can overwrite the string immediately after encrypting to erase the original value.  There still would be a small window of vulnerability, before/during encryption, but you can minimize it as much as possible.

2. Are there any existing cross-platform Racket projects that can proactively keep secrets away from the garbage collector and swap space? Nothing relevant comes up for "secret", "security" or "swap" on the package index.

Sorry, no clue.

3. Are there any other intermediaries in a Racket process that might keep a copy of a cleartext secret?

Not 100% certain, but I don't think so ... not unless the program itself makes copies. 


George

[Ryan Culpepper]

On 9/27/19 6:56 PM, Sage Gerard wrote:
> I got sloppy here in a Stripe integration:
> https://github.com/zyrolasting/stripe-integration/blob/master/main.rkt#L31
>
> I'm not an InfoSec expert, but I know I'd like to secure the secret key
> used here in memory instead of using a parameter.
>
> I'd probably encrypt the value provided by a client module and store it
> (write-only from the client's perspective) using set-box!. But I have
> several other questions:
>
> 1. Does the garbage collector keep a clear text copy of the secret in
> memory before I encrypt it? If so, how can I make it easy for a client
> module to set the secret key AND make it such that a garbage collection
> pass will remove the clear secret from RAM?

If the secret ever exists as (or within!) a Racket string or byte
string, then I think you should assume that the GC might leave old
copies in memory when it moves objects around. Memory allocated by a
foreign library or using Racket's malloc in 'raw or 'atomic-interior
mode shouldn't get copied by the GC.

> 2. Are there any existing /cross-platform/ Racket projects that can

> proactively keep secrets away from the garbage collector and swap space?
> Nothing relevant comes up for "secret", "security" or "swap" on the
> package index.

I thought about this briefly when I was working on the crypto package,
but I decided it was way too difficult to address at the time.

> 3. Are there any other intermediaries in a Racket process that might
> keep a copy of a cleartext secret?

If you read the secret from a file, it might occur in an IO buffer that
is not securely erased. If you read it in encrypted form and then
decrypt it, the decryption implementation might use intermediate storage
that isn't securely erased.

Ryan