Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Secret material erasure #11

Open
pqwy opened this issue Mar 15, 2014 · 3 comments
Open

Secret material erasure #11

pqwy opened this issue Mar 15, 2014 · 3 comments

Comments

@pqwy
Copy link
Contributor

pqwy commented Mar 15, 2014

A bunch of sources, and some working code, has provisions to destroy crypto material (eg. by overwriting it).

I guess the underlying logic is that if an adversary is sleeping in your RAM, but you are just lucky enough for them to be out for coffee while you are doing your secret-secretly-secret computations, if you overwrite your material quickly, they won't see it when they snuggle back in your memory.

This logic is beyond me. I'd say that if the memory is compromised, all bets are unconditionally off, and hoping to catch an appropriate timing -- even the timing caled "before" -- is weak.

The thing complicates in a memory-managed language, where the compactifying GC is another adversary sleeping in your RAM, interrupting your pesky activity from time to time, and copying around whatever you are working with. At unpredictable intervals.

Granted, most key material is Cstruct.t, which is a Bigarray.Array1.t, which is allocated outside of the GC heap, but:

  • We still retain some info in offset-length descriptors which are on the heap; and
  • A bunch of key material is naturally represented as numbers whose representation is beyond reach.

Things can be worked around, but it would leave a horrid api semantics, which would, instead of simply operating on values, now operate on objects: things, with a life-cycle, instead of bits of information.

Could this possibly be worth it?

@pqwy
Copy link
Contributor Author

pqwy commented Mar 15, 2014

And of course, erasure lowers the probability of the material being paged onto persistent storage, where it really could live indefinitely. But then the same logic applies to adversaries sleeping in your hard-drives, only a little weaker because those do get trashed with all the bits still on them.

Is it enough to assert the primary target is server-side TLS on Mirage?

@avsm
Copy link

avsm commented Mar 19, 2014

In general it's just a good idea to keep track of your sensitive material and prevent it from leaking into uninitialized memory (e.g. someone else's fresh stack, or persistent swap). It's obviously diminishing returns to destroy all possible derived material from a key, but it's reasonable to track the Cstruct explicitly and ensure that it's deallocated and zeroed before being released.

@infinity0
Copy link

https://heartbleed.com/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants