From owner-freebsd-security@FreeBSD.ORG Tue Jul 11 20:24:20 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 8719D16A4E1 for ; Tue, 11 Jul 2006 20:24:20 +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 22CB043D72 for ; Tue, 11 Jul 2006 20:24:20 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 6DC755DDD; Tue, 11 Jul 2006 16:24:19 -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 A7vzqgRv-MS6; Tue, 11 Jul 2006 16:24:16 -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 7BEA65D79; Tue, 11 Jul 2006 16:24:16 -0400 (EDT) Message-ID: <44B408E7.8070000@mac.com> Date: Tue, 11 Jul 2006 16:24:07 -0400 From: Chuck Swiger User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Poul-Henning Kamp References: <77121.1152648353@critter.freebsd.dk> In-Reply-To: <77121.1152648353@critter.freebsd.dk> 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 20:24:20 -0000 Poul-Henning Kamp wrote: > 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. That suggestion is a very good point, although trying to find a single trojaned image which matches several checksum methods is supposed to be a highly difficult task. -- -Chuck