Signed Java Applets, Trust, and Key Servers

A talk for the Boulder Java User's Group, March 1997, by Neal McBurnett.

Unlike PGP, javakey can be exported and is free for commercial use in the US (although there are claims to the contrary). Of course it doesn't do encryption, only signatures, but you can certify anything you want about any key, which leads to the general notion of "capability certificates".

Disclaimers

This is a very complex and fast-moving field. Take anything anyone says (including me) with a skeptical attitude. Feel free to ask questions and provide your own expertise.

Poll: who has used signed code? Published it? PGP key?

Introduction

• JDK1.1 has signed applets, javakey program for managing keys and trust (effectively makes everyone a "Certificate Authority")
• See Signed Applet Example and Using javakey for an intro (but see warnings below!).
• JDK1.1 has notion of multiple, interoperable security "providers" that can share keys, cross-validate, etc.
• "SUN" provider: DSA keys, not RSA: exportable!
• DSA may also be free of patent royalties for commercial use, but RSA claims that their "Schnorr" patent also covers DSA. Most experts seem to disagree, but lawsuits can be ugly. Another concern is that it has "covert channels" so an unethical implementor could leak your private key, or an unethical signer could leak information about the subject.
• Commercial Certificate Authorities not yet doing DSA keys.
• So how do we decide who to trust?
• Be careful: analogy to building with ID security only.

Javakey Safety Tips

• Javakey is an interim tool specific to the SUN provider. Not Sun's best effort....
• BASIC hygene premise: private keys need to be secure
• "How-To" example teaches the wrong thing, leaves private key world-readable....
• No encryption => no safety for private keys
• No separation of private and public key databases
• In the meantime, use PGP, floppy disks, copy $HOME/identitydb.obj back and forth, export and import certificates (javakey -ec and javakey -ic)
• On Unix, set umask 077
• Use different keys for signing code vs. providing certificates.
• For real use, generate your own keys with your own random-number seed
• Beware - they switched to ARCHIVE= rather than ARCHIVES= in APPLET tag (compatible with Netscape).

Key database Audit.java

• My program to help improve security. Warns of private keys in IdentityScope.
• Prints out user's IdentityScope in PGP style (see sample output)
• Identify keys by first 32 bits, not more ambiguous names
• "Fingerprints" (secure cryptographic hashes) can be easily verified out-of-band and allow you to be sure you've got an authentic copy
• Not (yet?) part of SUN security provider. Need a conventional thing to sign and hash algorithm. I do an MD5 hash of the public key in X.509v1 DER format (just like the public key files javakey produces).
• Note non-standard use of Distinguished Name fields: put email address in (but X.509 demands "@" encoding, e.g. "(a)"), use of OU=policy

Public DSA Key Server

• I've implemented a prototype Public DSA Key Server, allowing import and export of X.509v1 DSA certificates.
• Lessons: No generic Certificate.verify() method. I wish they would get rid of identity names - gets in the way.
• X.509v1 certs don't have the signer's public key in them, just an ambiguous "Distinguished Name". which makes the key management problem a little harder.
• Importing and exporting keys is currently done via cut and paste and the the MIME base64 encoding, since certificates are binary data.
• Don't trust any keys for which you haven't verified the fingerprint!

Other Public Key Infrastructures

• PGP had it almost right years ago: PGP's Web of Trust. But tools don't support arbitrary assertions about other keys (though RFC1991 "PGP Message Exchange Formats" does). A PGP Digital Timestamping Service is also available.
• Microsoft just doesn't get it
  • Unsafe scripting languages embedded in major products
  • "Prank" macros impose large costs on customers even if "not malicious"
  • ActiveX and Authenticode: see warnings at Risks Digest 18:86
  • Worst risk: ActiveX code designated "safe for scripting" without the language support that Java provides.
  • Echoes of sendmail
  • Microsoft advice that object which provides read-only access to spreadsheets is "safe for scripting"!
  • They allow users to default to "low" security setting - no questions asked for unsigned code. Even firewalled environments are just "crunchy on the outside and chewy on the inside".
  • Encourage us to trust the whole commercial world
  • But: much better job on managing private keys: encrypted on floppy, or smart card.
