Notes from the SF Physical Cypherpunks meeting

[minow@apple.com (Martin Minow)]

Here are my notes -- without significant editing or correction -- from
Saturday's (96.05.11) cypherpunks meeting in Palo Alto.

Discussion of crypto user interfaces (particularly NetScape and e-mail)

-- How to tell user that "installation" not secure in a decent GUI?
-- Expectation of what leaves user machine.
-- Vendor's "shouldn't distinguish products on security: security is the
   bedrock of our industry." (Quote from some industry person who
   was not present to defend this thesis).
-- Someday, there will be a "Word virus that attacks your CyberCash wallet."
-- If the message is insecure with respect to the user's expectation,
   there should be a user-visible window border (or similar): NetScape's
   little key isn't good enough. Did you know that the netscape key
   has 1 tooth for 40-bit, and 2 teeth for 120 bit encryption?
-- Signed code is the new industry meme. Bonded agents who certify
   signed code. Do you know how much bonding costs, and how little
   it offers?
-- Security dialogs need a help button that explains security.
-- Error messages (of all kinds) should have a url that gives more
   info. Can be a file:// or http:// for local help.

Eudora and Netscape will provide S/Mime. PGP is going nowhere,
S/Mime becoming ubiquitous (Eudora, future Netscape)

S/Mimepretty good. 2 Flaws: signature's name is not encrypted. Major
flaw: encryption defaults to 40-bit. No good way to negotiate for
stronger encryption.

c2.org: 90% of all connections are 40-bit RC2.

Need to publish negotiation info so that sender and receiver can agree
on crypto strength.

PGP lost in Eudora/Netscape: ongoing legal problems with Phil Zimmerman.
Strong concern that companies can't use PGP without problems with RSA.
Do they need Viacrypt.

Web of trust: not working. Hard to map an e-mail address to a key.
Hal Finney's Java implementation not sufficient for signature
distribution.

S/Mime will support Verisign. Verisign certificates have "trust"
level: class 1 is untrusted (equivalent to PGP self-signed?)

Next Netscape beta will have five additional non-verisign CA's:

----
Crypto toolkit: need certification for code fragments.

Need "web of trust" for software validation. There will be a zillion
Java applet's out there: how do you know one does what you claim it do?

When will Java signed classes/signed applets be released. Two weeks.
Hmm, Java One conference is in two weeks. Surely a coincidence.

You can sign a class by signing the class file (zip), then archiving
it together with the source and then sign the combined archive.

I think that Stuffit (on the Macintosh) supports signed archives if
PowerTalk is provided.

-----
Norm Hardy talked about the E programming language from Electric
communities.  (Java with capabilities).

[[These are notes, and occasionally incoherent, for which I
humbly apologize.]]

Capabilities. Should be able to import code and run it even when you
don't trust the code.  Java-type scheme can succeed. No short
description. Here are some of the reasons you should believe it:

-- History: late 50's Algol 60. Code shouldn't be able to escape
it's storage. Compilers and hardware thought this was not sufficiently
important to do this. Not implemented on actual compilers or hardware
(hmm, Burrows 5000, Basic timesharing systems offer counter-examples).
Intent was to be neat and modular, not to be secure against intruders.

Garbage collectors forced better, formal, theory of storage. Gave us
storage security. Multics gave cross-trust subroutine calls.

KEYCOS Started in TimeShare, early 1970's. Ran customers (competitors)
on the same machine. Machine code didn't get in other people's way.
Customers needed to interact. NCSC (part of NSA) looked at this,
recommended B3 rating. Archtecture was good for A1 (next to top, as
good as it comes). Needed rewriting by cleared people, needed formal
proofs. NSA judging systems to protect NSA secrets.

Main idea: programs have rapid communication, with strong security
properties that they themselves arrange. HYDRA earliest system
(Bill Wulf). KEYCOS improved on HYDRA.

Capability: designates something and conveys authority to that thing
Can't pull this apart: can't access without having capability. Can't
get information, can't affect its state. No specific superuser state:
privileged programs have different set of capabilities, not necessarily
all. COM e-mail/bbs system (Sweden) -- operator could backup e-mail, but
not read it.

Object oriented programming system is a capability system.

