Conference noted::hackers_v1

Why does this remind me of one of the articles in the latest
IEEE Spectrum?  (The one about 'spread spectrum' and the
ultimate untappable secret radio.) They were doing similar
things, but with vinyl records rather than ROM's.  Their
solution was to use couriers and trust them. In any case,
their records were used exactly once, so if one got copied
only one conversation was compromised. Of course, this was a
low volume affair and you mentioned that you are after high
volume. 

One suggestion -- make the important part so that it cannot
be fixed (open one and you have only molten silicon).  
Although this prevents repair, it may help prevent system 
cracking for a while.  (You need more than 1 to figure out 
how to open without destruction -- but then again, with high 
volume, 'they' will probably be able to get a couple 
truckloads.)

Another suggestion -- make each ROM have an ID encoded in 
maybe 1024 bits.  Before believing it, make sure that (1) 
the ID is on your list of good ID's.  

Have a counter in the remote device which you bump at known 
times (just before signoff, perhaps).  Check the counter 
against what you think it should be.  Make this counter 
count not by 1 but by some apparently random value.  Use a 
recursive algorithm instead of counting.  (For example,
x(i+1) = (x(i) + 17) / 12.) 


Good luck, and don't tell us what you finally decide on.

Andy V

Interesting.  I've thought about what may be a similar problem with software
distribution; a privileged piece of software needs to determine whether an
update kit is valid, whether it should be applied or rejected.

I'm not sure I understand your problem.  I assume the ROM is connected to
a general-purpose computer which can read the ROM to check its validity.
I've made some assumptions, and rephrased the questions.

1.  In the field, how can the customer verify the bits stored on the ROM?
2.  How can the customer determine that an enhanced version of the ROM is
    available?  How can the customer verify the enhanced ROM?

    This requires getting some high-integrity information to the customer.
    Presumably, this can be gotten from the local field service office, by
    publishing the information in Computer World, the New York Times, Wall
    Street Journal, Reader's Digest, and usenet, by direct mailing, and by
    providing a toll-free number for the information.

A variety of solutions are then possible.  One is to simply make the contents
of the ROM public information.  Presumably, something less straight-forward
(and with lower band-width) is desired.

It is possible to cheaply verify the ROMs; much of the verification code can
even be put on the ROM itself! (if there aren't too many possible processors,
if a human attends to the verification, and if most of the computer's operating
system hasn't been subverted).

					- Gilbert

We did the following for DECtalk, which you might be able to adapt for
your needs:  When DECtalk is first powered up, it waits for text from
either the local or host rs232 ports OR for the phone to ring.  If
it ever receives a character from the local/host port, it drops any
current phone call and enters "normal" text-to-speech processing.
If a phone call comes in before anything from the host, it enters
a field-service diagnostics mode.  In this mode, it speaks the
code and dictionary rom build (version) dates.  (The power-up
self-test already did a checksum verification that the bits were
ok.)

If this thing you are building has (could have) an external port,
you could add a similar diagnostics mode and provide the customer
with a variety of test algorithms (and their answers) -- straight
additive checksum, xor checksum, crc-16, crc-32, etc.

You might also consider adding a truly random piece of hardware
that would cause a correct device to return -- randomly -- one
of a range of values, with the randomizer embedded in the value.
Your (source-distributed) test program would be able to check
the randomization.  The Unix password algorithm does this --
when a password is chosen, one of 4096 random encodings is
stored in the password file.

These suggestions are probably still insufficient.

Martin.

Additional details:

the entire operating system is on these ROMS.  there is no other rom code.

i like the idea of making the source or roms contents public.  But there is
no way of reading the roms from the outside world.
There is an rs232 port for input only.

question: if the "checksum" was made public, could fake roms be generated
to produce the checksum?

I'm sorry if I make this problem very general as I'm not to comfortable that
the public doesn't have access to this notes file (not that I'm parinode sp?-
but you know the new product type problems)
If you do have a question, I am monitoring this note.
I also don't see any reason why More hardware can't be added if there is a
hardware solution.
ed

