Re: Integrity checking NANOBSD images

2006-07-11 Thread Jonathan M Bresler
> >A switch like on those 1.44'' floppy discs would be good... > >But then software/OS updates would require physical access to the box... > > For this app, the problem is that there might indeed be physical > tampering with the box despite some reasonable efforts to lock it up. If the box is sub

Re: Integrity checking NANOBSD images

2006-07-11 Thread R. B. Riddick
--- Mike Tancsa <[EMAIL PROTECTED]> wrote: > >But what if the trojan copies its files to the RAM disc and waits for this > >sha256 binary showing up? And then, when it is there, it removes its > >changes on > >the hard disc (those changes certainly must be in unused (formerly zeroed) > >areas of

Re: Integrity checking NANOBSD images

2006-07-11 Thread Mike Tancsa
At 04:45 PM 11/07/2006, R. B. Riddick wrote: --- Poul-Henning Kamp <[EMAIL PROTECTED]> wrote: > Arming a trojan to just do 'sleep 145 ; echo "sha256 = 0248482..."' > when you thing you're running sha256 would be trivia. > But what if the trojan copies its files to the RAM disc and waits for this

Re: Integrity checking NANOBSD images

2006-07-11 Thread R. B. Riddick
--- Chuck Swiger <[EMAIL PROTECTED]> wrote: > 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. > If the hash function is cryptographically secure, even a single such hash fu

Re: Integrity checking NANOBSD images

2006-07-11 Thread Mike Tancsa
At 04:34 PM 11/07/2006, Ruslan Ermilov wrote: > > > With respect to prepending a random salt to the image, can you expand > what you mean ? > It means that every time you want to checksum it, you send some random bits to be prepended to the image, then compute the checksum(s). You then do the sa

Re: Integrity checking NANOBSD images

2006-07-11 Thread Poul-Henning Kamp
In message <[EMAIL PROTECTED]>, "R. B. Rid dick" writes: >Wasn't is usual some years ago to switch the boot disc hardware to "read only" >mode? Some CF cards have that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer

Re: Integrity checking NANOBSD images

2006-07-11 Thread R. B. Riddick
--- Poul-Henning Kamp <[EMAIL PROTECTED]> wrote: > Arming a trojan to just do 'sleep 145 ; echo "sha256 = 0248482..."' > when you thing you're running sha256 would be trivia. > But what if the trojan copies its files to the RAM disc and waits for this sha256 binary showing up? And then, when it is

Re: Integrity checking NANOBSD images

2006-07-11 Thread Ruslan Ermilov
On Tue, Jul 11, 2006 at 04:18:19PM -0400, Mike Tancsa wrote: > At 04:05 PM 11/07/2006, Poul-Henning Kamp wrote: > >In message <[EMAIL PROTECTED]>, Chuck Swiger writes: > > > >>Checksumming the device image is a fine way of checking the > >integrity of it, > >>assuming it is read-only. The only th

Re: Integrity checking NANOBSD images

2006-07-11 Thread Chuck Swiger
Poul-Henning Kamp wrote: In message <[EMAIL PROTECTED]>, 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

Re: Integrity checking NANOBSD images

2006-07-11 Thread Poul-Henning Kamp
In message <[EMAIL PROTECTED]>, Mike Tancsa writes: >With respect to prepending a random salt to the image, can you expand >what you mean ? If you just run sha256 on the disk image, and the attacker finds out, he will just run sha256 himself and record the result. Arming a trojan to just do 'sl

Re: Integrity checking NANOBSD images

2006-07-11 Thread Mike Tancsa
At 04:05 PM 11/07/2006, Poul-Henning Kamp wrote: In message <[EMAIL PROTECTED]>, 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

Re: Integrity checking NANOBSD images

2006-07-11 Thread Poul-Henning Kamp
In message <[EMAIL PROTECTED]>, 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 >someo

Re: Integrity checking NANOBSD images

2006-07-11 Thread Chuck Swiger
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) 955ebad583bfc0718eb28ac89563941407294d5c61a0c0f35e3773f029cc068

Integrity checking NANOBSD images

2006-07-11 Thread Mike Tancsa
We have a number of Soekris devices that we will be deploying remotely in semi- hostile physical environments. The remote links are dialup so I dont have a lot of bandwidth available. I want to do integrity checks of the images so that I can detect any tampering of the flash image. If I