From owner-freebsd-security@FreeBSD.ORG  Tue Jul 11 20:05:56 2006
Return-Path: <owner-freebsd-security@FreeBSD.ORG>
X-Original-To: freebsd-security@freebsd.org
Delivered-To: freebsd-security@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 22B9C16A4E1
	for <freebsd-security@freebsd.org>;
	Tue, 11 Jul 2006 20:05:56 +0000 (UTC)
	(envelope-from phk@phk.freebsd.dk)
Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 9BCE343D6D
	for <freebsd-security@freebsd.org>;
	Tue, 11 Jul 2006 20:05:55 +0000 (GMT)
	(envelope-from phk@phk.freebsd.dk)
Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2])
	by phk.freebsd.dk (Postfix) with ESMTP id B63851703F;
	Tue, 11 Jul 2006 20:05:53 +0000 (UTC)
To: Chuck Swiger <cswiger@mac.com>
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
In-Reply-To: Your message of "Tue, 11 Jul 2006 15:50:38 -0400."
	<44B4010E.7010809@mac.com> 
Date: Tue, 11 Jul 2006 20:05:53 +0000
Message-ID: <77121.1152648353@critter.freebsd.dk>
Cc: freebsd-security@freebsd.org
Subject: Re: Integrity checking NANOBSD images 
X-BeenThere: freebsd-security@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Security issues \[members-only posting\]"
	<freebsd-security.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-security>, 
	<mailto:freebsd-security-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-security>
List-Post: <mailto:freebsd-security@freebsd.org>
List-Help: <mailto:freebsd-security-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-security>, 
	<mailto:freebsd-security-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jul 2006 20:05:56 -0000

In message <44B4010E.7010809@mac.com>, Chuck Swiger writes:

>Checksumming the device image is a fine way of checking the integrity of it, 
>assuming it is read-only.  The only thing you might want to do is use two or 
>three checksum algorithms (ie, use sha256 and md5 and something else), so that 
>someone can't create a new image which matches the sha256 checksum of the 
>original.

A much better idea is to send a random "salt" to be prepended to
the disk image before it is run through sha256, that would prevent
the attacker from running sha256 and any other algorithm you
could care for on the image, store the results and return them
with trojans.

Copying the sha256 binary over is no guarantee against a kernel
embedded trojan.

But then again, how paranoid one has to be is a matter of preference.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.