From owner-freebsd-security@FreeBSD.ORG Tue Jul 11 19:50:57 2006 Return-Path: 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 A587016A4E5 for ; Tue, 11 Jul 2006 19:50:57 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07AA143D64 for ; Tue, 11 Jul 2006 19:50:49 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 3685B5DD8; Tue, 11 Jul 2006 15:50:49 -0400 (EDT) X-Virus-Scanned: amavisd-new at codefab.com Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emKELmLrCh59; Tue, 11 Jul 2006 15:50:48 -0400 (EDT) Received: from [192.168.1.251] (pool-68-161-117-245.ny325.east.verizon.net [68.161.117.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id ECD1E5DBA; Tue, 11 Jul 2006 15:50:47 -0400 (EDT) Message-ID: <44B4010E.7010809@mac.com> Date: Tue, 11 Jul 2006 15:50:38 -0400 From: Chuck Swiger User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Mike Tancsa References: <6.2.3.4.0.20060711142809.04a6f8e0@64.7.153.2> In-Reply-To: <6.2.3.4.0.20060711142809.04a6f8e0@64.7.153.2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 19:50:57 -0000 Mike Tancsa wrote: [ ... ] > # ssh remote1.example.com "/tmp/rand-directory/dd if=/dev/ad2s1a > bs=4096k | /tmp/rand-directory/sha256" > 120+1 records in > 120+1 records out > 505389056 bytes transferred in 169.727727 secs (2977646 bytes/sec) > 955ebad583bfc0718eb28ac89563941407294d5c61a0c0f35e3773f029cc0685 > > Can I be reasonably certain the image has not been tampered with ? Or > are there trivial ways to defeat this check ? 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. -- -Chuck