Unattended reboots (was Re: The clouds are not random enough)

[Philipp Gühring]

Hi,

> If you (or anyone on this forum) know of technology that allows the
> application to gain access to the crypto-hardware after an unattended
> reboot - but can prevent an attacker from gaining access to those keys
> after compromising a legitimate ID on the machine - I'd welcome hearing
> about it.  TIA.

I (re?)invented a concept for that application, which can be applied in
certain situations.
I have started from the assumption that we are talking about something
like an E-Business system that is hosted in a normal commercial
environment with wired, routed networks.
The attack-vector I wanted to secure against was stealing the machines.
So in the scenario, an attacker would break into the building, steal the
server, get out again, and would try to get access to the data afterwards.
As long as the machine stays in place, it should be able to reboot
unattendedly, as soon as it's somewhere else, it shouldn't be able to
reboot unattendedly anymore.

The concept is to have a secondary server (or several secondary servers)
somewhere else, which has the necessary key available. It should be
situated in a place where it is highly unlikely that it also gets stolen
when the primary server gets stolen, and it has to be connected through
a somewhat trusted routed network.

Now the secondary server has configured the IP address of the primary
server, and regularly tries to contact the primary server, every minute
or something. (Or it uses a different method to detect when the primary
server needs the key).
The contact-tries are done over the routed network, and the routers must
be somewhat secured, and the links in between also have to be trusted.
When the secondary server succeeds the connection to the primary server,
 it authenticates the connection to the primary server (with a key that
is stored in plaintext on the primary server, or perhaps generated from
the hardware configuration). If the authentication succeeds, the
secondary server sends the private key to the primary server, and the
primary server can continue to boot normally.
If an attacker steals the server, and connects it at a different place
in the network, or somewhere else, then the secondary server will not be
able to reach the IP address due to the routing, and won't be able to
provide the key. So the attacker could only try to break in again, and
trace back where the server is, where it comes from, ...

Due to the connection originating from the secondary server and not from
the primary server, you have to have both the server, and you have to be
on the right place of the network.

It's not perfect security, but I think it's a reasonable tradeoff for
the given threats and the need for high-availability in those certain
situations.

Please let me know if you hear about any other interesting solutions too.

Best regards,
Philipp Gühring

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com