New keys, to be stored on the crypto chip, would presumably be delivered in a separately signed package using a master key that would not change (embedded within the chip). Maybe Cisco even doesn't have this key, and would need to send a revocation or new public key to be stored on the chip to the chip manufacturer, who would sign it with the master private key and which then could be delivered in a software update to the system. There are many possibilities, and no crypto scheme is foolproof. That much has been proven. But no, you would not make the on-chip EEPROM of the crypto chip "flashable" in the normal meaning of the word. You would send the chip a pointer to a buffer that contains a signed update key, and the chip itself would verify that signature and only then program the updated key(s). My intention was not to turn nanog into a crypto forum. I'd be much more interested in any unique methods that people use to harden their systems that have not already been widely distributed through vendor or industry best practices. Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS Senior Network Engineer Coleman Technologies, Inc. 954-298-1697
-----Original Message----- From: Jim Wise [mailto:jwise@draga.com] Sent: Thursday, May 29, 2008 11:10 AM To: Fred Reimer Cc: Jared Mauch; nanog@nanog.org Subject: RE: IOS Rookit: the sky isn't falling (yet)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 29 May 2008, Fred Reimer wrote:
The code would presumably be run upon boot from a non-flashable source, which would run the boot ROM code through a check on the crypto chip and only execute it if it passed. You would not put the code that checks the boot ROM on the boot ROM. The new crypto chip would presumably have the initial boot code, which would only be designed to check the boot ROM signature and nothing else so presumably would never need to be replaced and hence would be designed to be non-flashable.
Doesn't this just push the chicken-and-egg problem up the chain one step? The ROMMON would be flashable (among other reasons) because the key used to sign IOS releases should change over the years -- gaining length as cycles get cheaper, being replaced periodically to prevent use of the same key for too long, and perhaps being revoked if it should ever be compromised.
If the ROMMON is itself to be verified by a prior, non-flashable ROM, then all the same arguments would call for making its key-list updatable -- and given the time-in-service seen by many such devices, any weakness in that key list would be around for quite some time.
- -- Jim Wise jwise@draga.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (NetBSD)
iD8DBQFIPsdRq/KRbT0KwbwRAkcmAJ4xOBtANHOc+C/fzL+7PvgWnjp76ACfSGUw 43+1Pq3xWS4MagWzdetZ0ws= =62gJ -----END PGP SIGNATURE-----