Re: Preventing Swap of Sensitive Values

On Mon, Aug 13, 2012 at 5:04 PM, Tom Ritter <tom@ritter.vg> wrote:
> I haven't seen this discussed yet (but may have missed it due to
> mailing list snafus), but to support a lot of the primary use cases,
> it would be very important to have some sort of mechanism to indicate
> some javascript variables (in addition to the 'obvious' ones like
> private keys in the keystore) should not be written to disk by
> whatever mechanism provided by the underlying Operating System, and
> should be zero-ed when garbage collected.  This would of course be a
> 'best effort' approach, as the variables may be written to disk in the
> event of a core dump or hibernation, but if the OS provides any
> mechanism to avoid swapping memory, I feel like it should be used.
>
> This would be used in many of the secure message applications, the
> encrypted bill use case, and anything that winds up with plaintext in
> a javascript variable.
>
> -tom.
>

Hi Tom,

Thanks for the input. Unfortunately, I'm a bit concerned whether such
an API could actually work, especially in the context of modern JS
VMs. Conceptually, this is similar to the "cleanse" API afforded by a
number of modern crypto APIs, which often require a wide variety of
subtle and convoluted  actions to avoid compiler optimizations and the
like.

However, I think an important part of this is where we try to draw the
logical security boundaries. I think most of our discussions have been
in the context of security of a web origin, and 'protecting' it from
other web origins. Much like the security considerations notes that
it's perfectly valid for an implementations to store keys in plain
text on disk ( http://www.w3.org/2012/webcrypto/WebCryptoAPI/#security-developers
) , it's probably appropriate to add informative text about this sort
of scenario.

My inclination is that it's not a problem to be solved by the "Version
1". Yes, this probably limits the ability of the application to
perform certain High Value transactions on a General Purpose
implementation using this API, but it doesn't seem like it rules out
or makes impossible a number of new and novel applications with better
security that afforded now.

Received on Tuesday, 14 August 2012 00:31:57 UTC