Re: securing netboot
>>>>> Tzafrir Cohen <tzafrir.cohen@xorcom.com> writes:
>> Do I understand correctly that the netbooting Debian Live is
>> currently inherently insecure against both eavesdroppers and
>> intruders?
> PXE is indeed inherently insecure.
Well, it's not that bad when gPXE is considered:
>> I see that even if the gPXE option to securily check the kernel and
>> initramfs images after downloading is used,
See also:
http://www.etherboot.org/wiki/safebootmode
But I don't like much what that page reads.
>> NFS has still to be secured separately.
... And it's what bothers me the most.
> This relies on running gPXE code.
Does it? My experience with bootstrapping suggests that any
Linux bootloader will fit here.
> And this means you have to replace the boot media if you change the
> kernel and/or the initramfs.
Yes. Therefore, a write-many media has to be used, such as an
USB Flash drive.
> The initramfs in Debian Live can certainly change on configuration
> changes (and is recreated each time you build the system anyway).
Agreed.
>> Anyway, the process of establishing the secure connection to the
>> netboot server depends on a kind of secure ``token'' (say, a private
>> key and an X.509 certificate.) Do I understand it correctly that,
>> in principle, the availability of such a token early during the boot
>> process may allow for the whole netboot process to be secure?
> What is your threat model?
Basically:
* the network cannot be trusted at all;
* neither the local operators;
* but the computer hardware can be trusted; (in particular,
there're no hardware sniffers embedded into the keyboards or
main boards, etc.)
The situation is, roughly, that an organization ``donates'' some
of its computers (say, ``diskless stations'') for a certain time
(the forecoming new year's holidays) and for a certain project.
The computers are connected into the organization's network,
which at the very same time serves some random users, and
therefore cannot be ultimately trusted.
>> The secure token may, e. g., be embedded into the initramfs image,
>> which, together with the kernel, may be stored on a removable media,
>> such as a USB Flash or a CD-R (DVD+R) disk.
> A uniqueue key for each media?
A unique key per IP address. I expect that each medium will be
used to boot a bunch (in the order of tens) hosts and therefore
will contain a number of these keys.
> Why? The initramfs may contain customizations and I would like to
> occasionally rebuild it.
Yes.
> Redistributing it for every media would not be fun.
Note that the medium could be re-used after the kernel and
initramfs are loaded into memory by the bootloader.
There're going to be roughly a boot medium per boot operator.
There won't be too many media.
> So can easily add an extra key onto the media itself, though.
> And then again, why would the server trust on the client's report of
> this unique checksum in the first place?
Did I say anything about checksums? The whole point is to use
assymetric keys (e. g., RSA) for authentication!
It seems to me that the problem could be solved by getting an
IKEv1 or IKEv2 server running very early during the boot process
(even earlier than the root FS is available.) Once it's
running, the whole network exchange becomes inherently secure.
The task seems to be solved.
http://en.wikipedia.org/wiki/Internet_Key_Exchange
> What is the point of it being unique? I get the feeling you have your
> own system for providing unique IDs (and you don't like using
> e.g. MAC addresses for various reasons). Could you provide more
> information about it?
It seems that the Wikipedia page linked above has all the
relevant info and (or) links, but if there're some related
questions, I'd be glad to answer at least a few.
--
FSF associate member #7257
Reply to: