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 (1987)
DOCUMENT: Rutgers 'Security List' for January 1987 (20 messages, 13973 bytes)
SOURCE: http://securitydigest.org/exec/display?f=rutgers/archive/1987/01.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
From:      dplatt@teknowledge_vaxc.ARPA (Dave Platt)  2-Jan-1987 20:52:41
To:        risks@csl.sri.com, security@rutgers.rutgers.edu
There's an interesting article in the 1/87 issue of Radio-Electronics
which states that the Videocipher II television-scrambling system has
been cracked.  As Videocypher depends in some part on the DES
cyphering algorithm, this may have some major implications for
computer-system security (if it's true).

According to the article, "perhaps as many as several dozen persons or
groups have, independent of one another, cracked Videocypher II and we
have seen systems in operation.  Their problem now concerns what they
should do with their knowledge."

As I recall (and I may well be wrong), M/A-Com's Videocypher II system
uses two different scrambling methods: the video signal is passed
through a sync-inverter (or some similar analog-waveform-distorter),
while the audio is digitized and passed through a DES encryption.
Information needed to decrypt the digital-audio is passed to the
subscriber's decoder box in the one of the "reserved" video lines.
The actual decryption key is not transmitted;  instead, an encyphered
key (which itself uses the box's "subscriber number" as a key) is
transmitted, decrypted by the decoder box, and used to decrypt the
audio signal.

I've heard that it's not too difficult (in theory and in practice) to
clean up the video signal, but that un-DES'ing the audio is supposed
to be one of those "unfeasibly-difficult" problems.

I can think of three ways in which the Videocypher II system might be
"cracked".  Two of these ways don't actually involve "breaking" DES,
and thus aren't all that interesting;  the third way does.

Way #1:  someone has found a way of assigning a different "subscriber
number" to an otherwise-legitimate M/A-Com decoder, and has identified
one or more subscriber numbers that are valid for many (most?)
broadcasts.  They might even have found a "reserved" number, or series
of numbers, that are always authorized to receive all broadcasts.

This is a rather minimal "crack";  the satellite companies could
defeat it by performing a recall of all subscriber boxes, and/or by
terminating any reserved subscriber numbers that have "view all"
access.

Way #2:  someome has found a way of altering a decoder's subcriber
number, and has implemented a high-speed "search for valid numbers"
circuit.  This could be done (in theory) by stepping through the
complete set of subscriber numbers, and looking for one that would
begin successfully decoding audio within a few seconds.  It should be
pretty easy to distinguish decoded audio from undecoded...

This way would be harder for the satellite companies to defeat;
they'd have to spread the set of assigned subscriber numbers out over
a larger range, so that the search for a usable number would take an
unacceptable amount of time.

Way #3: someone's actually found a way of identifying the key of a DES
transmission, with (or possibly without) the unscrambled "plaintext"
audio as a starting point.

This I find very difficult to believe... it would be difficult enough
for one person or group to do, let alone "perhaps as many as several
dozen... independent" groups.  Naturally, this possibility has the
most severe implications for computer-, organizational- and national
security.

I suspect that the reported "cracking" of Videocypher II is a case (or
more) of Method #2, and thus doesn't have immediate implications for
the computer industry (I think).

Has anyone out there heard of any other evidence that DES itself has
been cracked?

-----------[000001][next][prev][last][first]----------------------------------------------------
From:      dplatt@teknowledge_vaxc.arpa (David Platt)  6-Jan-1987 13:49:23
To:        risks@csl.sri.com, security@rutgers.rutgers.edu
I just got a copy of the 2/87 issue of Radio-Electronics, which
contains brief descriptions of several of the systems that have
"cracked" the VideoCypher II scrambling system.

The systems described are all "software" approaches that fall into what
I described as "way #1"... they work by cloning copies of an authorized
subscriber number.  At least one has found a way to crack the "tiered
distribution" feature of VideoCypher, thus permitting someone who has
paid for only one service to successfully view several others.

None of the systems described so far actually involve a "cracking" of
DES itself... they're all methods of copying an existing (valid) key
from one decoder to another.  It appears that the MA-Com folks did take
some steps to conceal the subscriber number information (which
generates the actual key dynamically, I believe), but that their steps
were not sufficient.  Apparently, the subscriber-number is stored in
the battery-backed RAM in a small TI microprocessor, and there's no
direct way to query it; during operation, though, it's apparently
possible to trace the signals on some of the micro's pins and "catch"
the subscriber number as it flys by.  Someone has found a way to do
this and to "download" the number into the micro in another decoder...
thus permitting the "cloning" of an authorized number.

So, the vulnerability of the VideoCypher II system appears to boil down
to the fact that its "innards" aren't sufficiently guarded against
probing and/or modification.  If, for example, the box had been
provided with a cover-removal switch that would signal the micro to
erase its subscriber number, it might have been more difficult to
"crack".

A description of several "hardware" approaches is promised for next
month.  I'll summarize once I get my hands on an issue.
-----------[000002][next][prev][last][first]----------------------------------------------------
From:      C. P. Yeske <CY13@TE.CC.CMU.EDU>  9-Jan-1987 12:57:53
To:        security@rutgers.rutgers.edu
I found this on the tops-20 digest and thought it would be interesting.

Curt
cy13@te.cc.cmu.edu

                ---------------

Date: Wed 7 Jan 87 23:36:50-PST
From: Mark Lottor <MKL@SRI-NIC.ARPA>
Subject: CRYPT part II
To: tops-20@SCORE.STANFORD.EDU

Well, I had this diary of sorts that I had spent two years working on,
from around '82-'84.  I hadn't made an entry in a few months, and
when I went to decode the file I found that I had forgotten the
password.  So, last week I thought I'd do something about it.

I got the sources to the CRYPT program and I hacked it up to
try every single key.  I figured it might run for 5 or 10 years
but I wasn't in a hurry.  The key was 71 bits, but I found
what may have been a bug that reduced it to only 35.  This
computed to only about 200 days.  I tried a test case with
a simple key, and was a bit surprised when it was decoded in
about a minute.  So, I fired up the batch job that was going
to take all year to complete.  But it finished a minute later!
Yes, it was decoded.  No, it didn't try every key.  Hardly any
matter of fact.  I don't know how the algorithm was supposed to work,
but it appears that lots of keys are "equal" to each other.

I have found that I can decode any text file in about a minute.
This is using the CRYPT program (NCRYPT.FAI) that writes out
the coded file in a format like:

;crypt
ahdsj jhaud oiqmn djdud djsau kasia zajza husdh
;end

Just a warning to anyone using it;  it's worthless.

Now the questions:
Was it known this program was so bad?
Is there a good crypt program for Tops-20?  One that's been tested?

Mark
-----------[000003][next][prev][last][first]----------------------------------------------------
From:      *Hobbit* <AWalker@RED.RUTGERS.EDU>  13-Jan-1987 23:30:17
To:        security@RED.RUTGERS.EDU
Contrary to recent evidence, or lack thereof, the Security list is still
alive.  A number of random impediments to progress prevented me from
re-sending the queued mail for quite a while, including

Being horrendously busy building laser equipment

Stumbling across a strange and crippling bug in MM and having to work around
it myself with little or no support from those familiar with the code

The big Bitnet shakeup and re-ordering, during which all the Bitnet
recipients were moved to local redistributions and all internet list
maintainers had to learn how to deal with LISTSERV

The usual Christmas/holidays lossage

Being in DC for a week with no local network access [UMD was cut off]

Any number of other excuses I can come up with

I however *have* kept up with list maintenance requests and have been keeping
things therein current.  Now that things have settled down somewhat, the normal
flow of Security mail will resume.  A couple of other improvements have been
made as well; useless headers will now be stripped out before remailing and
right-widgeted message inclusions severely trimmed.

Note to Bitnet people: Some of you were receiving digest-format messages.
With the exception of one site [barilan] who requested specifically to remain,
I have moved *all* Bitnet recipients to the LISTSERV mechanism at UGA.  If you
were receiving digest format messages and can't bear to have it any other way
please send me a note and I'll fix your feed, but keep in mind it's just that
much more network bandwidth taken up at Wiscvm.  If there is sufficient demand
I'll arrange to have a separate digest distribution at UGA set up.

Thus, if you're looking for archives for December/January, there aren't any.

_H*  [security-request@rutgers]
-----------[000004][next][prev][last][first]----------------------------------------------------
From:      <SYSTEM%CRNLNS.BITNET@WISCVM.WISC.EDU>  16-Jan-1987 11:40:48
To:        security@red.rutgers.edu
I just received the following message via the TCP-IP mailing list.
I would appreciate it if you would please forward this to anyone
who might be affected.

Thanks,

Selden E. Ball, Jr.

Date: Thu, 15 Jan 87 12:41:43 PST
From: Dan Kolkowitz <KOLK@NAVAJO.STANFORD.EDU>

There has been another rash of breakins on the Internet.
We've noticed the SUN
release includes a number of unpassworded special accounts in the
default  /etc/passwd  file.  Breakins have occurred on at
least one of these.  You may want to set
the password for these accounts of disable them.
        Dan Kolkowitz
        Computer Science, Stanford

-----------[000005][next][prev][last][first]----------------------------------------------------
From:      Joseph I. Herman (Joe) <DZOEY@UMD2.UMD.EDU>  16-Jan-1987 15:17:55
To:        security@red.rutgers.edu, warnock%clemson.csnet@relay.cs.net
Doing a promiscous listen on ethernet is a function of twiddling a bit
on your ethernet port.  For the 3com board used in PC's, just can instruct
the board to show you all traffic by setting a bit when you tell the board you
want to listen (I don't remember which bit it is, it's documented.  If there
is a demand, I'll look in our code.)  There are two ethernet monitors that
I know of off hand.  Excelan's Lanalyzer (or something like that) and
the NETWATCH program out of the PC/IP stuff.

For IBM token ring it is not possible to do promiscuous receives using
the IBM boards.  However, if you're determined, TI sells a board that
will do promiscous receives.  However the board is 1) expensive ($1500) and
2) Does not understand 802.2 so you'd have to do all your decoding yourself.
I know of no market available token ring monitoring program.

I hope this helps.  We've found NETWATCH to be very very helpful for debugging
network programs

                           I'm routing that packet to where????
                                Oops.

                               Joe

Replies to either DZOEY@UMD2.UMD.EDU or DZOEY@TERMINUS.UMD.EDU

P.S.  Of course, the boards all detect whether you want promiscous
      receives for good or evil purposes and disallow any unethical usage :-)