Do these things communicate? (A rhetorical question only).

If they do, then part of the communication could be a challenge which
requires a particular response. The method of generating the response
should be some kind on encoding scheme based on the contents of the
ROM and the challenge given. Ideally, the potential 'cracker' can not
predict the particular response because until it happens, he doesn't
know the challenge.

The other thing to do is to make the thing as physically secure as
possible as in the previous response (.1 I think) where it was suggested
that it fuses itself. An adjunct to this is to seal the circuit in
epoxy which is difficult to get through without destroying it. Depending
upon the eventual use, it may be neccessary to introduce active 
anti-tampering. By this, I mean small explosive or incendiary devices,
however this would usually only be practical for military/government work.

Anyway these are just some ideas for you to play with. It may well be
best for you to talk to the customer's security people as they may have
their own ideas.

Good Luck,

Hugh

>My firmware goes into a physically secure box (complete with locks).  I blast
>my ROMs here in total safety and am satisfied that all is OK. two problems:
>
>1. when box reaches the field, how do I know that MY ROMs are installed in it?

	This one is easy!  Put your ROMs into the box under secure conditions
	and make it very difficult to open.  The security of the ROMs is only
	as good as the difficulty of opening the box such that it can be
	duplicated with new ROMs.  Those had better be GOOD locks.
>
>2. lets assume that my ROMs are in the field, but an enhancement (lord forbid
>   a bug) is needed.  How do I get my blasted set of ROMs out to the box.

	When you need to make a change, replace the entire box with a
	new, factory sealed box.  If the box is designed properly, you will
	be able to open it at the factory (and ONLY at the factory) and change
	the ROMs under secure conditions.

		-John A. Wasser

John (.6).  I like it. and we may have to go to something like it. however, 2

	problems with it.  #1 is quantity.  Right now we have a goal of 
	field service repairable.  Which means the boxes can be unlocked by
	the customer and fixed by field service.  

	#2: how do we know that the box we shipped is really the box that was
	recieved  (same problem as the roms- I gotta look up that IEEE article).
	We are not talking about your garden varity hacker.

yes the box has locks, yess it is bolted to the floor.
ed

The "challenge" seems a better solution than publishing the entire ROM.
This would hopefully be a small, public algorithm that would compute a
function: "response = f(challenge,ROM_contents)", such that only the valid
ROM contents will produce the expected response.  New challenge/response
pairs can be published every day or so.

See a previous note for comments on the security of CRCs.

It's also possible to use pre-determined challenge/response pairs (or,
equivalently, none at all), if a "trap-door" function is used.  That is,
if it's VERY difficult to find another ROM bit pattern that yields the
correct response.  I suspect such an algorithm would no longer be small.


Except for the fact that there's no port for directly reading the ROM
(presumably, the ports connect to some CPU inside the box).  If there were
such a port, you'd like a guarantee that you're reading the "real" ROM
(the box is probably big enough to hold two).

If the "standard" communication is with the CPU, and the CPU can't be trusted,
there's no way to be sure; CPUs can lie through their teeth.


An "unduplicatable" seal is a possibility.  For example, embed a dollar bill
in the plastic chip housing, and publish the (consecutive) bill numbers that
were used with the valid chips.

					- Gilbert

You might also want to discuss this problem in the SECURITY note file.
Although that file is not that much more secure than this file, it
will reach a wider audience of people interested in security issues.

Where is the security notes located?

wim

Wim's question has been answered.

Not to discourage any other answers, and I hope that I'm not going to,
I like Gilbert's last paragraph in .8.   Its simple and cheap.  Has 
anyone else heard or read of this implementation?  I'm leaning.....
thanks,ed

	On the challenge/response possibility...  How about taking a 
	generator of large random numbers that can be given a
	large seed to run one of a large number of checksum-like
	calculations on the contents of the ROMs... the ROMs being
	read in (pseudo)random order.  The results of the calculation
	must be dependent on both the entire contents of the ROMs
	and the order in which the ROMs were read.
		Build a small (cheap) sealed box to do the checking
	and give the customer a new sealed box (containing the
	new ROMs) every time there is a ROM change.  The user
	can call up a recording on a daily basis to get new keyboard
	input and expected output for the box... so they can be
	sure their box is actually checking!  The customer could
	then keep the box as secure as he wishes and check the
	internal ROMs as often as he likes.

		-John Wasser

	What about Execute Only ROMs? I read a few years back that
