[e-lang] Calculator
e-lang@mail.eros-os.org
e-lang@mail.eros-os.org
Wed, 22 Oct 2003 12:23:04 +0530
Thanks for the great reply!
I would just like to add that we may still have some attack possibilities
left:
1. If Q2 is very expensive and is not covered in the warranty, and the
manufacturer has a condition/software-agent that the defective piece must
be returned/reported to the manufacturer.
2. If Manufacturer charges money for the service of typing in stuff
(wheat/chaff) into the calculator. It will have to be recharged after 105.4
days and/or N uses of the calculator. [I was in E-Speak/Services for a
while at HP Labs Cupertino. :) ]
Do you think these may connect smart contracts and capabilities together??
BTW, I am trying to get myself a ticket to the conference at Mumbai for
ASIAN03. Let's see if I can make it!
-Rajesh.
* This bullet point was never written before in
(courtesy - Douglas Hofstadter)
"Miller, Mark"
<markm@hpl.hp.com> To: "'e-lang@mail.eros-os.org'" <e-lang@mail.eros-os.org>
Sent by: cc:
e-lang-admin@mail.e Subject: RE: [e-lang] Calculator
ros-os.org
10/22/03 12:07 AM
Please respond to
e-lang
At 03:34 AM 10/21/2003 Tuesday, RBhaskar@inautix.com wrote:
> Here is a question on the Calculator in the "Paradigm Regained" paper...
>
> What if the manufacturer has put in code that will create a problem with
> the display in the calculator precisely after 105.4 days. In the meantime
> the calculator logs in all calculations in its memory bank. The
> manufacturer is called for repairs and then he takes all the data out...
> :))
>
> Is this a valid scenario in the capabilities area?
Absolutely, and it's a great question.
<safely-skippable-detail>
I will answer in terms of the Factory design presented in Paradigm
Regained,
which provides both Confinement and Durability
http://www.cap-lore.com/CapTheory/KK/durability.html . It serves therefore
as both Factory and Fort. (Using the techniques shown in the paper, one
can implement more flexible schemes whereby Confinement can provided
without Durability, and vice versa. KeyKOS and EROS currently implement
only Factories that provide confinement, but they could easily also
support Durability, either separately, or bundled in with confinement.)
</safely-skippable-detail>
A calculator, let's say Q, has no access to a clock, even for relative
time,
unless Cassie provides Q with such a source. However, this is a detail, as
Q can still, for example, be built to break after being asked it to perform
N calculations, after which case Q can mount the same attack.
* If Cassie doesn't care about rescuing the individual calculator instance,
Q, specifically, she can go back to the calculator factory and use it to
make a new calculator, Q2, which must be as good as Q was originally, even
if Max intends otherwise. (This is where "Durability" would come in.)
* If Cassie does care to rescue Q himself, or if she wishes to help Max
find
his bugs by giving Max access to the allegedly broken Q, and if Cassie
decides she doesn't care to continue to keep Q's possibly accumulated
memories secret from Max, then Cassie can, at that time, decide to give Max
access to Q. Regarding this risk and Cassie's decision, our physical
calculator metaphor exactly mirrors the actual issues. (When my hard disk
crashed recently, I had to decide whether I valued keeping my secrets more
or less than rescuing my data. When humans do the rescuing, this decision
is unavoidable.)
Max, by pre-arrangement, can enable himself to obtain debug-level access to
his own calculators starting only from normal customer-level access. This
"rights amplification" ability is provided primitively in KeyKOS and EROS
by the "Brand" mechanism -- the same mechanism that implements their
trademarking. Like trademarking, this need not be primitive, but it sure is
convenient for it to be primitive. (It's a bit of a pain to build from
the other primitives.) E does not yet provide a primitive means to obtain
debug-level access by amplification, but it needs to.
* If Cassie does want to rescue Q himself, but wants to keep Q's memories
secret from Max, she might decide to see if Max is offering a confined
"patcher" for his previous calculator product. Note that even this query
leaks some information from Q to Max. Q could be programmed by Max to break
iff Cassie enters data that matches some criteria. If Cassie checks for
and downloads a patcher from Max, Max might conclude that Cassie had indeed
entered data matching this criteria. Let's say Cassie decides she can risk
this degree of leakage. (Alternatively, Cassie can download all such
patchers, whether she applies them or not.)
In this case, Cassie would actually download from Max a Factory for a
patcher. She would use it to make a confined patcher. She would give the
patcher access to Q and nothing else. The patcher could use the same
"rights
amplification" ability Max could have used above to obtain debug-level
access to Q's representation, which it could use to arbitrarily alter Q's
behavior, in order to allegedly fix Q. Cassie can use the allegedly
repaired Q, confident that Q has no further access, and confident
that Q has at most that further knowledge which might have been in the
patcher. For virtually all risks Cassie might worry about, we can say that
the allegedly repaired Q is as safe as the broken Q. The repair process
itself put no secrets at risk.
... # assume Q is broken and is in scope
{
def patcherFactory :Factory := ... # obtain somehow from Max
def patcher := patcherFactory .new([])
patcher.fix(Q)
}
... # use the allegedly repaired Q
Note that after the above block, the above patcher is unreachable except
possibly from Q.
Once again, thanks for the great question. AFAIK, the point made by the
last
bullet above has never been written down before.
----------------------------------------------------------------------------
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang