Conference smurf::dec_mls_plus

    The hardware User's Guide or SRM (Service Reference Manual) should
    describe how to reset the console password if you forget it.  The
    method for doing so was not standardized in the various models of Alpha
    in the past.  (It may be in the future.)
    
    I am not familiar with that model's method.  In any case, I believe
    that a general rule is the case: the password is stored in the NVRAM,
    so if you clear the password, you are clearing the NVRAM, which means
    all the other environment variables as well.  Unless the perp who
    cleared the NVRAM resets all the values to their values before he/she
    cleared the NVRAM, the system will not boot (no definition for
    bootdef_dev).  
    
    But that might be easily defeated, depending on how the NVRAM was 
    implemented in that model Alpha.  If the NVRAM has on-chip battery 
    backup, the perp could pop out the NVRAM, put in a blank NVRAM chip,
    boot up, load firmware, shutdown, replace old NVRAM chip.  And even 
    the password will have been restored.
    
    Having the OS do something to verify that the correct firmware is
    loaded is no help for this problem.  The reason is if someone has
    opened the box to reload the firmware, he/she could just as well
    change some other characteristic of the hardware that would defeat an
    OS check of the firmware.  Admittedly it's more work, but it is still
    a possibility, and the NCSC counts it.
    
    For example, suppose you used a variant of a method discussed with the
    NCSC in the past as a possible implementation for Trusted Distribution
    at an A1 level of trust:  design the hardware and firmware so that it 
    enables the booted operating system to read the firmware and create a 
    new signature (MD5 or better type checksum) and compare it with one 
    previously loaded by an ISSO, who received it via a "separate path" 
    (e.g., phone call, U.S. Mail, whatever).
    
    Even if you implement this, you still have the issue of physical
    hardware security.  If the perp can open the box to reload the
    firmware, he/she could in theory modify the hardware/firmware interface
    to the OS so that the signature program generates a false signature.
    
    Therefore even if you have the OS go to all that trouble, you still
    need physical box security.
    
    In the past the NCSC has approved physical security methods for CMWs,
    either a lock cage using a govt. approved tamper-resistant lock, or
    simply govt. issued tamper-detective tape.  Can order from the catalog.
    
    All you do is put in your operator's start-up procedure a check of the
    seal.  (And if the seal is broken, call 1-800-digital to order a new
    box :-).
    
    Right now, if you want to increase your level of assurance, then here
    are some suggestions of things you can do that won't cost an arm and a
    leg:
    
    o	Use a tamper-detective seal at a minimum; or a lock-box with
    	a tamper-resistant lock.
    
    o	Include in your operator's start-up procedure a reload of the
    	firmware from CDROM brought on site.  Note that this is insufficient 
    	in itself for the same reason having the operating system on boot 
    	verify a checksum or signature for the firmware: if the perp 
    	compromised the hardware, he/she could have compromised the firmware 
    	loading mechanism, etc.  You still need the tamper-detection or 
    	resistant seals.
    
    o	Include in your operator's start-up procedure a sanity check for
    	the firmware rev and other environment variables.  Note that you
    	can define your own environment variables.  If someone opens up the
    	box to clear the NVRAM and he/she doesn't have a blank NVRAM to switch
    	in and out, or the NVRAM is the type that does not have on-board 
        battery backup, you are at least checking to see that the old NVRAM is 
    	there. If it isn't you know something is wrong. 
    
    o	Add your own init script to the OS startup procedure to compare the 
    	firmware rev with an expected firmware rev. The firmware rev is 
    	reported in the syslog during boot.  If you do not get a match, you 
    	can shutdown or notify an ISSO.  This will prevent an accidental boot 
    	of the wrong firmware, but it won't protect you from someone who
    	maliciously changes the firmware (presumably he/she is clever
    	enough to keep the rev the same as the expected one).
    

    I once worked in an environment (no names please :) where we had a
    system that secure: program burned into PROM, checksum done at init-
    ialization and compared to known value (both by the program, to a
    checksum added by the prom-burning program, and by the operator), 
    tamper-detecting seals on all the joints, and key pieces inside a
    tamper-proof container.  All the seals were regularly audited by
    Those Who Audit.
    
    We once had to replace a bad component shortly before an operation.
    Found that a heat gun would nicely remove a tamper-resistant seal
    so that it could be replaced with no noticeable effect.  (Note:
    this was a *long* time ago, and perhaps the tamper-resistant technology
    has improved.)
    
    Martin        

    Was that before cyanide in the Tylenol or after???
    
    Since I believe that it is the government that publishes the catalog of
    such devices, presumably the government that buys from that catalog has
    determined the government's level of trust for the thing to which it
    will be applied, and will select from the catalog appropriately.
    
    whew.
    And for this we pay them taxes.

From:	ALPHA::majeske "Ann Majeske USG  21-Apr-1997 1105" 21-APR-1997 11:11:02.62
To:	19.807::bat (Segui la tua beatitudine)
CC:	majeske@DEC:.zko.alpha
Subj:	Re: Notefile DEC_MLS_PLUS Note 483.0 

BAT,

[ excerpted: ]

