I'm no guru with kernel nor crypt - but there could be a far
easier method to identify the "guy" who wants the kernel to reboot:
use a file like /etc/reboot.key (owned by root, rights 600) - this
file is enough protected from user-access to be sure no regular user
can see the bytes in it, a copy of it would be on a disc. It
conatins structs like this:
struct rebootkey{
unsigned long fromdate;
unsigned long tilldate;
char key[200];
};
I think only persons who have regular access to your system should
be able to reboot it - and those people _are_ able to come to you
and get the disk - they don't need crypto-computations just to
"guess" the current key, they can get it direct and without
accessing the network - I've never seen a cracker who can read
discs which lie in a box outside the drive :-)
how to use:
1st) compile your kernel with this option (only activated when it
finds a valid struct in this file - or by a user process
which tries to find that (root-process of course))
2nd) start a small program which generates this file for some time
(let's say 2 months, and a new struct per day)
3rd) copy this on one single disc (hidden in the tresor of the
superuser - who should be the only one able to do such things)
4th) let the kernel or this userprocess search for the next struct
the time the current expires (needs ~200 bytes of data in the
kernel and some code to handle it) - the key would be marked
as expired the time it is read (on the system; and the time it
is used on the disc; reboots are unusual under Linux, so it
wouldn't be needed a second time - for development kernels:
just let it expire once in 10 minutes)
5th) machine crash: just pick up the disc, insert it in a terminal,
start remoteboot and let it send a icmp package with the
current key -> machine reboots
->> no havy computation at reboot time, no fs-access at the same
time (actual struct is buffered in the kernel), and no one can get
the keys - except she/he is a cracker and crackes your root
login - but if she/he did that she/he has control at all and
doesn't need this feature to do cat /dev/random >/proc/kmem
->> point for crypto gurus: find an algorithm to get real random
strings for that key (those where I can't compute them if I
have much information about your system - like rtc-time,
hardware adresses, some world-readable files, the algorithm
itself)
->> if you want to be _really_ secure: make the keys expire once in
5 minutes and/or add the option trusted IP's or trusted
ethercards to the struct OR don't use it for sensible systems
(disconnect them from the net and you can be sure no hacker
outside the room can access your data via network)
happy hacking,
Konrad