All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Drewry <redpig@dataspill.org>
To: device-mapper development <dm-devel@redhat.com>
Cc: Marian Csontos <mcsontos@redhat.com>,
	Mikulas Patocka <mpatocka@redhat.com>,
	Milan Broz <gmazyland@gmail.com>
Subject: Re: DM-Verity
Date: Thu, 6 Jun 2013 09:41:38 -0500	[thread overview]
Message-ID: <CABmXcB-eN+iB+HdMn7MegJdGuxnRE5j5g+RPi9YTcxbQmCBenQ@mail.gmail.com> (raw)
In-Reply-To: <45934.192.168.200.1.1370447997.squirrel@gesmail.globaledgesoft.com>

Hi Pavan,

I think there's a bit of a mismatch in the terminology that you're
using.  I'll try to help:

On Wed, Jun 5, 2013 at 10:59 AM,  <pavankumar.p@globaledgesoft.com> wrote:
> Hi All,
>    I understand that hash generated by "sha256" is encrypted,

sha256 is a type of cryptographic hash algorithm.  It is a one-way
transformation of some data.  In this case, the hash isn't encrypted,
it just has desirable properties when acting as a strong checksum over
some dataset.

The hash passed in during setup (for the table) is the root hash of a
hash tree (also called Merkle Trees).  It is a checksum over the depth
below it in the tree which in turn is a checksum over the depth below
it, until the leaf nodes on the tree are the blocks-on-disk
themselves.  The self-checked tree structure provides transitive
integrity assurances verifiable at any time if you have the full data
set and the root hash.  It is possible to allow partial verification
of any path through the tree if the nodes along the path from the leaf
to the root are precomputed and made available.  dm-verity takes
advantage of this property to provide high performance integrity
assurances.

> but is there any way to corrupt hash value stored in hash device?

The hash tree that lives on the hash device is completely untrusted.
The hash tree can easily be corrupted with 'dd' just like with the
data device. If the hash tree is corrupted, dm-verity will fail to
verify the data because it will be unable to create a verifiable path
through the hash tree from the block to the root hash that was passed
in at device setup.

> Can the hash device be protected by a signature?

Generally, you will want to protect the dm-verity table line with a
signature and not the hash device itself.  At any point you can
recompute the hash device with veritysetup.  However, the "root of
trust" for a dm-verity device is always the hash passed in during
device mapper setup.  It is ideal, then, to ensure that the hash value
and device settings are always what was expected when the dm-verity
device was created or last updated.


I hope that helps,
will

      reply	other threads:[~2013-06-06 14:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-31 13:28 [Fwd: Re: DM-Verity Tool] pavankumar.p
2013-06-03 14:29 ` Mikulas Patocka
2013-06-05 15:59   ` DM-Verity pavankumar.p
2013-06-06 14:41     ` Will Drewry [this message]

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=CABmXcB-eN+iB+HdMn7MegJdGuxnRE5j5g+RPi9YTcxbQmCBenQ@mail.gmail.com \
    --to=redpig@dataspill.org \
    --cc=dm-devel@redhat.com \
    --cc=gmazyland@gmail.com \
    --cc=mcsontos@redhat.com \
    --cc=mpatocka@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.