linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Joel Reardon <reardonj@inf.ethz.ch>
To: linux-mtd@lists.infradead.org
Subject: Re: Security enhancement for UBIFS with secure erase feature
Date: Thu, 27 Oct 2011 09:33:12 +0000 (UTC)	[thread overview]
Message-ID: <loom.20111027T111843-772@post.gmane.org> (raw)
In-Reply-To: 1315747360.18731.57.camel@sauron

Greetings all:

So coincidentally I've been working on a secure deletion patch for UBIFS. (I'm a
grad student researching secure deletion here in Zurich.) I'm mostly finished
implementing it and the results are really good. It works by encrypting each
data node individually with a different key, storing the keys in a (logically)
fixed area, and then periodically atomically updating the key blocks to purge
the old
unwanted keys. A small number  erase block erasures are needed to purge all
deleted data, and since each data node is individually encrypted, there's no
overhead added in terms of seeking / random access, and truncations and
overwrites are also securely deleted. The keys are written ahead of time, and
assigned out as they are needed.

The implementation is well separated from the rest of UBIFS; it uses the
compress/decompress functions to handle cryptographic operations. The state of
keys (unused, used, deleted) is managed by the tree node cache: when adding a
node, the key is used, when removing it, then its deleted; the replay
mechanism thus also performs key management with the same code. Its a handful
of changes to UBIFS and a new data structure containing all the key
functionality. Keys are purged during checkpoint, and I was careful to make
sure that a full device scan is not needed for my modification, it works with
the commit/replay, and it can recover when power is lost during any point of
the purging proceedure.

I have a couple questions to ask the main developer, mostly about orphans for
which I found the documentation not quite clear. I'm quite keen to get
this integrated into UBIFS, however this will be the first time I've
contributed to the kernel so in this regard I'm unsure of the best practices
and so forth.

cheers,
Joel

  reply	other threads:[~2011-10-27  9:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-08 14:35 Security enhancement for UBIFS with secure erase feature Stelling Carsten
2011-09-11 13:22 ` Artem Bityutskiy
2011-10-27  9:33   ` Joel Reardon [this message]
2011-10-30 12:51     ` Artem Bityutskiy
  -- strict thread matches above, loose matches on Subject: below --
2011-10-31 17:51 Stelling Carsten
2011-09-05 16:01 Stelling Carsten
2011-09-08 11:18 ` Atlant Schmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=loom.20111027T111843-772@post.gmane.org \
    --to=reardonj@inf.ethz.ch \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).