-----------[000006][next][prev][last][first]----------------------------------------------------
From:      <SYSTEM%CRNLNS.BITNET@WISCVM.WISC.EDU>  21-Jan-1987 14:46:23
To:        SECURITY@RED.RUTGERS.EDU
Todd,

You recently asked via the SECURITY mailing list

>[...] I saw mention of a
>$SET WATCH command with VMS ...  Where did it come from ?

A query to the INFO-VAX mailing list would have been more appropriate:
the SET WATCH command was revealed there last September.
Maybe you confused the two lists?

I'm not quite certain how to interpret your question: are you
asking whence the SET WATCH command, or whence the information
about the VMS implementation?

At any rate, the SET WATCH command itself has (had) a long and
illustrious history on DEC's Tops-10 systems (Tops-20 too, I suspect).
The user could use the SET WATCH command to set flags so that the
"monitor" (operating system) would display all sorts of useful info every
time a program or command started and exited: time of day, elapsed cpu and
real time, .exe file origin (it could be persuaded to display a message
every time a shared segment was loaded, for example), disk and magtape i/o
counts, and file name and i/o type whenever a file was opened. Much of this
information was also available by typing a control-T or the USESTAT command.

(My comments are in the past tense because our DEC-10 was replaced by
8600s last year. I understand that there are a few lucky sites still
running them, though.)

