Re: Sun - Too visionary?

In comp.lang.java.advocacy, Roedy Green
<my_email_is_posted_on_my_website@xxxxxxxxxxxxxx>
wrote
on Wed, 16 Nov 2005 20:00:04 GMT
<ai3nn15mrh4k9uosjtljbbpvhp7ak40s3j@xxxxxxx>:
> On Wed, 16 Nov 2005 18:00:04 GMT, The Ghost In The Machine
> <ewill@xxxxxxxxxxxxxxxxxxxxxxx> wrote, quoted or indirectly quoted
> someone who said :
>
>>> This is ridiculous. Each app should run in an air tight compartment
>>> with no possibility it can meddle with the files or settings of its
>>> competitors.
>>
>>Define "air tight". An applet has to leak -- although
>>under ideal circumstances the only leak would be to one's
>>video screen (possibly opening new windows, closing its own
>>windows, etc.) and perhaps audio subsystem, where one has
>>the option of turning off said screen (or iconifying the
>>applet) and turning down the stereo volume. And of course
>>things leak over to the applet: keystrokes, mouse events,
>>maybe the occasional system change event depending on OS
>>("display resolution is now 16 bitplanes" sort of thing;
>>I'd have to look).
>
> My comment was about applications. I want to make it impossible for
> Vendor A to change the program files or DLLs of program B. I want it
> impossible for program A to change the installation variables or
> configuration settings of program B. I want it to be impossible for
> program A to look at or change the files that came installed with
> program B or that program B created.
>
> You might ask how does interchange of data happen -- by using public
> format files that have a verifier which in invoked on export/import.
>
> I want to extend the wall that exists between apps in RAM to the file
> system.
>
> I go even further to protect the proprietary rights of the vendor. See
> http://mindprod.com/jgloss/darkroom.html
>
> Similarly for Applets, Applets from different vendors should be
> protected from even knowing of each other's existence without a
> mutually agreed on export/import interface.

Hm...who's borrowed whose idea here? :-) But yes,
something in hardware, and not only limited to the CPU, is
needed for proper implementation. Consider, for instance,
a Dolphin hookup. (IIRC "Dolphin" is a drive tester that
among other things allows for data extraction and writing.
A CPU isn't needed for disk duplication, although it helps.)

In fact, every periphery card may require such a chip. Presumably
they will be generated in mass quantities, with unique 256-bit
private keys, and corresponding public keys. This key may be
specified in the following rather interesting fashion.

[1] manufacturer identification
[2] wafer identification
[3] chip position within wafer

Mask steppers will require modification, of course.

For protection against silly snooping attempts, the highest layer
(bulk substrate to interconnect) will have to be pure metal,
and I believe you've covered that.

(In case you're wondering, my knowledge of chip fabs is about
15 years old. Some of this may therefore not apply. I'd
frankly have to look and some of the technology is probably
proprietary anyway. Hopefully a UV sputtering technique
which can be driven by computer and the mask changed on the
fly is now available. AFAIK, transistor gates are now on
the order of 0.1 micron or 100 nm -- this is well into the
UV region.)

This metal will probably be connected to ground, though it's
not all that important; the main issue is keeping those darned
microscopes out if someone breaks the plastic package. (Ceramic
lidded packages won't work very well here.)

An alternative which is not something I would favor is a
manufacture-burn-verify-blow cycle.

[1] Manufacture: A "blank" chip is manufactured.
[2] Burn: A programming sequence is started to melt fusible links
on the chip. These fusible links define the private
and public keys.
[3] Verify: The key is verified.
[4] Blow: A sufficiently high voltage pulse is sent to the burn
control input to forever alter its characteristics so that
no one else can reprogram the chip. (This may be optional
depending on paranoia.)

I'll admit I like the "darkroom" idea; it's not something
I would have thought of. Presumably this is negotiated
in a manner similar to RFC2246. With an external chip
there are some major problems.

Fortunately, there is more than enough real estate to
accommodate a crydec. (Dibs on the term. :-) The notion is
similar to 'modem' = 'modulator-demodulator' or 'codec' =
'coder-decoder'; 'crydec' = 'encryptor-decryptor' works a
little better than 'encdec' or 'cryptor'. Its main problem
is that it might be confused with something associated
with liquid nitrogen or some such, but I think it's a
pretty cool word. :-) )

Hmm...the problem with an on-chip crydec is how to get the
key properly masked. Yuck. Then again, I don't know what
replicated masks are used nowadays. If one can project
a UV laser through some sort of liquid crystal affair
we may be in very good shape.

Speed differential: A timeout could be implemented somewhere else
on the data buss; if the properly structured block does not
happen after transmissal to the crydec, the system faults.
A double-fault will freeze the system. (This is behavior similar
to current CPU chips. Unfortunately, it's not hard to defeat,
though it depends on how savvy the system hacker is with
a soldiering iron and AWG30 wire -- and how sophisticated
the timer is.)

Updates: Define "frequent", but the software could
automatically take care of that, since most computers are
hooked into the Internet anyway. Note that the software
will have to ensure that the updates are properly signed
or encrypted; it has a public key for its publisher for
just such a purpose. I'll have to refer you to Bruce
Schneier for more details on this, though; someone could
blast that key and substitute his friends'.

Another possibility is a time-pulse; basically, every time
the software is run (and possibly occasionally during
its running -- once every 10 minutes or so), a random
value based on the current time is generated and signed,
then encrypted by the private key and sent to the vendor,
who has the host's public key on record. The vendor has an
identical algorithm and checks the time-pulse. The vendor
encrypts the result with his private key and ships it
back to the box, which decodes it. The main drawback
is that the system would have to be NTP-synchronized.
Such "breath of life" issues are already in common use in
products such as FlexLM, though I don't know exactly what
method they use.

Note that a "time-pulse" implementation puts the authorization
almost completely in the hands of the vendor. The machine
lives or dies based on his signed word. (The OS is considered
a piece of software for purposes of this exercise. Presumably
the OS vendor will issue updates of his own, and can check
the configuration of the user's machine on a periodic basis,
as required by the EULA.) Therefore software rental becomes
the norm -- frequent credit refreshes, probably once a month,
will be necessary. (XP Home might cost $10/month/computer.)

Single step: The timeout should take care of that. Also,
modifications to the processor might prohibit stepping
over a darkroom enabler instruction.

Watermarking: Hiding may not be necessary. Every installed
code base must have its own private key (this is in
addition to the main computer's key and the software
package identification key), and the code itself is
encrypted with it. Decoding is done during program load;
the only clear copy is in RAM, which could admittedly be
sniffed but a node that is in the pirate's physical custody
is suspect anyway. Unauthorized duplicates will have the
same private key, and may or may not work depending on how
clever the pirates are in figuring out how to install the
software on an arbitrary piece of hardware.

Factory key escrow: A split-key system might work here.
Basically, half of the private key is stored in a known
location; the other half in some other location, ideally
in another state. (This is in addition to the whole key
stored on chip.) If the FBI or CIA require access, they
subpoena a court to retrieve the copies and reassemble the
key -- a process that will probably take several days,
which may be a problem.

The authorization required would have to be similar to
Amendment IV of the US constitution. This may be mandated
by law.

Multiuser systems such as Linux, FreeBSD, or Unix may
cause some additional problems. The sysadmin (Dad, in some
cases -- but a big ISP such as AOL or Earthlink in others)
may have to hand out an additional subfield to authorize
who uses the software. (This is assuming the software is
going to run on that system; if it's just being delivered
to the eventual destination system this assignment isn't
all that necessary.)

Note that this scheme should not be limited to software.
Data should also be encrypted and subject to this scheme,
for full protection. After all, nobody runs a movie... :-)

