here's the slides if anyone hasn't seen http://seclists.org/fulldisclosure/2008/May/att-0668/EuSecWest_presentation_ppt
On Thu, May 29, 2008 at 11:27 AM, Fred Reimer <[EMAIL PROTECTED]> wrote: > 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:[EMAIL PROTECTED] > > 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 > > [EMAIL PROTECTED] > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.9 (NetBSD) > > > > iD8DBQFIPsdRq/KRbT0KwbwRAkcmAJ4xOBtANHOc+C/fzL+7PvgWnjp76ACfSGUw > > 43+1Pq3xWS4MagWzdetZ0ws= > > =62gJ > > -----END PGP SIGNATURE----- >