The VMS implementation of SET WATCH currently only supports the display
of file i/o information. (VMS's form of control-T is similarly limited
in functionality compared to the Tops-10 version.)

SET WATCH is not a "supported" command: there is no published
information about it. What is known has come from intrepid explorers
who have used the VERB program to dump the contents of the distributed
DCL command table file:

The syntax of the command is:

    $ SET WATCH FILE/CLASS:(option1,option2...)

The following options are available:

    ALL
    ATTRIBUTES
    CONTROL_FUNCTIONS
    DIRECTORY_OPERATIONS
    DUMP
    ATTACHED
    MAJOR_FUNCTION
    NONE
    QUOTA_LENGTH

You can make this command generally available on your system by
installing the image SYS$SYSTEM:SETWATCH with the CMKRNL priv.

I hope that this brief discussion has been some help.

Selden E. Ball, Jr.

Cornell University                 NYNEX: 1-607-255-0688
Laboratory of Nuclear Studies     BITNET: SYSTEM@CRNLNS
Wilson Synchrotron Lab              ARPA: SYSTEM%CRNLNS.BITNET@WISCVM.WISC.EDU
Judd Falls & Dryden Road          PHYSnet/HEPnet/SPAN:
Ithaca, NY, USA  14853             LNS61::SYSTEM = 44283::SYSTEM (node 43.251)

