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

Mon Jun 2 11:47:56 UTC 2008

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 <freimer at ctiusa.com> 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:jwise at draga.com]
> > Sent: Thursday, May 29, 2008 11:10 AM
> > To: Fred Reimer
> > Cc: Jared Mauch; nanog at 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 at draga.com
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.9 (NetBSD)
> >
> > iD8DBQFIPsdRq/KRbT0KwbwRAkcmAJ4xOBtANHOc+C/fzL+7PvgWnjp76ACfSGUw
> > 43+1Pq3xWS4MagWzdetZ0ws=
> > =62gJ
> > -----END PGP SIGNATURE-----
>