The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: Rutgers 'Security List' (incl. misc.security) - Archives (1990)
DOCUMENT: Rutgers 'Security List' for June 1990 (58 messages, 35024 bytes)
SOURCE: http://securitydigest.org/exec/display?f=rutgers/archive/1990/06.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 04:30:21 GMT
From:      annala@NEURO.USC.EDU (A J Annala)
To:        misc.security
Subject:   Re: Security and Masterkeys

> Has anyone, as an exercise, tried to make a very highly protected area?

Yes, we put the crypto equipment in a large double steel door enclosed
steel box suspended on huge shock absorbers and placed a double 24 hour
marine guard with automatic weapons at the entrance with shoot to kill
and ask questions later orders.  To my knowledge no unauthorized people
ever even tried to get into the crypto vault.

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Mon,  4 Jun 90 18:29:47 EDT
From:      wcs@erebus.att.com (William Clare Stewart)
To:        security@rutgers.edu
Subject:   Re: abolishing /etc/passwd
	/etc/passwd has become the traditional location for user-info
	other than passwords, so of course it needs to be kept,
	but I agree with the shadow-password approach that puts 
	(encrypted) passwords in a non-world-readable file.

	Yes, this means that YOUR software can't use the real
	password, but this is good - I'm not going to trust my real
	password to non-system software, because of the increased
	risk of trojan horses and insecurity; terminal-lockers and such
	get their own passwords.

]If DES is breakable, then a new algorithm needs to be implemented. And
]users should be encouraged to choose good passwords, otherwise it
]doesn't matter what encryption mechanism is used.

	The point of the modified-DES used by UNIX is that it isn't
	the same as the real DES, so a real-DES breaker won't work,
	and a fast hardware implementation of real-DES will make it
	hard to search for obvious passwords.  Unfortunately, though,
	people have gotten 10-fold speedups in password encryption
	through software, and hardware is 1-2 orders of magnitude
	faster than the old PDP-11 days (much more, if you have a
	network of machines to bum cycles off of).
	So DES isn't real secure enough either, given readable passwords.
-- 
				Thanks;  Bill
# Bill Stewart AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 erebus.att.com!wcs
# Actually, it's *two* drummers, and we're not marching, we're *dancing*.
# But that's the general idea.

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 22:29:47 GMT
From:      wcs@erebus.att.com (William Clare Stewart)
To:        misc.security
Subject:   Re: abolishing /etc/passwd


	/etc/passwd has become the traditional location for user-info
	other than passwords, so of course it needs to be kept,
	but I agree with the shadow-password approach that puts 
	(encrypted) passwords in a non-world-readable file.

	Yes, this means that YOUR software can't use the real
	password, but this is good - I'm not going to trust my real
	password to non-system software, because of the increased
	risk of trojan horses and insecurity; terminal-lockers and such
	get their own passwords.

]If DES is breakable, then a new algorithm needs to be implemented. And
]users should be encouraged to choose good passwords, otherwise it
]doesn't matter what encryption mechanism is used.

	The point of the modified-DES used by UNIX is that it isn't
	the same as the real DES, so a real-DES breaker won't work,
	and a fast hardware implementation of real-DES will make it
	hard to search for obvious passwords.  Unfortunately, though,
	people have gotten 10-fold speedups in password encryption
	through software, and hardware is 1-2 orders of magnitude
	faster than the old PDP-11 days (much more, if you have a
	network of machines to bum cycles off of).
	So DES isn't real secure enough either, given readable passwords.
-- 
				Thanks;  Bill
# Bill Stewart AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 erebus.att.com!wcs
# Actually, it's *two* drummers, and we're not marching, we're *dancing*.
# But that's the general idea.

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Tue, 05 Jun 90 16:51 CDT
From:      UCCXNCS@osucc.bitnet
To:        security@ohstvma.bitnet
Subject:   Expiring passwords
I was interested in the message about users who deliberately
changed their password several times so they could use
the same password again.  Here at Oklahoma State we have
met with a lot of resistance from faculty who do not even
like the idea of having their passwords expire, much less
not being able to use the same one again.  They seem to
think that having to change their passwords periodically
restricts their academic freedom or something.  I wonder
if any other computing centers out there have the same
problem, and if you do, how do you handle it?
    Nancy Stevens - Oklahoma State University

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 21:51:00 GMT
From:      UCCXNCS@osucc.BITNET
To:        misc.security
Subject:   Expiring passwords

I was interested in the message about users who deliberately
changed their password several times so they could use
the same password again.  Here at Oklahoma State we have
met with a lot of resistance from faculty who do not even
like the idea of having their passwords expire, much less
not being able to use the same one again.  They seem to
think that having to change their passwords periodically
restricts their academic freedom or something.  I wonder
if any other computing centers out there have the same
problem, and if you do, how do you handle it?
    Nancy Stevens - Oklahoma State University

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 08:54:09 GMT
From:      annala@NEURO.USC.EDU (A J Annala)
To:        misc.security
Subject:   Re: Opening a safe by manipulation