[Thanks also to Dan Cottler at RCA for a similar but less in-depth msg.  _H*]
-----------[000007][next][prev][last][first]----------------------------------------------------
From:      davy@ee.ecn.purdue.edu (Dave Curry)  22-Jan-1987 08:23:49
To:        dca-pgs@ddn1.arpa
Cc:        security@red.rutgers.edu
Yes, Gould has a C2 UNIX.  It was certified last year (October?), I
believe.  Basically, the most significant thing they did was remove
the set-uid bit.  There's also a bunch of "tracing" stuff in the
kernel, but I'm not sure exactly what is and isn't traced.

There was an item on USENET about three months ago about UTX/32S...
apparently they had a demo system at a trade show and were challenging
people to break in.  Prize was a TV set.  One guy broke in by noting
that the super-user account had the current directory in its search
path (mistake number one).  He wrote a little program, talked the
trade show guy into running it as super-user, and poof, he was in.

The stink arose because Gould refused to give him the TV set, since he
had not "played by the rules".  (They have since given him the set.)
The community was less than impressed by this, and slammed Gould
pretty hard on USENET...  Gould ended up sending this complete drivel
about "he had to convince the super-user to unwittingly help him, since
he realized immediately the system was otherwise unpenetrable" and other
factually void statements.

Finally they issued another challenge -- a TV and a VCR to break in.  Some
of us took them up on the challenge (they still have not gotten back to
us telling us when and where we get to try... I think it was a ruse),
others thought "if all you're willing to put up is a TV and VCR you must
not be too confident.  Try putting up $20,000 so it's worth our time."

Anyway, having had more than enough experience with Gould's alleged
software expertise, I'd be more than a little wary of UTX/32S without
taking a real good look at it first.

--Dave Curry

These opinions are solely my own and not my employer's and all that crap.

-----------[000008][next][prev][last][first]----------------------------------------------------
From:      davy@ee.ecn.purdue.edu (Dave Curry)  22-Jan-1987 09:00:42
To:        security@red.rutgers.edu
This was a reply to sullivan@ddn1.arpa and rsc@umix.cc.umich.edu, but
I managed to screw up the security list's address...

-----
        "C2"?  Really?  From what I know, "C2" doesn't mean a whole lot more
        than changing the default file/device permissions to a 'none group,
        none others' sort of thing.  Big deal.

No, you're thinking of C1... from the Orange Book:

        C1:
                - discretionary access control
                - identifcation and authentication
                - assurance of:
                        - system architecture
                        - system integrity
                        - security testing
                - documentation of
                        - security features user's guide
                        - trusted facility user's manual
                        - test documentation
                        - design documentation

        C2:
                - everything in C1, but at increased levels 
                - object reuse (guarantee no data from last
                  user of object left in object)
                - audit

Granted, C2 isn't a whole lot more complicated when you get right down to
it...

--Dave Curry

-----------[000009][next][prev][last][first]----------------------------------------------------
From:      dplatt@teknowledge_vaxc.ARPA (Dave Platt)  22-Jan-1987 13:15:23
To:        ST802414@BROWNVM.BITNET
Cc:        Security@Red.Rutgers.Edu
This depends very much on the environment in which the computer is to
be used, on the operating system, and on the degree of security that
you require.

For simple protection, you may be able to depend on built-in security
and access-control features in the computer's operating system.  Unix,
for example, has a three-level * three-privilege access control scheme,
which can be used to keep nosyparkers out of private data.  It can be
cracked, however, if someone can boot the privileged diagnostic package
and read the disk directly (or log in as "root").

Harder-to-crack protections (e.g. software protection) might be
implemented in a number of ways.  Several firms make software that can
be used to password and/or encipher the data on portions of a disk.  I
believe that Borland (vendors of Sidekick) sell a "safe-disk" utility
that enciphers data in a directory hierarchy;  I believe that it does
so by inserting itself into the device-driver path and ciphering data
during writes (and deciphering during reads).  Without the cipher
password, the data is unreadable (I believe that DES is used).

