From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 5 16:19:40 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7B3F16A4CE for ; Sat, 5 Mar 2005 16:19:40 +0000 (GMT) Received: from machshav.com (machshav.com [147.28.0.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C04343D2F for ; Sat, 5 Mar 2005 16:19:40 +0000 (GMT) (envelope-from smb@cs.columbia.edu) Received: by machshav.com (Postfix, from userid 512) id 8F963FB286; Sat, 5 Mar 2005 11:19:39 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 88BBEFB27C; Sat, 5 Mar 2005 11:19:38 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 8A9743BFF12; Sat, 5 Mar 2005 11:19:32 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: "ALeine" In-Reply-To: Your message of "Fri, 04 Mar 2005 10:55:48 PST." <200503041855.j24Itmfa032915@marlena.vvi.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 05 Mar 2005 11:19:32 -0500 Sender: smb@cs.columbia.edu Message-Id: <20050305161932.8A9743BFF12@berkshire.machshav.com> X-Mailman-Approved-At: Sun, 06 Mar 2005 12:58:25 +0000 cc: elric@imrryr.org cc: abuse@spamalicious.com cc: briggs@NetBSD.org cc: perry@piermont.com cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: tech-security@NetBSD.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 16:19:40 -0000 > >> 1) If you're doing analysis of a cold disk, it is ~trivial to tell >> the difference between a sector that has been written only once and >> a sector that has been rewritten. > >This is hardly trivial, you are basing your statement on the false >assumption that one cannot or will not do anything to protect the >encrypted image after the initialization. One can do a lot. > >For example, one can regularly scrub the unused areas around the >encrypted image (padding) with dd(1) using if=/dev/{u,}random and >similar. This can be fully automated with a cron job. > >One can also regularly scatter files with misleading names and >contents. etc. I think we need to be careful about phrases like "one can". I decided to stop supposing and gather some real data, so I wrote some analysis tools to measure the entropy of disk drives. I need to rewrite some of my tools and do a lot more analysis, but I think the results thus far are quite interesting. See http://www.cs.columbia.edu/~smb/rawdisk-entropy.ps There are two plots shown in the file. In both, the X axis is the entropy per sector (to two digits past the decimal point); the Y axis is the number of sectors that had that entropy. The first graph is of the entire NetBSD partition on my laptop. The only difference is that in the second, graph, I deleted the sectors with 0 entropy -- those were about 25% of the disk. (The disk is 2/3 full.) For calibration, I ran the same tool on 100,000 blocks of /dev/urandom output; the lowest entropy I got was about 7.4. Quantitatively, if you pick a block at random and use 7.4 as the cut-off for "random", you have about a 77% chance of hitting a non-random, i.e., plaintext block. I have some directories which I suspect have files of high entropy (mp3s, jpgs, .tgz files, a cgd partition); if I exclude those -- a not-unreasonable move for certain classes of disks -- you have a 98% chance of hitting a plaintext block. (Caveat: that analysis is very preliminary; I have not yet actually measured the entropy of those file types. Note the large hump between 3.5 and 6 on the second graph; it may be that some of those directories fall in there.) Anyway -- the moral of the story is that you really need to analyze your environment and your threat model when designing crypto. The answer to SAN link eavesdropping might be IPsec or link encryptors; the answer to cleaning lady attacks might be cleared personnel, two party rules, or other non-crypto solutions. But don't assume, and don't say "one can" or "one should". (As a footnote, I realized that my own cgd "partition" (via vnd) was created from /dev/zero instead of /dev/urandom; the result is that the entropy of the file itself reveals almost exactly how much of the cgd partition is in use. I'll have to correct that....) --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb