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