Other vendors sell similar products.  At the MacWorld expo earlier this
month, I saw a product ("MacSafe"?) that protects Macintosh disks
similarly.  It supplies both a nested-password scheme for locking
files, and a DES cipher.  Based on a conversation that I overheard
while hanging around the booth, the password scheme can be bypassed by
using a disk-sector editing tool such as FEdit (the files are simply
hidden from normal access), but the DES-ciphering is as robust as DES
itself (i.e. if you don't have the key, it'll take many moons to read
the data).

Protecting data against erasure is trickier.  You might be able to
depend on the operating system's access-control features to prevent an
existing filesystem from being modified by programs running in the
normal user environment.  To protect the data against modification by
diagnostic or stand-alone programs, you'll probably have to physically
disable the drive's ability to write new data.  Some drives have a
write-protect switch;  such a drive could be placed in a locked cabinet
next to the computer and used in a read-only mode.  If you have a drive
that has no such switch, you'll have to hack the interface between the
computer and the controller (or between the controller and the drive),
thus preventing the drive from ever seeing a "write data" order.  This
is nontrivial and should be delegated to someone who REALLY understands
the hardware.

You could, of course, copy the data from a conventional (Winchester)
hard disk to a WORM (write-once, read-many) optical disk, and then
leave the WORM copy on-line.  Or, for ultimate "no modification"
security, have the data transferred to a ROM optical disk (CD-ROM)...
expensive, but pretty secure against modification.

To meet your "for instance" (protect from erasure or access)
absolutely, there's only one way... DISCONNECT the drive from the
computer, LOCK IT UP in a physically-secure area, and don't give ANYONE
the keys!  If a drive is on-line or physically accessible, then you
must assume that someone with sufficient expertise and time will
probably be able to crack or destroy its contents.

                Dave Platt
Internet:       dplatt@teknowledge-vaxc.arpa
Usenet:         {hplabs|sun|ucbvax}!dplatt%teknowledge-vaxc.arpa
Voice:          (415) 424-0500
USnail          Teknowledge, Inc.
                1850 Embarcadero Road
                Palo Alto, CA  94303

The best book on programming for the layman is "Alice in Wonderland";
but that's because it's the best book on anything for the layman.
-----------[000010][next][prev][last][first]----------------------------------------------------
From:      obrien@rand_unix.ARPA  23-Jan-1987 13:53:33
To:        dplatt@teknowledge-vaxc.arpa (Dave Platt)
Cc:        risks@csl.sri.com, security@rutgers.edu
	Traffic in the Usenet newsgroup "net.video" implies that it was
done with your "way #1", i.e. someone found a trapdoor in the decoder
box that allows insertion of a new "subscriber number".  I didn't even
hear anything to the effect that a high-speed search is used.
-----------[000011][next][prev][last][first]----------------------------------------------------
From:      Michael Grant <mgrant@mimsy.umd.edu>  24-Jan-1987 20:38:19
To:        risks@csl.sri.com, security@rutgers.edu
>David Platt notes:
>If, for example, the box had been provided with a cover-removal switch that
>would signal the micro to erase its subscriber number...

Always best to eliminate the problem by redesigning that part in the
next generation of the cypher so that such important numbers as that
never leave the internals of chips.  At that point, it becomes much
more of a pain to probe than it may be worth, but...not entirely impossible.
-----------[000012][next][prev][last][first]----------------------------------------------------
From:      Douglas Humphrey <deh@eneevax.umd.edu>  25-Jan-1987 14:45:07
To:        dplatt@teknowledge-vaxc.arpa, risks@csl.sri.com, security@rutgers.edu
>Way #3: someone's actualy found a way of identifying the key of a DES
>transmission, with (or possibly without) the unscrambled "plaintext"
>audio as a starting point.

Note that they can easily have the plaintext, since the best way to
start experimenting on breaking something is to have two devices
there, one subscribed and authorized, and the other not. That way you
have (subject to trivial timing differences which can be ironed out)
two streams of data to play with, and you really are just trying to 
make one look like the other. 

On another note, does anyone know of any good spectrum analysis 
software available for cheap to work with reasonable priced A/D
converters ? There are a number of companies that sell the hardware
required to eat signals, but most of the software that I have seen
for actualy analysing the data is pretty weak. Maybe I'm just not
in touch with the right companies...