X-Only ROMS were being developed. The idea of the ROM was that if
references weren't amde in the proper sequence, then meaningless
data would be returned. I supposed a patient person could trace the
code. Anyone know any details of this unique ROM?

To repeat a point, the ROM is read to determine whether its contents are the
same as that of a known/public/correct ROM.  The idea of hashing the contents of
the ROM means that the contents of the ROM itself need't be made public; only
the hash value (which may depend on a "challenge"), and the hash function.

A "black box" to check the ROM provides a convenient place for subversions.
Namely, instead of reading the ROM it's intended to verify, it could read an
internal copy of a valid ROM.

This subversion will work until the (possible) ROM update.  A more sophisticated
"black box" could try to determine whether the ROM it's purportedly verifying is
a subverted ROM (indicated by a special bit pattern somewhere on the ROM), and
would read the installed ROM only if necessary to keep from being "found out".


Although intrigued by the idea of an "execute only" ROM, I don't see how it's
applicable here.


Another "too expensive to duplicate" solution is to provide a ROM with a very
exotic shape, which could be verified visually.  Of course, this depends on how
valuable a subversion is to the hacker.


A "too simple to subvert" solution is to build much of it out of "off-the-shelf"
components.  The customer would or could supply his own CPU, et al.  Presumably
it's too expensive to subvert all of Radio Shack's parts (as it's too expensive
to tap all phone booths in New York).  Also, this might absolve DEC against any
damages incurred by subversions.

					- Gilbert

re:4
Am I right in understanding that the ROMS (PROMS?) are blasted when installed
in the sealed box?

If so you have some problems already.....firstly you'd need a prom programmer
that doesn't need to verify each location because you state that the RS232
port is read only and the proms cannot be read externally.

Also if the proms are blown by external connection to the box then you've
donated a potential hacker a free interface.....he could program locations
not previously programmed, and conceiveably alter locations already programmed
while this may not "subvert?" the box it may well stop it functioning as intended, you can decide whether that's a worth while goal.

If the box is openable by he customer then let him worry about security of
the operational firmware.....you issue the customer with a plug in prom/rom
set in person once he has his firmware module he looks after ensuring it
gets into the box and more importantly stays there.

Let each rom be a message and issue a series of "start-address, key, response"
challanges using a publicly available encryption, such as DES.
(Or, let each rom be a key and issue a "start-address, message, response"
challenge.)  The customer extracts the information from the ROM by
purchasing a commercially available PROM blaster.  These can be
used to transfer ROM/PROM contents to a host computer.  Issue all
the challange/response software (including upload programs) in source
form.  Now, the criminal must be able to subvert not only Dec equipment,
but also non-Dec hardware.  Furthermore, the customer has the opportunity
of sight-verifying the verification software.

Martin

Re: 16.

	Thanks for the perspective.

Re: 1/2 of 13, 18, 2/3 of 19.

	Thanks for restating the previous suggestions, and for the
	errors (to keep us readers on our toes, right?).

Re: 1/2 of 13, 1/3 of 19.

	Thanks for the additional suggestions for physical "signatures".

re: .19
There is a problem with the second method I proposed - so much for composing
security algorithms at the keyboard!  To whit:  I suggested that you could,
even if the interface you USED was a simple RS232 request/response kind of
thing, provide a different interface that would let someone read the actual
contents of the chip, perhaps encrypted.  This kind of approach has a funda-
mental problem:  It makes the assumption that the code you read through this
window is the same code as is executed for the RS232 port.  This may be a
valid assumption for the REAL chip, but you have no reason to believe it holds
for the fake one!  A fake chip may contain the real chip connected to the
"verification" port, and have some entirely different circuit feeding the
"usage" port.  Signatures are only useful if they cannot be separated from
the thing they are supposed to be signatures FOR.
							-- Jerry