• Verisign - top-down model, monopolistic, forbids signing keys, publishing their certificates from your own site, no fingerprints.
• But all trust is circular - only you can inject trust into the system, and you must set policy along the way. See PolicyMaker, which provides a simple language for defining trust policies
• See also, e.g. IETF efforts on SPKI (focussed on general "capability certificates") and PKIX (more traditional and complex) and the W3C work on Digital Signatures, which is related to the PICS effort and is using Java heavily.
• SDSI

Conclusions

• Sun is on right track: language safety + code signing in Digital Signatures framework, code can be inspected, etc. BUT:
• Javakey application is in a primitive and dangerous state
• Need for key servers, flexible trust management
• Acute need for logging of risky behavior: signer, URL, hash of code that was signed, etc.

Pointers

• Stay tuned - Audit.html and key server could show up here
• JavaSoft's Java Security page
• Java Cryptography Architecture API Specification & Reference
• JavaOne conference talk on Security API
• Cryptix: free implementation of most cryptographic algorithms (including PGP) in Java and Perl from Ireland.
• Bruce Schneier, "Applied Cryptography" edition 1: "DSA is great for digital signatures ... royalty-free, making it the obvious choice" (p320). In the second edition he no longer says this, and seems to prefer another alternative, the similar and unpatented "p-NEW" scheme.
• Crypto++ - a free C++ class library of cryptographic primitives which includes DSA support. But they recommend against DSA.
• EPIC pages on DSA/DSS - pretty negative, but dated?
• Digital Signature Legislation

Sample output of Audit.java, in PGP-inspired format

Each pair of lines after that consists of a name to be signed and a "sig" line which describes who signed it. The name of the signee is always indented one space less than the name of the signer, and is always on the immediately preceding line, in this implementation. E.g., the second-to-last sig line indicates that key d57e6e36 (the "CA" key) is signing the association of the name
"CN=nealmcb@bell-labs.com, OU=jar-signer, O=, C=" with key d5b314cc.

The dates are not yet implemented.

WARNING: [Signer]testsigner[identitydb.obj][not trusted]: Keep private keys encrypted!
Type bits/keyID    Date       User ID
pub  1024/d57e6e36 1997/mm/dd d57e6e36[identitydb.obj][not trusted]
          Key fingerprint = 8C 57 2F 5A AF 38 9B 3F  4C 65 DF 19 33 E3 7F 40
                              CN="Neal McBurnett ", OU=CA, O=, C=
sig       d57e6e36             CN="Neal McBurnett ", OU=CA, O=, C=
pub   512/dedfc0fd 1997/mm/dd CN=Neal McBurnett - don't rely too much on this, OU=Bell Labs, O=Lucent Technologies, C=US[identitydb.obj][not trusted]
          Key fingerprint = 94 CB AA 08 0E EB B4 5E  26 9E 92 40 B0 9C 6E F8
                              CN=Neal McBurnett - don't rely too much on this, OU=Bell Labs, O=Lucent Technologies, C=US
sig       dedfc0fd             CN=Neal McBurnett - don't rely too much on this, OU=Bell Labs, O=Lucent Technologies, C=US
pub   512/e8fd3554 1997/mm/dd [Signer]testsigner[identitydb.obj][not trusted]
          Key fingerprint = BD 8A BA D6 2D 01 46 7A  5A A1 00 E0 BE 1D 0A 69
pub   768/d5b314cc 1997/mm/dd d5b314cc[identitydb.obj][not trusted]
          Key fingerprint = 74 92 AA 71 E2 F0 B7 A5  D8 31 60 80 4C 85 E5 08
                              CN=nealmcb@bell-labs.com, OU=jar-signer, O=, C=
sig       d57e6e36             CN="Neal McBurnett ", OU=CA, O=, C=
                              CN=nealmcb@bell-labs.com, OU=jar-signer, O=, C=
sig       d5b314cc             CN=nealmcb@bell-labs.com, OU=jar-signer, O=, C=