One other thing about console firmware and the console password.  Up
until recently, the console firmware for alpha boxes was not standardized
across the alpha platforms and firmware revisions.  Some boxes had the 
16 (not 15) digit hex console password (unencrypted), some instituted a 
"real" (ascii) password (encrypted) somewhere along the way, and some had 
no password at all.  With version 4.0 of the firmware CD (to be released 
this June), all of the workstation boxes (with the exception of the Jensen 
and bird machines) will have common "real" password support. The Jensen 
and bird machines will continue to have the 16 digit hex console password 
until or unless we can convince the firmware group to release a new 
version of firmware (with the  associated Qual cycles, etc) for these 
"past end of life" systems.  With version 4.1 of the firmware CD (to be 
released this September), all of the server boxes (with the exception of 
the high end machines - Ruby, Laser and TLaser - which have a physical key 
to lock the console) will also have this common "real" password support.  
(Gee, I guess things haven't changed as much as I thought!)

I don't know where the AXPvme100s fit into the above scenario.

Ann
    

    re .3 --
    
    It was long before the Cyanide/Tylenol incidents.

    Interesting side note (at least to me).  Phil Becker asked if they
    could load their firmware from their system disk, because he does not
    think the customer has a CDROM on their config.  Lee said that we load
    our firmware using MOP, but only ULTRIX systems support the mop_mom, so
    we are loading our firmware from an ULTRIX server.

From:	AIMHI::OFFEN        "SANDI OFFEN" <TELESALES REPRESENTATIVE ext 7042>" 24-APR-1997 09:58:07.03
To:	SMURF::BAT
CC:	US2RMC::"offen@mail.dec.com",OFFEN
Subj:	INFO ON NOTES FILE: DEC_MLS_PLUS

Hello,

This is Sandi Offen of the Digital Federal TeleCoverage Group in Littleton, MA.
I need your help.  You sent information to a Bill Triplett of the Naval Air
Warfare Center in Patuxent River.  I am trying to track down the rest of the
information so that I can help this customer.

	He sent a question (on the internet, I guess) and it got entered in
	the DEC_MLS_PLUS notes file.  The compelete string is as follows:
	DISK$NOTES:[NOTES$LIBRARY]DEC_MLS_PLUS.NOTE.1.  His note request is
	note #483.0 and your reply was note 483.1.

How can I get into that note and possibly get more information.  You had 
referenced a Service Reference Manual for his AXP.VME 100 and I need the
part number of that manual.  

Any help you can give me would be greatly appreciated,

Sandi Offen
Digital Fed'l TeleCoverage Specialist
800-277-8988 x 4632
    

From:	SMURF::BAT          "Barbara A. Thomson ZKO3-2/X46 1-2955" 24-APR-1997 13:18:56.46
To:	AIMHI::OFFEN
CC:	BAT
Subj:	RE: INFO ON NOTES FILE: DEC_MLS_PLUS


	If you have a web server available to you, you can get into
	the notesfile.  If you have an account on a VMS system, you
	can just use notes.

	I have no idea what the part number of the AXPvme100 user's
	guide or SRM is.  If you can get into VTX IR, there is an
	option there for Hardware Documentation.

	From VMS:

	$ notes
	NOTES> add ent smurf::dec_mls_plus

	From the Web:

	http://www-notes.lkg.dec.com/smurf/dec_mls_plus

	I don't remember the VTX IR thing and don't have time right
	now to look into it.  I forwarded your inquiry to the 
	people I know who are or were involved in the marketing
	of this product to that project/customer.  The customer
	should really be getting that documentation, or should
	have gotten that documentation, when he bought the system;
	or if not then, from his salesman?  Or is that not the
	we way do business anymore?  You guys have a tough job,
	if you get called upon to find out anything and everything...
    

Date: Wed, 30 Apr 1997 16:34:56 -0400
From: "Anthony Fiore" <tfiore>
Message-Id: <9704302034.AA10460@alpha.zk3.dec.com>
To: thomson
Subject: Tom Endyke EXTENSION is 4631
Cc: meg


Tom Endyke called regarding a US NAVY request.

He called Jim Barron who gave him my name.

They were looking for documentation on "locking the console". They
are running the single board alpha.

Can you call Tom at DTN 227-3777

Thank you,
Tony

    I am guessing that this inquiry is related to, and may be originating
    from, the same people who called last week from Patuxent River, also
    looking for the Alpha AXPvme100 hardware documentation (user's guide?)
    that tells one how to set the console password.  Why they call
    1-800-digital to get these manuals, I do not know.
    
    At any rate, since the last time I got a similar call, I believe that
    the AXPvme100 these people are using may not even have the console
    password, but I'm not sure. 
    
    I left voicemail with Tom Endyke suggesting that he call Chris Heiter,
    because Chris might know which model hardware manual they should order
    that applies to the hardware on which they are running.
    
    I looked in vtx los (literature order system), and got no hits on any
    variant of AXPVME 60/100 whatever, so I have no idea where to get the
    hardware doc.
    
    Finally, I also left voicemail with Tom Endyke, and I will try and get
    from him the name of the person who maintains the contact list in the
    Littleton database and see if I can have that corrected (1: Jim
    Barron is no longer the software documentation contact for MLS+ [ we
    don't have one ] and B: this was not a software documentation
    question.)