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 majord...@metzdowd.com