Conference 7.286::fddi

    If you have control of the physical box then it is simple enough to set
    the management sets allowed switch to off which prevents anyone from
    being able to load an image into the box.  This implies that the box
    itself is secure.
    
    The most reliable way to insure that flash has been erased is to load
    a new image into the box.  If one were to reload the
    bridge/concentrator firmware after each time the area was reclassified
    then you would be all set.  The first thing that the box does when it
    loads a new image is erase all flash.  The erase of the flash parts is
    verified.  The main drawback to this is that the parts will wear out
    more quickly.
    
    Scott

   Even though it wouldn't cause concern for my particular application, I
   gather from the docs that the software password switch in a set/load
   sequence could override the physical setting of the "management set enable
   switch" on the device.  Now, if the password is only 16 bits, this wouldn't
   be considered too robust I'm afraid.   I recall in some older gear that the
   MOP password was 32 bits, but that the upper 16 bits had to be a copy of
   the lower 16.  This obviously is as easy to guess as 16 bits.  It wouldn't
   take a persistent algorithm to long to go through the 64k permutations.

   How many times can flash memory be written?  Does DEC have a support policy
   for devices that are returned with the flash devices obviously worn out
   from too many writes?  Worst case, We're talking doing a write 2x/day for
   my application.  If these things can be written >10,000 times, then I
   believe we're up into the moot category.

   Would it be remotely possible ($) for engineering to provide & support
   devices with non-writeable rom for secure environments?

 

    The software switch CAN NOT override the hardware switch!  Yes the
    password is only 16 bits.  You may be confused by the fact that there
    are two phases of protection.  There is a physical Management Sets
    Allowed sitch per port and there is a software Downline Load Enable
    switch.  The Downline Load Enable switch can be set to enable downline
    load if you have the password and you have the physical Management Sets
    Allowed switch in the enabled position.  No sets or downline loads can
    be performed when the physical switch is set to disabled.
    
    The lifetime for flash is somewhere in the 10,000 writes category.
    
    No the FLASH cannot be replaced with ROM at least not very easily.  Of
    course any thing can be done by waveing enough dollars under the right
    nose.
    
    Scott
    

   Thanks for the clarification.  That makes sense now.  I still would
   appreciate clarification on the password length.  The DECndu doc says in
   section 3.1, "Prerequisites for Upgrading Bridges and Concentrators":

     "The password cannot be greater than 16 characters. "

   The ELMS user guide states in section 2.1.1:

     "The password must be 6 to 12 characters long. It can contain any
     letters or digits from the ISO Latin-1 character set, underscores
     (_), or hyphens (-)."

   I assume that even though Elms and ndu are performing different functions,
   that the password mechanism used is the same.  In both cases, ascii
   characters are specified which would provide far more permutations than 16
   bits would.  I'm interested in a confirmation that we're talking characters
   here, not bits, and what is the actual password max/min length for both the
   DECbridge 5xx/6xx and the DECconcentrator 500. The ndu doc says "no greater
   than 16", and the Elms doc says "must be 6 to 12".

   Also, the mechanism appears to be a bit different for the FDDIcontroller
   400 depending on whether the device is a VAX 6000 or a 9000.  The ndu doc
   in section 3.4.1 says:

     "Be sure that the system control panel switch on the VAX 6000 is in
     the update position *or* the software switch for updating on the VAX
     9000 has been set before you upgrade the DEC FDDIcontroller 400."

   Does the "or" here indicate that the VAX 9000 upgrade switch can be
   effectively set via either a hardware switch on the FDDIcontroller 400
   distribution panel or the console soft switch? Or must the VAX 9000 update
   switch be accessed via the software console switch?  Is the FDDIcontroller
   update switch simply a read register for the device driver or is it read by
   the firmware in the FDDIcontroller to implement the upgrade procedure?

   Thanks

   Jim Timmerman

    Password is 16 bytes case in-sensitive.
    
    Can't answer about the DEFZA

What was the question?

	paul

I accidentally nuked the base entry.  Brian Williams tried to rewrite it, but a 
pecularity of the version wouldn't let him, ...so here's the origional.


   I have a customer who is planning to use our FDDI componenets in a gov't
   secure environment where they have to routinely declassify the environment.
   For workstations, they have to have removeable media or scribble on the
   media until it can't be recovered etc.  Since the concentrators (and
   controllers ? ) have flash memory in them, the security people are
   wondering what the options are to assure the gov't that this memory can't
   be a source of a security problem when it needs to be declassified.  The
   particular concern is whether it is possible for a person knowledgeable of
   the internal architecture of the concentrator and other FDDI devices to say
   the right MOP things to push his own code or any image for that matter into
   the flash memory.  I assume that this would be extremely difficult (?), but
   the real question is whether this function can be reliably disabled or not.
   I am looking for a mechanism that would assure the gov't that it can't be
   done.  The DECndu documentation implies that a person with a particular
   device's password can override the physical write protect switch to enable
   loading the new sofware.  This actually would meet the requirement here if
   I understand correctly that this physical switch and the password are the
   only mechanisms that could possibly allow writing of the flash memory.

   I'd appreciate the following info:

   o Is above understanding true of how all of our FDDI devices could be
   protected?  I.e., user must have password or physical access to the device
   in order to modify flash memory?

   o How long can the passwords be for each device?  Are they HEX only ?

   o Is there a way to erase flash memory reliably?  Does the factory reset
   function accomplish this?

   Thanks

Thanks.

Sounds like the bottom line is that you protect the Flash memory with a
physical switch.  Given that, you don't have to erase it since it wouldn't
be written in the first place.  In such environments, the way to upgrade
is either to remove the box in question and upgrade it on a dedicated
(presumably tiny) network, or to kick off all untrusted nodes from the 
main network and then perform the upgrade.

	paul

   Thanks Paul and Scott for being so responsive.  The project people at
   Boeing are very satisfied with the FDDI products so far.  This account is
   refreshing to work with as they still think Vaxes are great machines and
   are writing their technology plans out of our catalogue.

   Their security people are doing their homework...  They would like to know
   which nonvolatile storage technologies we are using in each FDDI product.
   At the risk of wearing out my welcome, I hope we don't have a problem with
   giving them this info.  If possible, I'd like the below info for each of:

   DECconcentrator 500
   DECbridge 5/600
   FDDIcontroller 400
   FDDIcontroller 700 ( does it use nvram? )

   1. Nonvolatile Chip Industry Part# & Vendor #
   2. Description of Technology (i.e., EE or Flash)
   3. Used for in implementation 
        (i.e., Stores Filtering Address, op params, or o/s etc.)
   4. Method available to end user to insure complete erasure
        (i.e., any init clears all, or download algorithm erases & verifies
        erasure etc.)

   Thanks,

   Jim Timmerman