Crypto (public-private key) similar to capabilities. Public key is
a capability. Private key is the thing that the key designates.

Access lists: people access data. However, it's really the computer
program that accesses the data on the person's behalf.

Access control lists (VMS, Mac filesharing) -- more prevalent than
you might expect, but can be made unobtrusive. Few people notice
that Mac filesharing has access control lists.

Contraxt Unix and capability system. On Unix, programmer gives a
filename to the shell, shell tells the compiler. Compiler opens the file.

Capability: give "read" capability to shell, shell gives it to compiler.
Compiler uses capability to access data.  Cannot hide capability from
programmer. When you build something (create something), you have to
present a "space bank" (sub-pool). You can buy space bank, determine
the amount of free space, zap parts of it, etc.

Money object: can do in Java -- two classes: mint, pot. Pot has two
private fields, mint reference, value. Pot method: produce a sibling
pot with same mint object and no value. Transfer -- if two pots refer to
the same mint, transfer value between them.

I own program, you own data. I don't trust your data, you don't trust my
program. I want to allow you to run your data on my program. Factory
(mutually trusted). Give access to code to factory. Give you access to
factory. You invoke factory, factory creates object that can execute code
on data, but lacks capability to send data.

Capability architectures (narrower sense): for A to affect B,
necessary and sufficent for A to have capability for B.

Can't add onto Unix since old, non-capability mechanisms are still there.

Get capabilities two ways: create object, gets ownership to message.
Can pass capability in a message.

Give to subcontractor only narrow capabilities it needs. Build system so
capabilities can be very narrow. Can grant capability "Q := zero" --
receiver executes capability, but never know name of variable.
Algol call by name -- caller passes a "thunk" to the subroutine. Subroutine
executes the thunk that carries out the caller's computation.

Debugger subject to same capability restrictions.

Keeper -- computational resources become capabilities -- meters grant
ability to use cpu time. Meter has "amount of ticks" -- when hits zero,
task is suspended. Attached to another program with role of meter
keeper. Meter keeper can decide to replenish meter.

Can allocate budget (rate-based) -- useful for real-time app's.
Jewel manual (agorics web site). Market-based control Scott Clearwater.
Fractional (Fractal) reserve bank.  http://www.agorics.com/agorics.

Can grant subsets of own capabilities. Can (by prior arrangement)
revoke capabilities. Language-based vs OS based. Can run large parts
of o.s. in capability model. Get some advantages, but there are pitfalls.

Capability systems can protect against denial of service. Can
administrate cpu/space usage. Language-based systems can message
across trust boundaries quickly. O.S. based may need many machine
cycles.  Crypo-based capability may need millions (exponent).

----

Marianne Mueller.  Reported on Java Security Workshop.

[[Dumb jokes self-censored to protect the guilty.]]

Java team interested in security -- nobody is specifically Mr. Security.
Everybody's responsiblity.

1st Morning. Status + foodfight: Steve Bellovin: Java is a virus. Venting.
We all got minimal trusted computing base (with verifying, formally)
religion. Need better formal model of the language. with better
specificiation, can get better testing. Need better test suites to ensure
that Microsoft implements the same model as Netscape.

VM spec, language spec, also working on policy spec (what the sandbox
policy actually is). Funding an outside security group.

1st Afternoon. Paul Karger, Mark Schaffer. How to use capabilities with
Java. "If you do capabilities, make sure it does these 15 properties. "

2nd Morning. Proposal to do code signing. Afternoon, continued to discuss
code signing and key management. Discussed trust models. Butler Lamson and
Ron Rivest paper on Rivest's home page (on capabilities). Lamson now
working for Microsoft.  IEEE symposium on security and privacy. Security
theory people. Princeton stuff. Security folk all over the Princeton folk
-- think they're just a bunch of hackers.  Java folk impressed; find
Princeton stuff useful.

Working on crypto API's. Sun lobbying govenment to free crypto API's.

Signing classes, applets, applications (application is classes + data).

Microsoft coming out this summer.

Code signing very important. Needs very soon.

Hard to do real capabilities on Java. Transitive closure is very difficult.

-----
Transcribed in real-time by

Martin Minow
minow@apple.com