{This message was corrupted - notice the "56664 lines" - here is all I could
salvage.  <_Jym_>}

================================================================================
Note 61.19                     Help from a hacker?                      19 of 21
RANI::LEICHTERJ                                   56664 lines   3-OCT-1984 08:37
--------------------------------------------------------------------------------

It still isn't clear to me just what kind of problem is being proposed here,
or why we are looking for an electronic solution when there are much simpler
physical solutions.

Suppose you sent out the code on a tape, or over a net, rather than on a ROM.
The problem then is exactly that of digital signatures:  How does the receive
KNOW that YOU sent he message, not an interloper?  There are plenty of solutions
to this in the literature, some even practical.  (Probably the simplest of the
latter is to do some sort of encryption, using DES, of the message.  You
fold the message back on itself - e.g., take first 8 bytes, encrypt, use
result as key on next 8 bytes, etc.; final result is "signature".  Send
signature and key to customer using a private, secure channel.  WARNING:
THIS PARTICULAR METHOD OF GETTING A SIGNATURE IS CONJECTURAL.  There are
techniques like it that are thought to be good; there is one the banks are
thinking of using.  I made this one up while typeing; DON'T use it.  Note,
of course, that you need send the key privately only once; the signatures
on updates, and even on the original, can be published.  You can also
"send the key" as a piece of hardware - a sealed DES chip + ROM + small CPU.
There are techniques for physically sealing such devices that are considered
tamper-proof.  DON'T just make one up without checking into the current
state of the art, though!

To return to the original problem:  You are sending out, not tapes, but ROM's.
You can, of course, check them the same way as the tapes; in fact, you could
provide the "key hardware" described above with space to plug in a ROM.
Unfortunately, this requires that the ROM contents be readable.  One way
around this is to provide a port that provides direct access to the ROM - but
sends out the words encrypted with a key that only you know.  This key, too,
is built in to the verification box.  The box never reveals either key to
anyone, either through a programmed interaction or "under torture", i.e.,
physical disassembly.

HOWEVER, all this seems like a hard way to solve a much simpler problem.
What you want is to be able to tell that a PIECE OF PHYSICAL HARDWARE,
the ROM update, really came from who it claims to have come from.  This is
an old, old problem with many PHYSICAL solutions.  What you need is some
kind of physical attribute or marking that only you can produce, but anyone
can recognize.  Further, that physmed interaction or "under torture", i.e.,
physical disassembly.  HOWEVER, all this seems like a hard way to solve a much
simpler problem.  What you want is to be able to tell that a PIECE OF PHYSICAL
HARDWARE, the ROM update, really came from who it claims to have come from.
This is ROM . . .

{This is where the message was chomped.  <_Jym_>}

    Some time later...
    
    The book `Battlefield Earth,' by L Ron Hubbard, described an
    interesting concept in physical security.  Basically, a secure box
    had all closures connected to `magnetic fuzes.'  If the closure
    was opened, the fuze would blow, slagging the box contents, unless
    there was a magnetic field of particular properties present, and
    the atmospheric pressure was just right.  Now, the latter doesn't
    seem very workable under field conditions, but you might do something
    with the former - perhaps a tiny xmitter the F/S tech took with
    him and left turned on in his toolkit.  If the xmission wasn't being
    received when the box was opened, SLAG!!
    
    Another interesting concept the book described, and which may be
    useful to SOMEbody or other, was a material which was used wholesale
    for insulation, but which could be made conductive under certain
    conditions.  (Basically, you could trace the equivalent of an etch
    pattern on a piece of bakelite with the right tool.)  The visible
    circuit would perform a totally different (and perhaps even useful)
    function, but the invisible circuit built into the insulating board
    would be needed for proper operation.
    
    #ken	:-)}