--
#191, ewill3@xxxxxxxxxxxxx
It's still legal to go .sigless.
.

Relevant Pages

  • Re: Protecting Encryption Algorithms
    ... The NGSCB includes specialized hardware that makes doing this ... >> erase everything on it (including the algorithm). ... I can describe the TCPA chip more specifically because that is what I ... It comes built in with one private key that never leaves ...
    (sci.crypt)
  • Re: Gotta start somewhere ... how many of us are really out there?
    ... The last 4 hex digits of the card and chip lines are the vendor ID ... For the above, vendor *should* be Aopen Inc, not Realtek Semiconductor ... ...
    (freebsd-questions)
  • Re: Philips webcam
    ... Unplugging and then plugging in the camera gives me this: ... Most likely this version of the driver doesn't recognize your ... vendor and product id of your camera can be found. ... The driver checks whether a device with his chip is ...
    (Ubuntu)
  • Re: Can you use ECC to produce digital signatures? It doesnt see so.
    ... > the host computer never needs to know what the private key is. ... SHA-1 to the card. ... chip that was not "always on" couldn't. ... An AADS chip provides significantly higher integrity than a magstripe ...
    (sci.crypt)
  • Re: what information is needed for developing a USB2.0 camera device?
    ... >>I do not think the driver is implemented for USB Video class. ... >>already made the hardware based on the chip. ... > vendor command, that's someplace you need to insert your hardware. ...
    (microsoft.public.development.device.drivers)
Loading