Bind ubuntu to hard drive.

[Jeffrey F. Bloss]

TwinZ Ubuntu Mailing List wrote:

> Exactly! That is my point, so I am looking for two ways to protect the
> drive's contents:
> 
> Step one: by using a completely encrypted file system (root as well).
> Surely, dd would be able to do a bit-by-bit copy, but they'd end up with a
> hard drive with encrypted files in it and could not just read them by
> mounting the drive to another system. Right?

Mostly right, however if your machine is compromised while running all
bets are off. Whole disk encryption protects nothing while volumes are
mounted, and they must be mounted for the machine to boot. This is one
of the reasons container encryption is advantageous in some situations.
It doesn't make much sense to rely on whole disk encryption to secure
an "always on" system, but data in an unmounted file or partition
container can be equally secure either way because you can unmount that
container without loosing the rest.

I do realize that your stated scenario included someone would removing
a drive and putting it on another machine where shutting it off is a
given, but it's important to realize that copying a drive in its
entirety doesn't *necessarily* demand the drive be dismounted or
powered down first. ;)

It also doesn't make much sense to try and prevent someone from
duplicating a running setup, when they can essentially do the same
thing by installing their own version of that operating system and add
data to make the mirror image "perfect".

> Step two: binding the installation to the hard drive serial. Even if one
> made a bit-by-bit copy the new drive would have a different serial and -in
> theory- would not boot. Right? Haven't figured out how to exactly implement
> this one, here are a few thoughts.

There's probably a thousand ways to do it ranging in complexity from
trivial to bizarre. ;) The point is, without a strong encryption back
end they're utterly useless, and even with strong encryption they're
utterly useless if an attacker can duplicate your encryption keys. As
you more or less deduced in another post, this pretty much chops any
autonomous system off at the knees because whatever keys you're using
have to be present for the system to boot, and if the OS itself can
read them freely, so can the attacker.

If you bind to a hard drive serial number for example, all an attacker
has to do is write down that serial number while they're duplicating
your partitions, and feed that falsified information to the OS in some
sort of "virtual" environment, or by manually adjusting the serial
number of another drive. Either of which are possible with the right
software and/or hardware.

Oddly enough, what you're proposing is essentially what an entire
industry has invested considerable resources in trying to implement.
Sony alone spent billions over the course of many years trying to keep
people from watching movies in an "unauthorized" way. It took some kid
in Germany about a week and some pocket change to crack the result
of all that effort. ;) What you're dealing with here is essentially the
same thing at its core.

> - I need a similar command like the " label " or " vol " used in dos to
> extract the drive's serial somehow. I could start from there.
> 
> - Is there a way (startup script maybe) to have the OS loader check the
> drive's serial and prevent startup in case of a mismatch? Since the drive

As an academic exercise things like this have great value, but if your
goal is actual security you're probably wasting your time. Decide what
your typical threat model will be, implement the restrictions that
address it best, and be done with it.

For most people this will be a policy of shutting off unnecessary
services, restricting access to necessary services with good passwords
or secure keys, and either whole disk or container encryption depending
on the typical usage a given machine sees. Laptops are generally more
likely to benefit from whole disk because when they're vulnerable,
they're often "off". They're also more likely to move between untrusted
networks, so additional encrypted containers aren't a bad idea for more
sensitive data.

Desktops can go either way, but if you leave the machine on and
unattended with any regularity whole disk is pretty much a waste of
clock ticks. Put your sensitive data in an encrypted container, and make
sure it automatically dismounts after a period of time if possible in
case you forget to do it manually before walking away.

Forget about trying to roll your own "trusted platform" scheme unless
you're just interested in an experiment or two, or have the financial
incentive and academic muscle to improve on an inherently flawed
methodology. And if you do manage to perfect DRM make sure you contact
Sony ASAP. They have really deep pockets, and as I've now given expert
business advice on the matter I'm your agent, and deserve 10%. <grin>

-- 
     _?_      Outside of a dog, a book is a man's best friend.
    (o o)         Inside of a dog, it's too dark to read.
-oOO-(_)--OOo------------------------------[ Groucho Marx ]---
                    http://wrench.homelinux.net/~jeff/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 892 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20070325/0d015db8/attachment.sig>