[Botan-devel] RFC: memory locking

[Nathaniel Smith]

On Mon, Nov 12, 2007 at 09:22:34PM -0500, Jack Lloyd wrote:
> On Mon, Nov 12, 2007 at 06:30:11PM +0000, Nathaniel Smith wrote:
> Another possibility here is to use std::vector with a custom
> allocator: which is pretty difficult in C++03 and is made
> exceptionally ugly via the lack of template typedef support, but seems
> somewhat more sane in C++09 (but I haven't yet read all the WG papers
> WRT allocator changes, so I don't know if it provides enough hooks
> that this could reasonably be done). That at least avoids having to
> reinvent container types. Actually this method might be usable today
> with something like
> 
> template<typename T, size_t INITIAL_SIZE=0>
> class botans_new_vector : public std::vector<T, botan_allocator_of<T> >
>    {
>    public:
>       botans_new_vector() { /*resize to INITIAL_SIZE if set*/ }
>       void clear() { /* zeroize contents */ }
>       ~botans_new_vector() { clear(); }
>    };
> 
> but TBH I don't know if this approach is a good idea at all (deriving
> from std::vector seems somewhat unkosher, though I know it can be /
> has been done).

I actually can't see any problems with this approach, though I share
the uneasy feeling that there *must* be something wrong...

> > The only sane thing from a security standpoint, yes; the only sane
> > thing from a speed standpoint is just the opposite.  Kernels get
> > pulled on by both camps...
> 
> >> (Not to mention that swap encrypted with a random key chosen at
> >> boot time is trivial to implement).
> > Very true.  But no-one uses it.
> 
> I know! Which I think says something about how important most
> users/sites consider the possibility of data leakage via swap.

Indeed!

But we can't really have one API for most users, and then another API
for users who are more worried about security...

> > I'm nervous about a plan that changes the API in such a way that it
> > becomes impossible to achieve secure key handling.  In practice, it
> > might well be impossible to achieve now -- at least without herculean
> > extra effort (auditing code to be suid safe, for instance, like gpg
> > does) -- but if those other issues get solved tomorrow, it would be
> > nice if Botan weren't stuck saying "oops, can't use me".
> 
> A change to std containers would make that pretty difficult. The
> question in my mind is what, if anything, secure key handling (in the
> very limited sense that Botan is providing) is giving in terms of
> actual security, and if is worth the costs. Can you provide a case
> where it would be something useful or important? Part of the problem
> is I've got no scenario to motivate this code's existence.

Arguably, "any time crypto code actually handles valuable secrets".
Data exposure via swap is a very plausible attack, though not one that
most of us have to worry about in practice, esp. since our "secrets"
are pretty lame.  Of course, the people who do care about this
probably should use encrypted swap, but hey, crypto's effectiveness or
lack thereof is completely invisible to most users most of the time,
so it's sort of our job as developers to worry about the stupid edge
cases for them...

The other reason, of course, is that people will look at Botan, see it
doesn't have this feature which they consider critical, and sigh and
decide they'll just have to use Crypto++ instead, warts and all.
Whether that's a sane reason or not doesn't necessarily matter.

> > (At the moment, it looks like the ability to make executables
> > setu-CAP_IPC_LOCK is going to make it into linux distros before
> > default-encrypted swap, for instance.)
> 
> Link?

It's been merged in kernel.org 2.6.24, coming to a distro near you...
sometime in the next 6 months, maybe:
  http://lwn.net/Articles/254559/

-- Nathaniel

-- 
So let us espouse a less contested notion of truth and falsehood, even
if it is philosophically debatable (if we listen to philosophers, we
must debate everything, and there would be no end to the discussion).
  -- Serendipities, Umberto Eco