> (And Group I R are also proof against radiological attack - i.e., they have
> plastic wheels so they can't be X-rayed.)

Maybe they can't be x-rayed ... but they can be attacked with fast neutron
activation analysis, magnetic resonance imaging, etc ... don't assume you
can't image the tumblers because they can't be x-rayed ... of course, most
spy types would rather compromise someone with access to a safe rather than
try to get into the safe themselves.

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jun 90 22:27 PDT
From:      "Ned Freed, Postmaster" <NED@hmcvax.claremont.edu>
To:        security@pyrite.rutgers.edu, blount@media-lab.media.mit.edu
Subject:   Re: a new scam
It's been done before, pretty much as you described. The article I saw was
on the RISKS Digest some time back. It may have also appeared in this
newsgroup as well.

Some details:

(1) The fake machine was built in front of the real one, which if done
    in an inobvious manner insures a lot of "clientele" - the regular users.

(2) I believe the machine swallowed the cards completely, saying that it
    was confiscating them or some such. This saves the trouble of getting
    a card reader operational.

I don't recollect where this occurred. I don't keep such details handy.
It wasn't here in Claremont, CA -- I would have remembered *that*.

All in all, given the limit on the amount of cash dispensed per card, it
does not sound like a very effective scam. Better to rip off/out the whole
machine, as some have done. My recollection is that the amount reported
stolen was large enough to make it cost-effective but not stunningly so.

An interesting question -- is this sort of thing a white or blue collar
type of crime? I recently heard a statistic comparing the amount stolen
in your basic blue collar bank robbery (peanuts), white collar robbery
(i.e. fraud, in the millions), the chances of getting caught (blue collar
quite high, white collar quite low), and the penalties if caught (blue collar
quite severe, white collar quite lenient). In view of the active nature of
such a crime, it comes across like a stickup. But it is quite clever...
like a clever scheme for fraud. Thoughts?

				Ned Freed
				Innosoft International, Inc.

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Thu, 07 Jun 90 10:09:27 -0500
From:      nugent@gargoyle.uchicago.edu
To:        misc-security@uunet.uu.net
Cc:        strick@osc.com (HAR56)
Subject:   Re: Best Locks
One University I attended had the policy that the master key was
always the deepest key cut.  If you took apart a multi-keyed cylinder
and made a key with the deepest of all the possible cuts, you reliably
ended up with a grand-master key for the building or even group of
buildings!  It made collecting the "complete master key collection"
rather easy--just one cylinder to take apart  per building.

On a recent visit I noticed they had rekeyed with Medeco Bi-axial locks, but
I'm afraid I didn't have the time to see if they had learned any lessons 
about keying plans. 

Todd

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 05:27:00 GMT
From:      NED@HMCVAX.CLAREMONT.EDU ("Ned Freed, Postmaster")
To:        misc.security
Subject:   Re: a new scam

It's been done before, pretty much as you described. The article I saw was
on the RISKS Digest some time back. It may have also appeared in this
newsgroup as well.

Some details:

(1) The fake machine was built in front of the real one, which if done
    in an inobvious manner insures a lot of "clientele" - the regular users.

(2) I believe the machine swallowed the cards completely, saying that it
    was confiscating them or some such. This saves the trouble of getting
    a card reader operational.

I don't recollect where this occurred. I don't keep such details handy.
It wasn't here in Claremont, CA -- I would have remembered *that*.

All in all, given the limit on the amount of cash dispensed per card, it
does not sound like a very effective scam. Better to rip off/out the whole
machine, as some have done. My recollection is that the amount reported
stolen was large enough to make it cost-effective but not stunningly so.

An interesting question -- is this sort of thing a white or blue collar
type of crime? I recently heard a statistic comparing the amount stolen
in your basic blue collar bank robbery (peanuts), white collar robbery
(i.e. fraud, in the millions), the chances of getting caught (blue collar
quite high, white collar quite low), and the penalties if caught (blue collar
quite severe, white collar quite lenient). In view of the active nature of
such a crime, it comes across like a stickup. But it is quite clever...
like a clever scheme for fraud. Thoughts?

				Ned Freed
				Innosoft International, Inc.

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Thu,  7 Jun 90 11:02:31 EDT
From:      shz@packard.att.com (Seth Zirin)
To:        security@rutgers.edu
Subject:   Re: Opening a safe by manipulation
Group II locks offer no intentional protection against manipulation, but
wheel shadowing, sticky flies, etc can prevent successful manipulation.

Group I locks can also be manipulated in an infinite period of time but
cannot be manipulated within 20 hours, which makes them group I.

Group 1R locks meet Group I guidlines and are additionally immune to
radiological attack.

Seth Zirin

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 13:11:00
From:      jpc@fctunl.rccn.pt (Jose Pina Coelho)
To:        security@rutgers.edu
Subject:   Re: a new scam
It has been made.
The pseudo ATM was in a box in front of the real one.

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 09:48:12 GMT
From:      zimmerma@lan.informatik.tu-muenchen.de (Kai Werner Zimmermann)
To:        misc.security
Subject:   Re: a new scam

This has been done here in Germany more than 2 years ago.
In Germany most of those card machines stand inside the entrance
halls of the banks. To enter the hall you have to put your card into
a reader slot but NOT to type your password, e.g. every card owner
may enter.
The thieves placed their card reader in a plastic box which they simply
fixed in front of the entrance card slot and asked the people
via an LCD display to enter their password.

--
===============================================================================
|Kai Zimmermann                    zimmerma@lan.informatik.tu-muenchen.dbp.de |
|                Hold fast to your dreams, for if dreams die,                 |
---------------- life is a broken winged bird that cannot fly. ----------------

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 15:09:27 GMT
From:      nugent@GARGOYLE.UCHICAGO.EDU
To:        misc.security
Subject:   Re: Best Locks

One University I attended had the policy that the master key was
always the deepest key cut.  If you took apart a multi-keyed cylinder
and made a key with the deepest of all the possible cuts, you reliably
ended up with a grand-master key for the building or even group of
buildings!  It made collecting the "complete master key collection"
rather easy--just one cylinder to take apart  per building.

On a recent visit I noticed they had rekeyed with Medeco Bi-axial locks, but
I'm afraid I didn't have the time to see if they had learned any lessons 
about keying plans. 

Todd

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 16:29:04 GMT
From:      jslove@starch.enet.dec.com ("J. Spencer Love; 508-841-2751; SHR1-3/E29  07-Jun-1990 1229")
To:        misc.security
Subject:   Re: Best Locks

I remember hacking Best locks in high school, say about 17 years ago (now it 
can be told).  There are a lot more than 250 possible combinations.

We had "A" blanks, 6-pin tumblers, and a keying system called "X".  Each pin 
could be cut at at either the odd or even 5 of 10 possible levels.  With one 
level reserved for the master cut, that left 4 cuts/pin for pass keys.  That 
means there were 4,096 possible pass keys.

The locks were zoned into 64 groups of 64, with the school apparently having 
only licensed the first 8 zones.  The 3 shallowest cuts (neat the handle end 
of the key) varied within a zone.  Different zones were lettered A-H, and 
assigned to different departments within the school -- something like A for 
upper school, B for offices, C for the kitchen, D for boarding student's 
rooms, E for maintenance and grounds, F for the middle school, G for the gym, 
and H for the lower school.  (These are probably scrambled -- it's been a long 
time.)

The keys were stamped with codes ranging from XA1 to XH64.  The codes were in 
simple base-4 correspondence to the cuts, starting from the first cut 
modularly above the master cut as zero.  It was only necessary to measure 3 
keys with a microcaliper to solve the whole system except for the control key.
We made a pretty good guess at the control key (one of 2 patterns).

They stamped these numbers on the locks, too.  Since they really wanted to 
label everything, it's really too bad they didn't use a random codebook.  (We 
made friends with the locksmith later and he used a codebook, not the math.)

The "X" corresponded to the pattern of evens and odds of the individual pins.  
I suppose in theory that 64 different patterns could have been given out, but 
any pattern that had only one (or even two) differences of even/oddness had 
better be on a different blank (or 1000+ miles away) or there would be too 
much chance of interchangability of keys.

The other basis I have for thinking that they only licensed part of "X" is 
that their grand master key had a passkey cut for the deepest pin.  This would 
only open 1/4 of the possible X locks (twice as many as they actually used).

We got quite a rise out of the administration by showing them just how easy it 
had been to solve their key system, and describing the real grand master (not 
the one they had) without ever having seen it.  The two of us who confronted 
them were threatened with instant expulsion if we were ever caught USING such 
knowledge; we didn't tell them about the others...

I think they had the cheapest available system, or maybe it was just bought 
early in Best's career.  The cores had those convenient holes for picking the 
core sleeve.  The pins had little (removable!) press in caps over the springs, 
so we could pick and remove a core, disassemble it and measure the pins, and 
reassemble and replace it, unharmed.  Took about an hour, but we were 
amateurs.  There were mushroom pins in some of the cores.  The locks, by the 
way, had a master key cut for the deepest pin, even though the school didn't 
use it.  (Maybe the police or Best co?)

There were competing groups of students who stole padlocks and disassembled 
them to figure out the system.  There must have been 3 separate successful 
masterkey projects in my class alone (I knew of 2, counting my own, and had 
evidence of another.  There might have been more, but with a graduating class 
of 59, I doubt it).  Someone let themselves into the locksmith's shop and 
stole the key machine the next year; very crude, they should have used it on 
the premises so no one would have suspected.

Best locks are convenient, but only elementary schools should dare to use 
them.  RPI used them also; when I went to check the place out senior year, 
practically the first thing I noticed was in the undergraduate handbook where 
it threatened instant expulsion to anyone who was caught with a master key.  
Might as well try to sweep back the tide.  I went to a college with a more 
relaxed attitude.

Speaking of common practice, key combinations are recycled.  Suppose that 
there are 40 doors and 64 possible keys.  If you "lose" your key, you pay a 
fine and get a new lock and key.  24 lost keys later, someone else will get a 
new copy of your "lost" key.  The loss rate is fairly low; the migration of 
students from room to room each year is much more likely to create 
unauthorized access.

						-- Spencer

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 20:23:32 GMT
From:      Doug Gwyn <gwyn@smoke.brl.mil>
To:        misc-security@rutgers.edu
Subject:   Re: Best Locks
It's pretty easy to figure.  There are two pinning schemes for Best
locks:  10 depths at 12.5 mil increments and 7 depths at something
like 18 mil increments.  The former is the most common; however, to
avoid using 12.5 mil pin sections, which tend to jam, the convention
is to use only every second depth for each pin in the 10-depth scheme.
Thus, pin columns can be labelled "even" or "odd", depending on which
of the two alternate sets of depths they use.  If you were to pin a
core with splits every 25 mils, with the bottom pin segment chosen as
a #0 or #1 length depending on whether the column is even or odd, the
core would open on any key in the system.  (This would make a good
universal substitute for replacing a core removed for study, since it
would open the lock for its intended keyholder -- as well as others
in the unlikely event that they were to try while the substitute is
in place.)  Anyway, the number of possible day key changes for the
10-depth scheme can therefore be no more than 5^7 = 78125, while for
the 7-depth scheme it is no more than 7^7 = 823543.  The actual
number is reduced by three considerations:  Some key bittings are too
insecure, for example all depths the same can be unlocked by a stiff
straight wire.  Some key bittings are infeasible (at least for some
lock brands, possibly not Best), for example the deepest depth adjacent
to the most shallow depth (the deep cut's slope overlaps the base of
the shallow one's).  And finally, to avoid accidental cross-keying,
the day keys cannot use the master-key depths.  This latter
consideration lowers the upper limit to 4^7 = 16384 and 6^7 = 279936,
respectively, for one level of masterkeying.  Since most campuses
use multiple levels of masterkeying (3 or 4 is typical), cross-keying
avoidance reduces the number of day key changes still further.  There
are probably no more than 2000 available; to go beyond that multiple
keyway sections are normally used.  Best offers several, in at least
two distinct families, with special blanks available for the masterkeys
to allow them to pass multiple keyway sections within the family.

>Is it common practice on campi to have two locks the same, assuming
>the residents will never notice?  Occasionally a group of people would
>all go down a hall trying locks, but we never found a double.

I've never encountered a masterkeying setup where duplicate day keys
for different access was considered acceptable practice, so I suspect
they're not using that at your campus either.

>p.s. are there any other HAR56's out there?

The "HAR" codes are specific to your campus.

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jun 90 12:38:11 -0600
From:      zeleznik@cs.utah.edu (Mike Zeleznik)
To:        security@pyrite.rutgers.edu
Subject:   Re: Internet Security
The only problem is that within an organization, a level of trustworthiness
may be assumed among users, and various other security controls may be
relaxed, based on this.  It helps in getting work done.

However, if one user makes the mistake of chosing a low level of security
for themselves (e.g., an easy password), many other users may be affected.

Of course, there are other ways they can leave themselves wide open (e.g.,
access modes on certain files), but at least we can try and stop the
ones we can.

Mike

  Michael Zeleznik              Computer Science Dept.
                                University of Utah
  zeleznik@cs.utah.edu          Salt Lake City, UT  84112
                                (801) 581-5617

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 03:02:01 GMT
From:      robert@anagld.analytics.com (Robert Gottlieb)
To:        misc-security@uunet.uu.net
Subject:   DES routine for VMS
I'm not sure if this is the right place to post this, so sorry if this
causes any trouble.  I am looking for some source C code for a DES
routine.  It isn't for me, so I don't know the details except that
it has to run on a VMS running 5.2 and SmartStar, a co-worker of mine
is looking for this.   Any replies would be greatly appreciated.
I'm looking for ftp'able stuff or email is fine too, or any other
suggested methods.  Thanks in advance.

/No fancy sig as of yet | Robert Gottlieb aka robert@analytics.com	/
/But look in this space | #include <stdisclaimer>			/
/For future fancy sig   | "I'd rather have a bottle in front of me.. "	/

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jun 90 08:57 +1200
From:      Simon Travaglia <CCC_SIMON@waikato.ac.nz>
To:        security@rutgers.edu
Subject:   Re: Opening a safe by manipulation
> All Group II safe locks, by definition, can be manipulated.  Group I locks,
> which are mostly sold to the government, are not susceptible to manipulation.

That's a pretty tall order - Not susceptable to manipulation.  It's probably
more accurate to say that
	It's not manipulatable in a short time with current common knowledge

Locks really only buy you time.  Although I agree with your comments about
group I locks (people will KNOW if you've been in), most new locks were
non-manipulatable until someone did it.  I would always leave the shadow of
doubt so that there isn't blind faith in a mechanism.

----------------------------------------------------------------------------
|    |       |     |       |       ___      spt@grace.waikato.ac.nz
|    |   of  |     | .^. o |/  .^.  +  .^.  SimonT, Computer Services,
|    |NI     |  |  | +-+ | |\  +-+  |  | |  University of Waikato,
 \__/         \_^_/  | | | | \ | |  |  `v'  New Zealand.  PSI 0530171000004
Disclaimer:  I didn't do it, I'm a helicopter!
----------------------------------------------------------------------------
When a man says, "Get thee behind me, Satan," he's probably ashamed to have
 even the devil see what he's up to.

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Fri,  8 Jun 90 16:04:48 EDT
From:      shz@packard.att.com (Seth Zirin)
To:        security@rutgers.edu
Subject:   Re: Best Locks
HAR56 is a blind code that would likely have no meaning within a different
master keying system.  The 'H' probably indicates the keyblank, 'A' the
grandmaster, 'R' the master under the 'A' GMK, and '56' the actual
change under the master.

A properly designed master keying system should arrange that HAR56 and HAR57
or HAR56 and HAS56 have no relationship that would allow someone to
calculate or guess other keys.

Whenever I set up a master keying system, I randomly select changes under
a master and randomly select masters under the GM, etc.

Seth Zirin, CPL

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 20:04:48 GMT
From:      shz@packard.att.com (Seth Zirin)
To:        misc.security
Subject:   Re: Best Locks

HAR56 is a blind code that would likely have no meaning within a different
master keying system.  The 'H' probably indicates the keyblank, 'A' the
grandmaster, 'R' the master under the 'A' GMK, and '56' the actual
change under the master.

A properly designed master keying system should arrange that HAR56 and HAR57
or HAR56 and HAS56 have no relationship that would allow someone to
calculate or guess other keys.

Whenever I set up a master keying system, I randomly select changes under
a master and randomly select masters under the GM, etc.

Seth Zirin, CPL

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jun 90 20:12 CST
From:      Ken Selvia x3547 <UCS_KAS@shsu.bitnet>
To:        security@tcsvm
Subject:   VideoCipher II
     I have asked this question on three other lists and no one (yet)
has been able to help.  I was referred to this list, so if you can
help please jump in.

     I would like to find out more about the encryption methods used with
home-satellite audio systems.  I know the signals are digitally encoded and
encrypted with the DES encryption algorithm.  This scheme (called
VideoCipher II) was designed by General Instruments.  I understand that a
variation of this has been released (VideoCipher II plus) which is more
secure.  A friend of mine has a set of replacement EPROM's in his
descrambler unit which allow him to receive all scrambled channels, once
given a valid key for one scrambled channel.  Apparently even one valid key
is not necessary for some reprogrammed EPROMs.  Can anyone tell me how this
works?  Does anyone have any information about the new VC2+ encryption
algorithms?  I have seen (and ordered from) adds for software which
explains and demonstrates VC2 encryption techniques.  Please send any
pointers or references.  I read that there are BBS's which might be
helpful, but the ones I have tried are no longer running.

[Moderator injection: they probably got busted for piracy or something...  _H*]

Kenneth Selvia             Internet : ucs_kas%shsu.decnet@utadnx.cc.utexas.edu
Programmer Analyst II          BITNET : UCS_KAS@SHSU.BITNET
Sam Houston State University
Huntsville, TX 77341                    [I have no opinions. I make no claims]

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 21:37:19 GMT
From:      OPSRJH@uccvma.BITNET (Richard Hintz)
To:        misc.security
Subject:   Authentication of electronic commercial documents

We are interested in technology for authenticating electronic
commercial documents, such as Purchase Orders.
Can someone provide some pointers to references on this?

Also, does it make sense to talk about using the RSA technology for
this purpose?  By the way, I'd like to get RSA's phone number,.
if someone has it handy.
  Richard Hintz  University of California  (415) 987-0437  opsrjh@uccvma

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jun 90 12:14:55 pdt
From:      ssc-vax!ssc-bee!maa@beaver.cs.washington.edu
To:        security@beaver.cs.washington.edu
Do you folks know anything about the upcomming UNIX security 
conference coming up in Portland this August? I need dates, places,
etc. Thanks

Mark Allyn
uw-beaver!ssc-vax!ssc-bee!maa

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 19:14:55 GMT
From:      maa@ssc-bee.UUCP
To:        misc.security
Subject:   (none)

Do you folks know anything about the upcomming UNIX security 
conference coming up in Portland this August? I need dates, places,
etc. Thanks

Mark Allyn
uw-beaver!ssc-vax!ssc-bee!maa

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jun 90 15:42:32 EST
From:      Don Irmiger <don@delta.com>
To:        SECURITY@ohstvma.ircc.ohio-state.edu (John Opalko, N7KBT)
Subject:   Re: RS-232 encryption boxes??
> destroy-before-reading, but it does have to make it difficult for
> eavesdroppers.

Call Black Box Corp.  See what they can offer you.

--
Donald K. Irmiger III                                 UUCP: uunet!delta.com!don
Data Systems Coordinator                          Internet: don@delta.com
Michiana Rehabilitation Institute's Data Systems Center \ Altos 2086/Xenix 3.4b

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 15:04:48 GMT
From:      vancleef@FS01.NAS.NASA.GOV (Robert E. Van Cleef)
To:        misc.security
Subject:   Re: Expired passwords...

Oh - Cute! That means YOU, or one of your staff, know all of the
passwords. What we did is:

1 - Make the password program reject dumb passwords.

2 - Run a fast password cracker against all of our systems to insure 
    the "root" hasn't given someone a dumb password.
	    
You are assuming that you and your staff will assign passwords that are
safe and memorable. My experience is that, under the pressure of
events, people will assign passwords to others that are as bad, or worse,
that those others would have picked for themselves.

Let your software do the work for you. 

Of course, you did say a "medium sized system". The problem with most
solutions that I have seen, to all Unix system administration problems,
are that they are not scalable. As systems grow, things break! Can you
safely say that your current procedures would work if your system
doubled in size or the number of users?

Bob 
__
Bob Van Cleef - vancleef@nas.nasa.gov

RNS Distributed Systems Team Leader
NASA Ames Research Center		(415) 604-4366
Mail Stop 258-6				 FTS  464-4366
Moffet Field, CA 94035-5000	    FAX (415) 604-4377
__
"If you're not a liberal at 20, you have no heart, and 
 if you're not a conservative at 40, you have no head."
 Winston Churchill

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jun 90 22:25:35 EDT
From:      simsong@next.cambridge.ma.us (Simson L. Garfinkel)
To:        netcom!onymouse@claris.com
Cc:        security@pyrite.rutgers.edu
Subject:   National Security Agency
   You cannot, as a plain old, lowly American citizen, get anything
   from the NSA.  All requests are declined.

This is patently not true.

You can, for instance, get a job from the NSA.  You can also get a job
interview, reimbursement for your travel expenses, and the like.

On a slightly more serious note, you can get papers that the NSA has
published.  The NSA has a research group which does non-classified
work and publishes papers, as well as presents them at various meetings.

You can get a bibliography from the NSA of all the books that have
been published about The Agency, both pro and con (they will even tell
you which are which.)

The NSA produces several pamphlets describing what they do.  One of
the things that you cannot get from the NSA is their budget.

I could go on.

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jun 90 10:06:49 EDT
From:      shz@packard.att.com (Seth Zirin)
To:        security@rutgers.edu
Subject:   Re: Security and Masterkeys
>In every
>case I am aware of the master key is the lowest key of all.

Sorry Leonard.  You must not be aware of any professionally designed
master keying systems that were set up according to common locksmithing
industry standards.

A properly selected master key must be impossible to create by filing
a change key.  That means it must contain at least one cut that is
taller than the corresponding cut in every change key.  The master
key should also have a wide assortment of cuts so that the master key
shear line in the lock (every lock) is difficult to pick.

If the master key was always the "lowest key of all", whatever that means,
it would be a very flat key or provide very few cut depths (and thus
key combinations) for the change keys.

Calculating the top level master key by measuring pins becomes increasingly
difficult as the number of levels (i.e., MK, GMK, GGMK, GGGMK, etc)
increases.  It is possible for a lock in a single level master-keying
system to have more pins than an idential lock in a four level system.

Seth Zirin, CPL

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 14:06:49 GMT
From:      shz@packard.att.com (Seth Zirin)
To:        misc.security
Subject:   Re: Security and Masterkeys

>In every
>case I am aware of the master key is the lowest key of all.

Sorry Leonard.  You must not be aware of any professionally designed
master keying systems that were set up according to common locksmithing
industry standards.

A properly selected master key must be impossible to create by filing
a change key.  That means it must contain at least one cut that is
taller than the corresponding cut in every change key.  The master
key should also have a wide assortment of cuts so that the master key
shear line in the lock (every lock) is difficult to pick.

If the master key was always the "lowest key of all", whatever that means,
it would be a very flat key or provide very few cut depths (and thus
key combinations) for the change keys.

Calculating the top level master key by measuring pins becomes increasingly
difficult as the number of levels (i.e., MK, GMK, GGMK, GGGMK, etc)
increases.  It is possible for a lock in a single level master-keying
system to have more pins than an idential lock in a four level system.

Seth Zirin, CPL

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 17:58:11 GMT
From:      6600tlee@ucsbuxa.ucsb.edu (Tennyson Lee)
To:        misc-security@ucsd.edu
Subject:   Re: RS-232 encryption boxes??
Here's a list of vendors that produce the cryptographic hardware
you're looking for:

Pailen-Johnson Associates (703) 442-9051
Products: LEAD, 9600bps, $500
	  Secureware, Jr., 9600bps, $195

Racal-Guardata, Inc (703) 471-0892
Products: CAT-2000, 19200bps, $1125, DES
	  ISM, 9600bps, $2195, DES (eeprom based keys)

Microframe, Inc (201) 494-4440
Products: Cipher Key, 3000bps, $400, DES

Jones Futurex, Inc (916) 635-3972
Products: ENC324, 9600bps, $595, DES
	  ENC400, 9600bps, $595, DES

Intellicom (818) 407-3900
Products: microcipher, 19200bps, $499, DES

GN Telematic (800) 468-8353
Products: safematic, 9600 bps, $900, DES/RSA/custom algorithms

This is a partial list of companies that manufacture crytographic
hardware of the type you're looking for.  See the June 11, 1990 issue
of computerworld for a brief article and listing of companies that
manufacture such devices.

--
Tennyson Lee			University of California, Santa Barbara
6600tlee@ucsbuxa.ucsb.edu
6600tlee@ucsbuxa.bitnet

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 20:26:57 GMT
From:      gwyn@SMOKE.BRL.MIL (Doug Gwyn)
To:        misc.security
Subject:   Re: Security and Masterkeys

>In every
>case I am aware of the master key is the lowest key of all.

In a properly designed system, it shouldn't be.  Otherwise, any "day key"
(ordinary operating key) could be filed down to produce a master key.
This would especially compromise security when restricted blanks are used.

However, the procedure you suggest can often be used in modified form
to determine the highest-level masterkey, because if there are multiple
splits in a pin column you can be fairly sure that the one that matches
your day key is NOT the master split, and if there is only one split
then your day key and all levels of master key must share that depth in
that column.  Thus, if there are no more than two splits in each column,
using the ones that differ from your day key (when there is a choice)
will very likely produce the highest level master key.  (Lower-level
mastering is often done by sharing splits in a column or two with the
day keys in that submaster group.)

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 20:26:57 GMT
From:      Doug Gwyn <gwyn@smoke.brl.mil>
To:        misc-security@rutgers.edu
Subject:   Re: Security and Masterkeys
>In every
>case I am aware of the master key is the lowest key of all.

In a properly designed system, it shouldn't be.  Otherwise, any "day key"
(ordinary operating key) could be filed down to produce a master key.
This would especially compromise security when restricted blanks are used.

However, the procedure you suggest can often be used in modified form
to determine the highest-level masterkey, because if there are multiple
splits in a pin column you can be fairly sure that the one that matches
your day key is NOT the master split, and if there is only one split
then your day key and all levels of master key must share that depth in
that column.  Thus, if there are no more than two splits in each column,
using the ones that differ from your day key (when there is a choice)
will very likely produce the highest level master key.  (Lower-level
mastering is often done by sharing splits in a column or two with the
day keys in that submaster group.)

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 90 06:30:00 GMT
From:      NED@HMCVAX.CLAREMONT.EDU ("Ned Freed, Postmaster")
To:        misc.security
Subject:   Re: Security and Masterkeys

Don't expect the master to always be the lowest cut key. It is not in many
cases, although the pins where it is the "high cut" tend to be ones
reserved for zone master/grand master distinctions. However, I've never
seen a system where the highest cut was used in more than a couple of
pin positions, so the number of keys possible, even when working from a
single lock as an information source, is not very large.

Use of different grooves in the blank is the usual mechanism to
differeniate grand masters from great grand masters. However, adding
additional grooves to a key is pretty easy if you have access to a
mill and a tool of the proper size. Making your own key from brass stock
is also not too hard if you know what you're doing, and it makes complete
hash out of all these foolish "registered blank" schemes.

I mentioned making a key out of sheet metal in a previous posting. I once
made one out of mild steel as a sort of joke for somebody; it wasn't even
a master since that was not part of the joke (his key broke off in his
lock on two different occasions and I thought I'd make one that would not
suffer from this problem).

			Ned Freed

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 15:26:57 GMT
From:      DIXON@OHSTVMA.IRCC.OHIO-STATE.EDU (Bob Dixon)
To:        misc.security
Subject:   Re: DES routine for VMS

We have DES software which is compatible across all common operating systems,
including VMS. It is available to non-profit organizations for free.

                                            Bob Dixon
                                            Ohio State University

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 90 13:39:00 GMT
From:      EVERHART@arisia.dnet.ge.com
To:        misc.security
Subject:   Virus prevention

Re Kees deGroot's posting.
The DECUS library sells to anyone (membership in DECUS is free and
nobody is that concerned whether you are or are not a member.) The
software in it (multiple gigabytes of software) covers a great many
machines, and is NOT, repeat NOT, limited to boxes DEC makes. You
won't find much systems code for, say, Unisys boxes in the DECUS
library, but applications that will run on Unisys boxes certainly
abound.
   The library is run by a staff, who are DEC employees.
   It has two basic virus/trojan resistant attributes.
   First, the submitter is ALWAYS known and recorded, and everyone
who gets software from the library (for which a production fee is
charged; the cost is NOT paying for the software, but is covering part
of the cost of running a fulltime library) has that name.
   What you get is a copy of what the submitter sent in. The production
machines aren't on any nets or outside hookups; this makes them
fairly resistant to penetration by ill-doers.
   Further, there's a central office with people who answer the phone.
When covert behavior of a program is detected, here's what happens:
  1. The program is pulled from further distribution.
  2. People are notified by whatever means are available (which these
	days will include the net) about the nature of the problem and
	all specifics that are known.
  3. Efforts are made if the program was otherwise useful to reset the
	covert behavior and distribute the cleaned-up one together with
	a complete analysis of what happened.

	Source code is usually available also.
	This happened only once so far where a program had a covert
time-out. The damage to someone's reputation when he submits a program
and suffers all the adverse publicity which we can and WILL produce
is such that there's not much incentive to try putting covert behavior
into programs going into the DECUS library.
	Besides this, a good many of us use the code and look for
"funny" stuff. It's not organized so that there's 100% coverage,
and we don't want to say there is coverage even where it exists in
too strong a form; we are after all human and don't want lawsuits by
someone who says we should have tested more. But there are paths for
reporting odd behavior and reacting to it. This applies to the sig
tapes also, which are produced and distributed outside the DECUS
library as well as contributed to it. Most funny behavior that's been
reported are version or site dependencies (which can be quite hard
for an author to detect) and we try to tell what we find. 
	In all, the path from author to recipient is probably shorter
dealing with DECUS library stuff or SIG tape stuff than it is for
most commercial software, and we won't and haven't concealed any
reported covert behavior; we are best protected by publicizing any
such as quickly and widely as possible. Be sure this list will get such
reports, as well as info-vax/comp.os.vms and, if we find a worm orv
virus, virus-l. 
	We do ask that people using the code help by reporting any
odd behavior. You can call the DECUS office (508 480 3418 will get
you into the office, though you'll need probably another extension
to which you can be transferred) or me (215 354 7610) (me for
sig tape info; the DECUS office for any, by preference) or Ted
Nieland (513 427 6355) for SIG tape info also. To the extent we
watch one another's backs, we're all the safer.
	Funny behavior in this case means suspected covert behavior
by a program. If you have a systems program written, say, for VMS
V4.7 and try running it on VMS 5.3-1 symmetric multiprocessors, you
should expect it to fail in many cases. We're more interested thee
there in what succeeds. However, timeouts, odd use of privs, 
writing files or modifying files that aren't documented, and the
like are of interest.
	I understand the concerns about trojans or viruses, but these
are probably more likely in commercial software than people realize.
Your path from the submitter to you is as short dealing with the DECUS
library as it is buying direct from a commercial vendor, and shorter
than if the software passes through a store or distributor. The DECUS
record of NOT concealing any problems is also public, and that
policy will ultimately protect you further.
   Glenn Everhart
VAX SIG librarian (DECUS)
Everhart@Arisia.dnet.ge.com

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 90 17:41:22 GMT
From:      TS0258@ohstvma.BITNET ("Chuck Sechler")
To:        misc.security
Subject:   Password Checking

Some breakins to a computer at a university in Ohio has prompted us at Ohio
State to look into enforcing use of more obscure passwords on our systems.

Basically, Iwould like to know if there has been any work on MVS and/or CMS
platforms to keep users from picking obvious passwords, like their name,
password same as userid, password is a word, etc. On MVS we are working on Top
Secret software, and it has some interesting capabilities for restriction,
including generating random passwords, when a user is forced to change their
password, but it is not ready for full implementation yet. Some UNIX platfors
check against large lists of restricted words(like 50000 or more). Any
thoughts? Please respond to me. Thanks.

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 17:16:41 GMT
From:      mark%beowulf@UCSD.EDU (Mark Anderson)
To:        misc.security
Subject:   Re: Security and Masterkeys

>A properly selected master key must be impossible to create by filing
>a change key.  That means it must contain at least one cut that is
>taller than the corresponding cut in every change key.

I don't know about "common locksmithing industry standards", but the 
Foley-Belsaw training course doesn't mention any such concern in their
lessons.  Almost everywhere I've ever been you could find a change key 
to convert to a master.  I think you are overestimating the 
training/concerns of most locksmiths.  Or perhaps is just that 
facilities outgrew the original "correct" design.

And who really cares about the master key shear line, any old shear 
line will work, even for keys that don't exist.  I've always had 
the best luck picking locks on a master key system.

And if you are in a position where you can request legitimate keys, 
you can often order masterkeys through the same office just by knowing 
the code (which you get by watching a janitor).

mark

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 20:44:01 GMT
From:      levine@csd4.csd.uwm.edu (Leonard P Levine)
To:        misc.security
Subject:   Re: Security and Masterkeys

> Sorry Leonard.  You must not be aware of any professionally designed
> master keying systems that were set up according to common locksmithing
> industry standards.

Don't I wish.  I spoke at length to our locking staff, as well as the 
building designers.  They did not even believe that this really bad design
was not the norm.  I agree with Seth that this is dangerous, but never
could get lock people to follow the problem.

Seth, are you speaking from theory or do you have a high masterkey in 
your posession?  I really want to know.

len levine

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 90 07:33:36 GMT
From:      hobbit@PYRITE.RUTGERS.EDU (*Hobbit*)
To:        misc.security
Subject:   Failed: attempt #1 at securing the vehicle

It would be REALLY GREAT if makers of "real" locks made drop-in replacements
for car doors, complete with reinforcing plates and good pin cylinders and a
mechanism that works such that once you turn the key a certain way the little
lever is locked toward one direction and won't move at all.  This would prevent
use of a slim-jim.  Unfortunately for the kind of car-door latch that doesn't
work when the lock is locked, it could also trap people inside the car.  Given
that one would have to explicitly lock the door from the outside with such a
rig, I think that I'd personally rather have that small risk than what, for
instance, I have now, which is a car that's frighteningly easy to break into.

I recently tore my door apart to investigate the possibility of doing this.
The cylinder has a limit stop which prevents motion much more than 60 degrees
either way from center, and this stop is somewhere underneath the stupid
press-fit front bezel, which if bent apart and then back again will probably
be rather weakened.  So for the moment I've given up on the idea of redoing it
so it could be turned 180 degrees and then the key pulled.  If someone knows of
a type of car cylinder whose limit stops are on the *back*, where I could
get at them and file them down, please holler, and I could go off to a junkyard
and find that kind of car.  Yes, even with all that glass sitting there
saying "break me", I still want to do this just for hack value.

_H*

-----------[000039][next][prev][last][first]----------------------------------------------------
From:      John Moore <anasaz!john@mcdphx.phx.mcd.mot.com>  22-JUN-1990 19:23:02
To:        security@asuvax.eas.asu.edu
Yes... the same monthly master key is (or at least was) used for all channels.
Thus, if you can decrypt one, you can decrypt all. The VC-II uses
non-crypto means to decide whether you can watch a particular channel.
Thus, if you defeat this (by modifying the code), you can subscribe
to one channel (which makes all the crypto possible) and then receive all.

My understanding is that someone dissected the crypto chip, found a
way to reconnect a factory test lead, and was able to get intermediate
crypto products out that can be used to crack the key. This is from
a hazy memory.

[Disclaimer: I have a video-cipher II and haven't touched the insides.
 I don't want to go to jail!]
-- 
John Moore HAM:NJ7E/CAP:T-Bird 381  {asuvax,mcdphx}!anasaz!john john@anasaz.UUCP
Voice: (602) 951-9326 (day or eve)   FAX:602-861-7642  Advice: Long palladium,
USnail: 7525 Clearwater Pkwy, Scottsdale, AZ 85253     ......: Short petroleum
Opinion: Support ALL of the bill of rights, INCLUDING the 2nd amendment!
-----------[000040][next][prev][last][first]----------------------------------------------------
From:      "Ned Freed, Postmaster" <NED@hmcvax.claremont.edu>  22-JUN-1990 19:50:37
To:        security@pyrite.rutgers.edu
Don't expect the master to always be the lowest cut key. It is not in many
cases, although the pins where it is the "high cut" tend to be ones
reserved for zone master/grand master distinctions. However, I've never
seen a system where the highest cut was used in more than a couple of
pin positions, so the number of keys possible, even when working from a
single lock as an information source, is not very large.

Use of different grooves in the blank is the usual mechanism to
differeniate grand masters from great grand masters. However, adding
additional grooves to a key is pretty easy if you have access to a
mill and a tool of the proper size. Making your own key from brass stock
is also not too hard if you know what you're doing, and it makes complete
hash out of all these foolish "registered blank" schemes.

I mentioned making a key out of sheet metal in a previous posting. I once
made one out of mild steel as a sort of joke for somebody; it wasn't even
a master since that was not part of the joke (his key broke off in his
lock on two different occasions and I thought I'd make one that would not
suffer from this problem).

			Ned Freed
-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 90 15:44:22 GMT
From:      jearly@LEHI3B15.CSEE.LEHIGH.EDU (John Early)
To:        misc.security
Subject:   SPARCstation security

The CC and CSEE here at Lehigh are going to set up a Sun SPACRstation *public*
site (hopefully in time for the fall semester) and I'm trying to find out
what is available as far as physical security systems.  All we really need
to do is bolt the CPU and monitor down (we will have both the 16 inch color
and the 19 inch mono) and cable the keyboard and mouse to the CPU.  (The
optical mouse will be interesting...while there is no ball for people to steal
the pad will certainly walk if not glued down, yet if I glue it down our
left-handed users are screwed--and don't ask me to ask for money to buy two
per station.)
So if anybody knows of any systems for Suns please e-mail me.  If people want
I can let you know how things work out in the fall.
Thanks,
John.

----------------------------------------
John Early                             |
jearly@lehi3b15.csee.lehigh.edu        |  I was just a child then;
JPE1@Lehigh.Bitnet                     |  now I'm only a man.  [pf]
LUJPE@VAX1.cc.lehigh.edu               |

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 90 14:32:19 GMT
From:      kuras@josef.enet.dec.com
To:        misc.security
Subject:   Re: workshop

The dates of the workshop are August 27 & 28, 1990.  Sorry, I don't have
location or other particulars at this time, other than it's in Portland,
Oregon. 

The organizer of the workshop is Matt Bishop,  Dept of Mathematics &
Computer Science, Bradley Hall, Dartmouth College, Hanover, NH 03755 (603)
646-2415 

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 90 06:01:57 GMT
From:      deronwal@TYBALT.CALTECH.EDU (Deron Walters)
To:        misc.security
Subject:   Medecos (was Re: Best Locks)

>On a recent visit I noticed they had rekeyed with Medeco Bi-axial locks, but
                                                   ^^^^^^^^^^^^^^^^^^^^^

Huh?  Bi-axial?  I'm familiar with regular Medeco locks, but I've never heard
of these.  Please describe them in more detail!

Deron A. Walters

[Moderator explanatory tack-on: Biaxial refers to Medeco's offset-chisel-tip
pin design, in which the bottom edge of the pin is offset forward or back
by .025".  Thus the bottom of the keycut has to not only be at the right
height and twist, it also has to be at the correct offset along the key bit.
_H*]

-----------[000044][next][prev][last][first]----------------------------------------------------
From:      Rick Schatzman <AURPS@asuacad.bitnet>  27-JUN-1990 23:21:03
To:        security@pyrite.rutgers.edu
Does anyone know how to decrypt a Word Perfect 5.0 or 5.1 file when the key has
 been lost?  I have heard that there is an article published that explains how
to do this.
-----------[000045][next][prev][last][first]----------------------------------------------------
From:      Richard Hintz <OPSRJH@uccvma.bitnet>  27-JUN-1990 23:56:00
To:        security@ohstvma
We are interested in technology for authenticating electronic
commercial documents, such as Purchase Orders.
Can someone provide some pointers to references on this?

Also, does it make sense to talk about using the RSA technology for
this purpose?  By the way, I'd like to get RSA's phone number,.
if someone has it handy.
  Richard Hintz  University of California  (415) 987-0437  opsrjh@uccvma
-----------[000046][next][prev][last][first]----------------------------------------------------
From:      zeleznik@cs.utah.edu (Mike Zeleznik)  28-JUN-1990  0:22:41
To:        security@rutgers.edu
>You cannot, as a plain old, lowly American citizen, get anything from the
> NSA.  All requests are declined.

But you CAN get all you want of their public info from their public arm,
the National Computer Seurity Center (NCSC) (I'm sure this has been
mentioned here before).  You can also  probably get an account on
dockmaster to keep up with what is available on-line (Project OPENAIR).

OPENAIR:	NCSC
		Attn: OPENAIR Accounts Administrator
		9800 Savage Rd
		Fort Meade, Maryland 20755-6000
		(301) 850-4446 or maybe 859-4360

NCSC PUBS (single copies only): 	(301) 859-4450

And if you need other info, the people above will probably be more then
willing to help point you in the right direction.

Mike

  Michael Zeleznik              Computer Science Dept.
                                University of Utah
  zeleznik@cs.utah.edu          Salt Lake City, UT  84112
                                (801) 581-5617
-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 90 15:24:00 GMT
From:      DEGROOT@rcl.wau.nl ("Kees de Groot, Information Systems Security")
To:        misc.security
Subject:   Re: Off the wall...ROM security?

Bob,

        Intel's micro-controllers in the MCS-51-series
        have a feature in which you can program a sort of
        hashing or mask. The effect is that it is impossible
        to read directly from the EPROM, but you can erase
        the whole device and reprogram it.
        This is al from between my ears. if you want
        more detailed information I can try to find some docs.

Tel. +31-8370-  .KeesdeGroot   (DEGROOT@RCL.WAU.NL)   o\/o  THERE AINT NO
     (8)3557/   Computer Systems Security              []   SUCH THING AS
        4030    Inform. & Datacomm.  Dreijenplein 2   .==.  A FREE LUNCH!
                6703 HB  Wageningen, the Netherlands
                X25:    PSI%(+204)18802031937::DEGROOT
disclaimer:     I always speak for myself
- if you go too far to the east, you find yourself in the west ..  -

-----------[000048][next][prev][last][first]----------------------------------------------------
From:      vancleef@fs01.nas.nasa.gov (Robert E. Van Cleef)  28-JUN-1990  0:54:44
To:        security@pyrite.rutgers.edu
Oh - Cute! That means YOU, or one of your staff, know all of the
passwords. What we did is:

1 - Make the password program reject dumb passwords.

2 - Run a fast password cracker against all of our systems to insure 
    the "root" hasn't given someone a dumb password.
	    
You are assuming that you and your staff will assign passwords that are
safe and memorable. My experience is that, under the pressure of
events, people will assign passwords to others that are as bad, or worse,
that those others would have picked for themselves.

Let your software do the work for you. 

Of course, you did say a "medium sized system". The problem with most
solutions that I have seen, to all Unix system administration problems,
are that they are not scalable. As systems grow, things break! Can you
safely say that your current procedures would work if your system
doubled in size or the number of users?

Bob 
__
Bob Van Cleef - vancleef@nas.nasa.gov

RNS Distributed Systems Team Leader
NASA Ames Research Center		(415) 604-4366
Mail Stop 258-6				 FTS  464-4366
Moffet Field, CA 94035-5000	    FAX (415) 604-4377
__
"If you're not a liberal at 20, you have no heart, and 
 if you're not a conservative at 40, you have no head."
 Winston Churchill
-----------[000049][next][prev][last][first]----------------------------------------------------
From:      xrtnt@amarna.gsfc.nasa.gov (Nigel Tzeng)  28-JUN-1990  1:30:44
To:        misc-security@ames.arc.nasa.gov
^ adminisister the password problem is to assign passwords and remove the
^ passwd program

>From the users point of view this gets annoying after a while.  For longish
password of random variables they'll eventually just write them down.  Now what
does that buy you?  Same for the preemptive password lengthening system.  If
they can't deal with a 8 char password limit in an intelligent sort of way how
do you think they'll deal with a ten char password limit?

This sort of behavior is a) confrontational b) non-productive.  By doing this
sort of thing you'll piss off users who know better and lead to the situation
where they go out of their way to circumvent your protections leading to a
further unprotected system.  

Of course I work in a development environment where most users here can be
considered "power-users".  As software professionals we (or at least I) insist
on being treated as one and not as some hacker dude from the Chaos Klub.  Users
are as much part of a secure system as the protection schemes built into the
native OS.

NT

--------------------------------------------------------------------------------
   // | Nigel Tzeng - STX Inc - NASA/GSFC COBE Project
 \X/  | xrtnt@amarna.gsfc.nasa.gov
      | 
Amiga | Standard Disclaimer Applies:  The opinions expressed are my own. 
-----------[000050][next][prev][last][first]----------------------------------------------------
From:      Alex Kuhn <75016.1201@compuserve.com>  28-JUN-1990 22:09:53
To:        <security@pyrite.rutgers.edu>
Hi.  I'm new to this newsgroup, but I have a question I figure someone here
can answer.  How does someone become a locksmith?  I've always had a great
interest in keys and locks, and am interested in doing some locksmithing.
  Do you have to be licensed in the town/state?  Or can you just set up shop
with a key machine and call yourself a locksmith?  Can someone order blanks
from a distributor or manufacturer directly, or do you have to have a
locksmith's license to get them?  I'm interested in the whole field, but
Best keys interest me particularly.  Can these be gotten without a
locksmith's license?
  Thanks for any help you can give-
Alex Kuhn (75016.1201@compuserve.com)
-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Jun 90 22:19:44 -0400
From:      Theodore Lee <lee@TIS.COM>
Subject:   The F9 factoring result
MESSAGE FROM RON RIVEST VIA JIM BIDZOS VIA STEVE KENT VIA STEVE CROCKER:
Thanks to Robert Silverman for keeping many people honest.
As an additional effort to that end, I attach an analysis of
the recent factoring effort, done by Ron Rivest.  The early 
reports of RSA's demise have been greatly exaggerated...
Note: Be sure and read the end of Rivest's note.
Jim Bidzos, RSA Data Security

To:	Whom It May Interest (Feel free to distribute further...)
From:	Ronald L. Rivest
Date:	June 21, 1990
Re:	Recent Factoring Achievement
	(Preliminary draft; may contain typos or other inaccuracies.
	Please send corrections to rivest@theory.lcs.mit.edu)

This note is in response to the numerous inquiries I've received regarding
the recent factoring of a 155-digit number by A. Lenstra, M. Manasse, and
others.  (See the New York Times article of 6/20/1990 by G. Kolata.) 
This note attempts specifically to correct some of the misimpressions that
may arise from a reading of such popular press articles.

Using an ingenious new algorithm, Lenstra, Manasse, and others have
factored the 155-digit number known as "F9", the ninth Fermat number:
		F9 = 2^(2^9) + 1 = 2^(512) + 1 .
In binary, this number has the form
		100000....000000001
where there are 511 zeros altogether.  (F9 is a 513-bit number.)
This is a fascinating development, and the researchers involved are to be
congratulated for this accomplishment.

The algorithm used is known as the "number field sieve", or "NFS" (not
to be confused with a network protocol of the same acronym!).  The NFS
algorithm is described in the Proceedings of the 1990 ACM STOC Conference.
The NFS algorithm is based on an idea due to Pollard, as developed further by
Arjen Lenstra, Hendrik W. Lenstra, and Mark S. Manasse.

The NFS algorithm is specifically designed to factor numbers that,
like F9, have a very simple structure: they are of the form
		a^b + c 
where c is relatively small.  (For F9, we have a=2, b=512, and c=1.)
Some simple extensions of this algorithm are also possible, to handle
numbers whose binary representation has many zeros, and related kinds
of numbers (ternary, etc.)  Numbers that have such a special structure are
extremely rare and are unlikely to be encountered by chance.  That is,
the NFS algorithm does not apply to the kind of "ordinary" numbers that
arise in practical cryptography, such as using RSA.  They only apply to
numbers with "sparse" representations having few nonzero components.
(Let us call such numbers "rarefied".)

When working on a rarefied number, the NFS algorithm has an estimated
running time of the form (for an input number n):
		exp(1.56 (ln n)^1/3 (ln ln n)^2/3)			(1)
For n = F9, this evaluates to 
		4.1 x 10^15 operations,
which, at 3.15 x 10^13 operations/year for a 1 MIP/sec machine (i.e. a
MIP-year), gives a workload estimate of
		130 MIP-years,
only off by a factor of two from the actual work of 275 MIP-years. (That is,
formula (1) may be roughly too low by a factor of two.)

It is instructive to see the effect of doubling the size of the number
being dealt with.  A 1024-bit (332-digit) rarefied number requires an estimated
		1.54 x 10^21 operations
	=	4.9 x 10^7 MIP-years,
a dramatic increase in difficulty.  The NFS algorithm algorithm is not a
"polynomial-time" algorithm; the difficulty of factoring still grows
**exponentially** with a polynomial function of the length of the input.

What has this to do with RSA and cryptography?  I think there are three
basic points:
	-- This development indicates that the status of factoring is
	   still subject to further developments, and it is wise to be
	   conservative in one's choice of key-length.
	-- The NFS algorithm may yet be generalized to handle "ordinary"
	   numbers, and the potential impact of this should be considered.
	-- Factoring is still a very hard problem, despite everyone's best
	   efforts to master it.

Regarding the further extensions of NFS to handle ordinary numbers, this is
judged to be a reasonable possibility by those working on NFS, so it is 
helpful to consider what impact this may have.

It is conjectured (see the ACM STOC paper referenced above) that a successful
extension of the NFS algorithm to ordinary numbers would have a running time
of the form:
		exp(2.08 (ln n)^1/3 (ln ln n)^2/3)			(2)
This is similar to equation (1) except that the constant 1.56 is
replaced by the constant 2.08.  Note that a practical version of such
an extension does NOT yet currently exist (to the best of my
knowledge), but even granting its plausibility we arrive at an
estimate of the tie required to factor a 512-bit number of
		6.5 x 10^20 operations
	= 	2 x 10^7 MIP-years
which (in my opinion) is a substantial degree of security.  It is 
interesting to note that this work factor is actually GREATER than that
required by the ``standard'' factoring algorithms (e.g., the quadratic sieve),
which have a running time of
		exp((ln n)^1/2 (ln ln n)^1/2);
for a 512-bit number, this gives a work-factor estimate of only
		6.7 x 10^19 operations.
Indeed, the NFS algorithm (when extended) will be asymptotically superior than
the quadratic sieve algorithm, but will be slower for numbers with less 
than about 200 digits.  That is, assuming that (2) is indeed the correct
running-time estimate for any extension of NFS, then NFS will not affect the
security of any numbers of less than about 215 digits.  So any "standards"
that have been considered using 512-bit RSA moduli are not likely to be
affected by any NFS extensions.  (At most, one could imagine that the
RSA key-generation process might be extended to check that the resulting
modulus n is not a rarefied number.)

In the truly worst-case scenario, we would have that an extension of
NFS would be found that allows ordinary numbers to be factored with a
work-factor that is governed by equation (1); in this case one would
need to adjust the sizes of moduli used by RSA upwards by a factor of
less than two to more than offset the new algorithm.  A factor of two
in size affects the running time of public-key encryption (or
signature verification) by a factor of four and the running time of
private-key encryption (or signature generation) by a factor of eight.
Noting that the speed of workstations has increased by a factor of
over 100 in the last decade (indeed, such factors have been the
technological advance that made the successful implementation of NFS
possible!), such performance penalties, if necessary, seem to be
easily absorbed by expected technological advances in the speeds of
the underlying RSA implementation technologies.  That is, the NFS-like
factoring algorithms do not, even in this worst-case scenario, prevent
successful implementations of the RSA cryptosystem.

As a cryptographer, I am actually very happy with all the effort that
is being spent trying to determine the exact level of difficulty of
factoring.  Achievements such as the recent development of NFS help to
pin down the best-possible rate of growth of the difficulty of
factoring, so that users of cryptographic schemes can pick key sizes
with an increased degree of confidence that unforeseen developments
are unlikely to occur.  The best way to ensure confidence in a
cryptographic system is to have it attacked vigorously and
continuously (but unsuccessfully) by well-qualified attackers.  If,
despite their best efforts, the difficulty of cracking the system
remains intrinsically exponential, then one can have a reasonably high
degree of confidence that the system is actually secure.  This is the
process we have been seeing at work in the recent work on factoring.
The results of the attacks can be used to guide the selection of the
necessary key size for a desired level of security (with an
appropriate margin of safety built in, of course).

(As a closing note, here's a prediction: I expect that the 128-digit
``challenge RSA cipher'' published in the August 1977 issue of
Scientific American to be cracked (probably by the quadratic sieve
algorithm or a variant, not NFS) during the next 1-3 years.  This
accomplishment will require substantially more computer time than the
275 MIP-years required to factor F9.)
-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 90 18:52:02 GMT
From:      security-request@PYRITE.RUTGERS.EDU (*Hobbit*)
To:        misc.security
Subject:   Collected replies re: IBM security

There were many of these; to save a little network bandwidth I've created
a small digest thereof.   _H*

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date: 13 Jun 90 04:38:50 GMT
>From: Doug Gwyn <gwyn@smoke.brl.mil>
Subject: Re: IBM security

>What I don't understand is that I have rarely
>encountered references to security breachs on IBM machines running VM or
>MVS.  Why is this?

There are many possible reasons, among them:
	UNIX and VMS are set up to facilitate sharing among users,
	while IBM mainframes are set up to prevent sharing.

	There are relatively few users of IBM mainframes, especially
	hacker types, students, etc.

	IBM mainframe security is such a joke that breaking it isn't
	considered a challenge.

	Technical information about the inner workings of IBM
	mainframes is voluminous and hard to come by.

	IBM mainframes don't provide direct access by ASCII terminals,
	which are the only kind crackers are likely to have.

	IBM users don't share information the way UNIX (and to some
	extent VMS) users do.

I've heard of several security breaches on IBM mainframes, so I
wouldn't say that they're inherently more secure.

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date: 13 Jun 90 09:19 EST
>From: EVERHART@arisia.dnet.ge.com
Subject: IBM security

I've heard of a number of cracks of IBM system programs in the past.
They're generally hushed up quickly at the local site. One was to
boot VM into a system too small to hold CMS; one gets into a VM nucleus
somehow and can issue commands which CMS would ordinarily filter as
privileged.
  The ISAM access method for years used (maybe still uses?) self modifying
channel code which can be and has been used to get into supervisor state.
   I recall stories of using SVC 15 to get to supervisor state, but that
was a long time back and I heard too little to get the details. There
was a hole in one of the IBM OSs that allowed nonpriv'd users to do
this though. 
   The hole in CMS security was patched at the site where the case I 
heard of by having them hire the guy who did it (he was a high school
student at the time and used it to forge some mail and play a few
pranks but did no serious damage) and get him to plug them. Lord knows
what else was involved.
   I've heard these stories about several sites where I've gotten to know
IBM systems people. They are NEVER discussed in the press, and the
systems are generally large computing centers that feel they would be
highly embarrassed (and lose business) if their vulnerabilities were
discussed openly. This of course leaves OTHER IBM sites still wide
open to the same hacks, apart from the (hopeful) reports to IBM
and (hopeful) IBM fixes. Since most of these sites don't seem to be
as pervasively networked as other systems, and since their internals
are often unfamiliar, reports don't seem to have leaked out as much
as in other systems. I presume that after this many years the problems
reported don't exist in current IBM OSs, but have little doubt that
others do.
   Anyone have other more recent stories to tell?
Glenn Everhart

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date: Wed, 13 Jun 90 08:11:12 -0700
>From: vancleef@fs01.nas.nasa.gov (Robert E. Van Cleef)
Subject: Re: IBM security

Look for the novel "The Consultant", published in the late 60's.

It is about a computer security consultant that used his 
knowledge to steal from his clients. As a novel it is 
so-so, but it will give you some insight into the environment
of large, commercial systems.

Bob
__
Bob Van Cleef - vancleef@nas.nasa.gov

RNS Distributed Systems Team Leader
NASA Ames Research Center		(415) 604-4366
Mail Stop 258-6				 FTS  464-4366
Moffet Field, CA 94035-5000	    FAX (415) 604-4377
__
"If you're not a liberal at 20, you have no heart, and 
 if you're not a conservative at 40, you have no head."
 Winston Churchill

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date: Wed, 13 Jun 90 12:16:03 -0400
>From: wrf@ecse.rpi.edu (Wm. Randolph Franklin)
Subject: IBM OS security

Unix Today, Jan 23, 1989, page 10,  had an  article "Feds Insecure about
MVS too".  It doesn't have too  much technical info though.   I think in
general IBM practices at least some security through obscurity.

In the  1960s and early 70s, OS  had  no  protection whatsoever.  Anyone
could read  or write any  disk data  set (file).   The IEHPROGM  program
could   delete   any  data  set  something   like  thus   (my  memory is
approximate):

SCRATCH VOL=USR001,DSN=MY.FTN

If you omitted the comma, the DSN=MY.FTN would be treated as  a comment.
The remaining command caused the whole disk to be scratched.  One day at
U  of  Toronto someone   scratched all the online disks.    I'm not even
certain it was malicious  and  not  accidental.  They restored  from the
daily backup and deleted   that function   from  the IEHPROGM   program,
forcing any potential hacker to read the  manual and  write a program to
do the SVC call to scratch the whole disk himself.

Of course IBM is better now.  It's harder to get the manual :-)

P.s. U  of T  20 years  ago  did better  backups than all   the publicly
available computers here at RPI today, except the campus mainframe.   So
IBMers do a few things right.

                                     --------
						   Wm. Randolph Franklin
Internet: wrf@ecse.rpi.edu (or @cs.rpi.edu)    Bitnet: Wrfrankl@Rpitsmts
Telephone: (518) 276-6077;  Telex: 6716050 RPI TROU; Fax: (518) 276-6261
Paper: ECSE Dept., 6026 JEC, Rensselaer Polytechnic Inst, Troy NY, 12180

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date: 13 Jun 90 20:04:36 GMT
>From: esf00@uts.amdahl.com (Elliott S. Frank)
Subject: Re: IBM security

It's been a while since I last logged onto TSO (the interactive access
component of MVS), but I'll give it a whirl. [I'm not a lawyer, but
I occasionally wear a shirt and tie like one. If I actually knew
anything about anyone breaking MVS, I'd probably not disclose it in
this forum (see third paragraph, below.)]

The mechanisms required to break MVS security are "well known" -- all
you need to do is to place your program in an "authorized library"
[allowed to invoke restricted operating system functions] and off you go.
Consequently, there are tools from both IBM and from third parties
(Computer Associes has two **expensive** offerings) to restrict access
to such libraries. MVS also has extensive logging and tracing built
into the operating system. This logging covers *all* access to data.
This logging is the basis for most chargeback schemes, so it is kept
running most of the time. IBM will also accept **all** bug reports
that identify a security 'leak' in MVS and fix them. Security APARs
(bug fixes) are distributed with only the label 'SECURITY' -- with
the failure mechanism and bypass information that normally accompany
each MVS bug fix suppressed.

Most MVS shops run large configurations ( >>50 VUPS) and consequently
have the requisite administrators as part of the overhead of operating.

Finally, if you've got your corporate financials and other *extremely*
sensitive files running under MVS, you're not going to publicize the
fact that you have been attacked. The law that makes it criminal for
corporate officers to pay (or codone paying) bribes *anywhere in the
world* also makes corporate officers responsible for the security of the
computers that they manage. If you publicize an attack on your MVS
system, you lay yourself open to a stockholders suit. Far better to
defeat the attack, turn the miscreant over to your lawyers, and seal
the court records. Given the mechanisms described above, I suspect
that most attacks are 'semi-inside', rather than outside crackers.
-- 
Elliott Frank      ...!{hplabs,ames,sun}!amdahl!esf00     (408) 746-6384
               or ....!{bnrmtv,drivax,hoptoad}!amdahl!esf00

[the above opinions are strictly mine, if anyone's.]
[the above signature may or may not be repeated, depending upon some
inscrutable property of the mailer-of-the-week.]

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date:         Wed, 13 Jun 1990 17:40:27 EDT
>From: Homer <CTM@cornellc.bitnet>
Subject: Re: IBM security

     This is totally off the wall, but I proffer it anyhow.  IBM systems
are often associated with higher echelon sort of people, professionals
doing serious work etc, people who have outgrown their 'criminal' years
of 18 to 25.  IBM systems are also very expensive to access so young
student use is minimal, although at Cornell I must admit IBM mainframes
have served the student body for many years and still do.

    Sun and Unix systems on the other hand proliferate widely,
are 'free' in that rarely do you hear of someone needing to put
money into an account so almost anyone can get an account who wants one
and they are not limited by small amounts of alloted computer time.
Thus the bigger more expensive to use systems are used more by serious well
funded, well checked out kinds of people,
and the smaller less expensive systems attract endless nuts.  The
extreme of this are the PC's of course where viruses are a dime a dozen,
but so are the PC's.  Anyone can own one and hack on it forever in the privacy
of his own home until he has developed a killer something or other.

     Also the IBM environment of VM is much like solitary confinement,
it was designed this way on purpose.  Writing a virus for this system
would infect you and thats it.  That is the whole idea behind virtual
machines.  Every time you are swapped out of core, your whole machine
is turned off and someone elses is turned on.  Of course no virus
can survive a on/off cold boot.

     IBM systems can be attacked, but it takes more system knowledge
than is available to your usual freshman hacker.  Anyone can get
systems knowledge of a Sun or Unix system.  That is part of their design
philosophy.  You gotta have a real job to get it on the IBM systems,
and most of those people are trust worthy.  Of course if any IBM
system were ever attacked by an inside job, the results would be
devastating at least to that one machine.

     Pardon my display of ignorance.

     Also I did not mean to insult anyone using non IBM systems.
Professionals use all sorts of non IBM systems all the time.  My point
is merely that there are a higher number of NON professionals using
the non IBM systems too, and these systems are widely interconnected,
and are easy to learn the internals of.  This is a recipe for trouble.
As the professionals who use the non IBM systems have found out.

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date:         Wed, 13 Jun 90 18:32:00 EDT
>From: "Lee C. Varian" <LVARIAN@pucc.bitnet>
Subject: Re: IBM security

Craig,  For the last seven years for VM (and I think about ten years
for MVS), IBM has made an "Integrity Statement" about these two operating
systems which basically says that they will fix security problems in
these systems.  I'm enclosing a copy of the original Integrity Statement
for VM.

Our installation participated in uncovering a security problem in VM a
number of years ago (the "Hugo problem" in which it was possible to
alter a protected area of memory with a very bizarre and clever I/O
channel program).  I can assure you that IBM took the problem very
seriously and we were testing a fix from them in a matter of days.
  Lee Varian
  Princeton University

IBM Programming Announcement dated June 21, 1983 (VM/SP integrity
    announcement)

Statement of system integrity for
VM/System Product (VM/SP) and VM/SP
High Performance Option (VM/SP HPO)

 5664-167
 5664-173

System integrity is an important characteristic of VM/SP.  This
announcement extends IBM's previous statements on system integrity to
the VM/SP environment.  For VM/SP Release 3 and the associated VM/SP
High Performance Option, IBM will now accept APARs that describe
exposures to system integrity or that describe problems encountered
when a program running in a virtual machine not authorized by a
mechanism under the customer's control introduces an exposure to system
integrity.

IBM has performed an analysis of the VM/SP environment, which includes
the VM/SP control program and VM/SP HPO, to identify and correct
instances of potential system integrity exposure.  As system integrity
problems have been investigated and corrected, understanding of VM/SP
integrity has increased and IBM has implemented specific design and
coding guidelines for maintaining system integrity in the development
of VM/SP.  Procedures have also been established to make the application
of these design and coding guidelines a formal part of the
design/development process.

However, since it is not possible to certify that any system has
perfect integrity, additional exposure may come to light.  Therefore,
IBM will accept APARs that describe exposures to system integrity of
VM/SP or that describe problems encountered when a program running in
a virtual machine not authorized by a mechanism under the customer's
control introduces an exposure to the system integrity of VM/SP, as
defined below.

IBM will continue its efforts to verify and enhance the integrity of
VM/SP and to respond promptly when exposures are identified.  Except
as noted, this statement applies to:

o VM/SP Release 3 and subsequent releases

o The associated VM/System Product High Performance Option release
  and subsequent releases.

VM/SP system integrity definition:  VM/SP control program system
integrity is defined as the inability of any program running in a
virtual machine not authorized by a VM/SP control program mechanism
under the customer's control and/or guest operating system mechanism
under the customer's control to:

o Circumvent or disable the control program main or secondary
  storage protection.

o Access a control program password-protected resource.

o Obtain control in real supervisor state or with privilege class
  authority or directory capabilities greater than those it was
  assigned.

o Circumvent the system integrity of any guest operating system
  which itself has system integrity (such as MVS or VM/SP as a
  result of an operation by any VM/SP control program facility.

VM/SP control program system integrity does not specifically
include the protection of data between multiple users of a single
CMS batch system.  It also does not apply to virtual machines using
Non-Disruptive Transition (NDT) support.

The following environments are supported for MVS machines only:

o V=R with the NOTRANS option

o V=R with the Shadow-Table-Bypass SET command option

o The preferred machine assist

o The single processor mode

However, when any of these facilities are used within an MVS guest
machine, an MVS user or program that has been given authority to
bypass MVS system integrity control may also be able to bypass the
system integrity controls built into VM/SP.  In these circumstances
it is a customer responsibility to assure that the required MVS
system integrity controls are installed and that MVS-authorized
programs and users are properly controlled. (See the programming
announcement dated October 21, 1981 for the definition of MVS
system integrity.)

Main storage protection refers to the isolation of one virtual
machine from another.  The control program accomplishes this by the
use of hardware dynamic address translation.

Secondary storage protection refers to the disk extent isolation
implemented for minidisks/virtual disk through channel program
translation.

Password-protected resource refers to resources protected by control
program logon passwords and minidisk passwords.

Guest operating system refers to a system control program that operates
under the VM/SP control program.

Directory capabilities refers to those directory options which control
the use of functions intended to be restricted by specific assignment,
such as those which permit system integrity controls to be bypassed
or those not intended to be generally granted to users.

Customer responsibilities:  While protection of the customer's data
remains the customer's responsibility, data security continues to
be an area of vital importance to IBM.  IBM's commitment to the
system integrity of the VM/SP environment, as described in this
announcement, represents a major step to help customers protect their
data.

Product documentation, subject to change, will describe what action
must be taken and which facilities must be restricted to complement
the system integrity support provided by VM/SP.  Such actions and
restrictions may vary depending on the system, configuration, or
environment.  The customer is responsible for the selection,
application, adequacy, and implementation of these actions and
restrictions, and for appropriate application controls.

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date: 17 Jun 90 15:38:10 GMT
>From: hwt@x.bnr.ca (Henry Troup)
Subject: Re: IBM security

My experience as a VM system programmer was that IBM was reasonably 'tight'
with regards to bypassing the protection mechanism. There were occasional
RAS (Reliability, Availability, Security) announcements and fixes from IBM,
but most of the holes in the system would simply cause a crash, rather than
allowing unauthorized access.

One of the biggest (and classic) VM/SP holes is the installation guide, which
has the listing of the starter system directory as the back 20 pages - passwords
and all.  Many small packaged systems never changed those passwords, and some
people even thought that those accounts and passwords were essential.

I suspect, however, that the security of most mainframes lies in the fact that
you can't break a system from a card reader with any ease.  There's still an
immense amount of non-interactive computing done on MVS, for example. Physical
terminals may be few and far between.

At U of Toronto, when I was there, there were complete separated academic
and administrative systems - duplicated, non-cross connected IBM 3033N8s.
It was well known that a student caught doing anything with the admin system
would be expelled.  All terminals were keylocked, and behind locked doors.
Students were not allowed in the machine room.

Final note: VM has several privilege classes - the most useful to the hacker
being the one that allows you to write to system memory - and change your 
privilege class.
--
Henry Troup - BNR owns but does not share my opinions
..uunet!bnrgate!hwt%bwdlh490 or  HWT@BNR.CA

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 90 19:38:00 GMT
From:      CSMSPCN@OAC.UCLA.EDU (Pete Nielsen)
To:        misc.security
Subject:   Re: Authentication of electronic commercial documents

I'd ask a bank, I believe wired funds include an authentication
code.

RSA is an interesting question.  I heard that some mathematician
recently factored a 155 digit number, and that they are consequently
recommending at least 200 digit primes for the RSA stuff.

-----------[000054][next][prev][last][first]----------------------------------------------------
From:      Bob Dixon <DIXON@ohstvma.ircc.ohio_state.edu>  29-JUN-1990 12:04:03
To:        security@pyrite.rutgers.edu
We have DES software which is compatible across all common operating systems,
including VMS. It is available to non-profit organizations for free.

                                            Bob Dixon
                                            Ohio State University
-----------[000055][next][prev][last][first]----------------------------------------------------
From:      "Howie McCausland (802)388_3711x5754" <HOWIE@midd.cc.middlebury.edu>  29-JUN-1990 12:37:05
To:        security@pyrite.rutgers.edu
I have heard the argument made that forcing frequent password changes is
counterproductive--particularly in those systems where the user logs in,
learns that her/his password has expired, and has to choose a new one
IMMEDIATELY.  The supposed flaw is that the user will pick a poor password,
because there isn't enough time to think up a good one.  Similarly, those
password generator programs that impose a non-english password on the user
are said to cause passwords to be written down.

I'm not sure I subscribe to either argument, but wondered what others in
the network thought...

                        Howie McCausland  (Middlebury College)
-----------[000056][next][prev][last][first]----------------------------------------------------
From:      EVERHART@arisia.dnet.ge.com  29-JUN-1990 13:11:40
To:        security@pyrite.rutgers.edu
Re Kees deGroot's posting.
The DECUS library sells to anyone (membership in DECUS is free and
nobody is that concerned whether you are or are not a member.) The
software in it (multiple gigabytes of software) covers a great many
machines, and is NOT, repeat NOT, limited to boxes DEC makes. You
won't find much systems code for, say, Unisys boxes in the DECUS
library, but applications that will run on Unisys boxes certainly
abound.
   The library is run by a staff, who are DEC employees.
   It has two basic virus/trojan resistant attributes.
   First, the submitter is ALWAYS known and recorded, and everyone
who gets software from the library (for which a production fee is
charged; the cost is NOT paying for the software, but is covering part
of the cost of running a fulltime library) has that name.
   What you get is a copy of what the submitter sent in. The production
machines aren't on any nets or outside hookups; this makes them
fairly resistant to penetration by ill-doers.
   Further, there's a central office with people who answer the phone.
When covert behavior of a program is detected, here's what happens:
  1. The program is pulled from further distribution.
  2. People are notified by whatever means are available (which these
	days will include the net) about the nature of the problem and
	all specifics that are known.
  3. Efforts are made if the program was otherwise useful to reset the
	covert behavior and distribute the cleaned-up one together with
	a complete analysis of what happened.

	Source code is usually available also.
	This happened only once so far where a program had a covert
time-out. The damage to someone's reputation when he submits a program
and suffers all the adverse publicity which we can and WILL produce
is such that there's not much incentive to try putting covert behavior
into programs going into the DECUS library.
	Besides this, a good many of us use the code and look for
"funny" stuff. It's not organized so that there's 100% coverage,
and we don't want to say there is coverage even where it exists in
too strong a form; we are after all human and don't want lawsuits by
someone who says we should have tested more. But there are paths for
reporting odd behavior and reacting to it. This applies to the sig
tapes also, which are produced and distributed outside the DECUS
library as well as contributed to it. Most funny behavior that's been
reported are version or site dependencies (which can be quite hard
for an author to detect) and we try to tell what we find. 
	In all, the path from author to recipient is probably shorter
dealing with DECUS library stuff or SIG tape stuff than it is for
most commercial software, and we won't and haven't concealed any
reported covert behavior; we are best protected by publicizing any
such as quickly and widely as possible. Be sure this list will get such
reports, as well as info-vax/comp.os.vms and, if we find a worm orv
virus, virus-l. 
	We do ask that people using the code help by reporting any
odd behavior. You can call the DECUS office (508 480 3418 will get
you into the office, though you'll need probably another extension
to which you can be transferred) or me (215 354 7610) (me for
sig tape info; the DECUS office for any, by preference) or Ted
Nieland (513 427 6355) for SIG tape info also. To the extent we
watch one another's backs, we're all the safer.
	Funny behavior in this case means suspected covert behavior
by a program. If you have a systems program written, say, for VMS
V4.7 and try running it on VMS 5.3-1 symmetric multiprocessors, you
should expect it to fail in many cases. We're more interested thee
there in what succeeds. However, timeouts, odd use of privs, 
writing files or modifying files that aren't documented, and the
like are of interest.
	I understand the concerns about trojans or viruses, but these
are probably more likely in commercial software than people realize.
Your path from the submitter to you is as short dealing with the DECUS
library as it is buying direct from a commercial vendor, and shorter
than if the software passes through a store or distributor. The DECUS
record of NOT concealing any problems is also public, and that
policy will ultimately protect you further.
   Glenn Everhart
VAX SIG librarian (DECUS)
Everhart@Arisia.dnet.ge.com
-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 90 18:18:42 GMT
From:      sson%remus.Berkeley.EDU%@RUTGERS.EDU (Stacey Son 377-4965)
To:        misc.security
Subject:   Re: Word Perfect Decryption

I have a friend who has a company that specializes in data recovery.
He markets a program that will recover crypted Word Perfect documents.
He also decrypts other programs such as Lotus, Microsoft Excel, etc.
You can reach him at the following address:

	Access Data Recovery
	% Eric Thompson
	87 E 600 S 
	Orem, UT 84058
	(801) 224-6970

-----------------------------------------------------------------------------
Stacey D. Son                         | "I think there is a world market for
Network Manager, Supercomputer Center | about five computers" -- Thomas J. 
Brigham Young University              | Watson, CEO, IBM Corporation, 1947
Dept. of Electrical/Computer Eng.     |
459 Clyde Building                    | "The number of UNIX installations has
Provo, UT 84602                       | grown to ten, with more expected." 
Voice:(801)378-5950 FAX:(801)378-6586 | -- UNIX Programmers Manual, 2nd 
Email: sson@ee.byu.edu                | Edition, June, 1972 
-----------------------------------------------------------------------------

END OF DOCUMENT