Thanks
Doug
-----------[000013][next][prev][last][first]----------------------------------------------------
From:      crash!pnet01!adamsd@nosc.ARPA (Adams Douglas)  26-Jan-1987 12:00:43
To:        crash!security@rutgers@nosc.arpa
I have a PC-AT here at my office which gets frequent remote use through
dialup. My office is a cubicle with no physical security save some lockable
cabinets. I don't do classified work, but I would like some confidence in
leaving the machine up and running over weekends. The basic problem is that
when I leave my phone-line monitor running I cannot use the key lock on the AT
as the program occasionally will recover from bad errors by doing a warm-boot.
If the keyswitch is locked, the warm-boot will not complete and I am down for
the rest of the weekend.

Is there a simple way of insuring the machine's security without inhibiting
its dialup use under these circumstances? I thought of removing the keyboard
and locking it up, but a determin{ed person could swipe a keyboard from
another machine here (or bring their own). Encrypting every file on the
machine is something I would like to avoid.

Helpful ideas would be welcome.
-----------[000014][next][prev][last][first]----------------------------------------------------
From:      Jim Aspnes <asp@ADAM.PIKA.MIT.EDU>  26-Jan-1987 16:52:20
To:        barnett%vdsvax.tcpip@ge-crd.arpa
Cc:        SECURITY@RED.RUTGERS.EDU
Setuid csh scripts are dangerous, because on many implementations of
Unix the csh which executes them can be tricked into believing that it
is a login shell by exec'ing the script with argv[0] set to "-".  I
believe this has been fixed in Ultrix; I know it has been fixed in
4.3.

The problem with popen() and system() was that both calls used /bin/sh
to parse their arguments, and this shell inherited the IFS environment
variable from its parent.  By setting IFS to, say, "/", one could turn
a call to /bin/mail into a call to bin, which could be a trojan horse
of one's choosing in the current directory.  4.3 sh clears IFS on
startup, eliminating the problem.

The best loophole-finding program I know of is KUANG, written by Bob
Baldwin <baldwin@xx.lcs.mit.edu>.  It does rule-based search to find
paths of attack to gain arbitrary objective (e.g., becoming root, or
obtaining permission to write to a particular file.)  You may want to
ask him if he's willing to distribute it.

Jim Aspnes <asp@athena.mit.edu>
-----------[000015][next][prev][last][first]----------------------------------------------------
From:      pnet01!brock@nosc.ARPA (Brock Meeks)  27-Jan-1987 22:26:36
To:        crash!security@rutgers@nosc.arpa
The following message has been ported from BYTE's electronic
network.  The author is Rick Cook.
    I thought all you DES devotees would be interested.
 
 =-=-=-=-=-=-=
 
TITLE: Three Claim Breaking of DES-Based Scrambler
 
The Videocypher II scrambling system, which uses the government-
backed DES encryption algorithm to protect satellite television
signals, has apparently been broken by no less than three
different groups using different approaches. At a "scrambling
summit" in the British West Indies recently, three groups
demonstrated ways of cracking the system, which its manufacturer
and major users promote as uncrackable. The video signal is only
lightly scrambled using conventional analog techniques.
   Because the DES algorithim is so secure, cracking the signal
has been considered beyond the abilities of anyone without the
resources of a government or major corporation. None of the three
groups broke the DES algorithim directly. Instead they attacked
the hardware inside the descrambler to get at the firmware that
runs the descrambler. M/A-COM engineers had cut one of the
control pins off the unit's microprocessor to thwart such
attacks. One group reattached the pin with a laser micro-welder.
Another used a combination of out-of-spec voltages and clock
speeds to deduce the firmware. A third group said it found a flaw
in a key IC.
   M/A-COM says provisions built into the Videocypher II can foil
crackers. For example, each descrambler has several additional
keys that can be activated from the satellite uplink station.
However, the presenters at the conference claimed that for every
countermeasure there is a possible counter-countermeasure -- a
contention borne out by the history of software copy-protection.
                                 --Rick Cook
 
 =-=-=-=-=-=-=-=-=

People against needless garbage at message end.

                                                --Brock Meeks
-----------[000016][next][prev][last][first]----------------------------------------------------
From:      *Hobbit* <AWalker@RED.RUTGERS.EDU>  29-Jan-1987 19:59:32
To:        security
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Date: Thu, 22 Jan 87 18:08:40 EST
From: ELKINS <relkins@vax1.acs.udel.edu>
Subject: Re:  hard drives

I believe that there are some hard drives for the ibm, that are password
protected.  ie, a password must be given to the hard-drive controller before
it will boot the drive.  There are also some control systems that exist for
the IBM-pc series...Another security feature is a lock for the hard drive
which requires a key to be inserted for the drive to operate.  I believe
that the IBM AT's have this feature...

Rob Elkins
relkins%trillian@udel-relay

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

Date: Thu, 22 Jan 87 15:53:46 EST
From: Michael Grant <mgrant@mimsy.umd.edu>
Subject: Re:  hard drives

There is a card that can be had which encrypts everything on the disk.
A password is required to get into it.  It seemed fairly secure.
Jeez, I saw it at some random security show.  They were giving out
some very large sum of money for anyone if they could crack it.

I wish I could provide more info on it, but it was a long time ago.  As I
remember, it was a disc controller in the back of a PC.  When you powered
up it would ask for a password.  Otherwise, no reads or writes.

If this is what you are looking for, I suggest you go to the next
ComSec in Washington, or your local security conference.

-Mike Grant

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

From: siggy@aim.rutgers.edu
Date: 22-Jan-87 20:38:16 EST
Subject: hard disk security

Christopher Chung asked if there was a method of securing a hard disk in a
publicly accessable microcomputer.  If the beast is an IBM PC or really close
clone there are a number of commercial software packages which will do the job
quite nicely.  The two which come to mind are The WatchDog by ?? and  The
Knight by AST.  The AST product costs somewhat under $200 but it does really
work.

send mail direct if you really want me to find the literature on WatchDog.

cheers
/S*
siggy@aim.rutgers.edu
latzko@topaz.rutgers.edu
backbone!rutgers!topaz!latzko

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

Date: Sun, 25 Jan 87 12:45:50 PST
From: Derek_Isobe%SFU.Mailnet@umix.cc.umich.edu
Subject: hard drives

I have such a password program in basica. It asks for a password
on h/d boot and kills the system if it does not receive the right pw.

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

Date: Sun, 25 Jan 87 13:00:57 EST
From: Simson L. Garfinkel <simsong@MEDIA-LAB.MEDIA.MIT.EDU>
Subject: hard drives

I assume that you mean a "hard drive" on an IBM PC/clone/AT kind of
computer.

The easiest way to keep a hard drive from being accessed is to
physically remove it from the computer. With removable media hard
drives and Bornelli boxes, this is a practical solution.

There isn't any other way to keep people from accessing a hard drive.
You can encrypt the data on the disk, however.

				Simson L. Garfinkel
				MIT Media Lab
-----------[000017][next][prev][last][first]----------------------------------------------------
From:      ROY MILLER <qseclry%gitpyr%gatech.csnet@RELAY.CS.NET>  30-Jan-1987 10:19:27
To:        security@RED.RUTGERS.EDU
I believe Government Computer News, July 18, 1986, contained an article about
Oracle and the DOD orange book security compliance. If anyone has any
information on this that they could send me I would appreciate it.

Thanks
Stewart 

-----------[000018][next][prev][last][first]----------------------------------------------------
From:      William_Allen_Doster@um.cc.umich.edu  30-Jan-1987 17:14:27
To:        AWALKER@RED.RUTGERS.EDU
One way to secure your machine might be to just replace *all* the keyboard
related interrupts with pointers to IRets.  Then you wouldn't have to remove
the keyboard but no-one would be able to do anything.  You could also have
another program to restore the keyboard interrupt vectors, and remotely
run it just before coming back in to work.  Not sure how you would prevent
someone from power-cycling it to undo these changes, though.
-----------[000019][next][prev][last][first]----------------------------------------------------
From:      astrovax!princeton!allegra!amdcad!bandy@caip.rutgers.edu (Andy Beals)  30-Jan-1987 18:14:27
To:        red.rutgers.edu!security@caip.rutgers.edu
Well, if you have a big enough cabinet, you could lock the whole computer
within it; however, you would have a big cooling problem if the cabinet
wasn't big enough or your cubie didn't stay cold enough (you could knock
some holes in the cabinet and put some muffin fans in it).  

If you cannot leave it in the cabinet, I'd say that there isn't much you can
do about it; but why be paranoid?

END OF DOCUMENT