RE: IOS Rookit: the sky isn't falling (yet)

["Fred Reimer" <freimer () ctiusa com>]

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-----

Attachment: smime.p7s
Description: