- Previous message: david raistrick: "Emerg data recovery recommdnations?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
|
|
|
From: Christian (no email)
Date: Mon Jun 02 2008 - 07:47:56 EDT
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 <> 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:]
> > Sent: Thursday, May 29, 2008 11:10 AM
> > To: Fred Reimer
> > Cc: Jared Mauch;
> > 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
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.9 (NetBSD)
> >
> > iD8DBQFIPsdRq/KRbT0KwbwRAkcmAJ4xOBtANHOc+C/fzL+7PvgWnjp76ACfSGUw
> > 43+1Pq3xWS4MagWzdetZ0ws=
> > =62gJ
> > -----END PGP SIGNATURE-----
>
|
|
|