A Conversation with Bob Scheifler, Part III

Many potential applications of Jini require network security. Although various third parties have made proprietary security extensions to Jini, until now the only security available to users of the standard Jini release is the security infrastructure of the Java platform. The Jini Community's Davis project is about to change that. Bob Scheifler is leading the development of the next release of Jini, in which security is the central concern, as part of the Davis project.

On Friday, April 12, 2002 Bill Venners visited the Sun Microsystems campus in Burlington, Massachusettes and interviewed Bob Scheifler, Sun Distinguished Engineer and architect in the Jini Group. In Part I of this interview, Scheifler discusses the need for security in Jini and the special security considerations of dynamically downloaded code. In Part II, Scheifler describes the mechanisms used to determine whether a proxy should be trusted. In this third installment of the interview, Scheifler discusses the mechanisms used to ensure object integrity. These mechanisms enable the recipient of a network mobile object to determine that both the data and code portions of the object are received intact.

Object Integrity

Bill Venners: How do you do object integrity?

Bob Scheifler: If you look at standard Jini deployments, everybody is using HTTP URLs today. The problem with that from an integrity perspective is there is nothing intrinsic in the HTTP protocol that guarantees integrity. If somebody attacks and overwhelms the HTTP server, and I ask for service-dl.jar, it can hand me whatever it wants under that name. Or it is conceivable that a third party could intercept the traffic, modify it, and return data I don't want to use. The HTTP protocol by itself isn't going cut it. We need something stronger.

Using HTTPS URLs for Integrity

One possible way to get integrity for downloaded code is to use HTTPS URLs. You are a service, and you send me a proxy that has classes annotated with an HTTPS URL. That will guarantee integrity because you sent me an HTTPS URL, and you sent it in-band. The URL itself has normal data integrity, so I get the URL you thought you sent.

HTTPS gives me server authentication along with confidentiality and integrity. I will require the HTTP server to authenticate under the host's identity. The actual transfer of the JAR file will have, in fact, both encryption and guaranteed integrity. If you annotate your classes with an HTTPS URL, then I know I will get the classes you expected.

One possible way to ensure object integrity is to say everybody should use HTTPS URLs for their code bases. But that has some disadvantages. One is that you have to set up public key certificates for your HTTP server to authenticate as the host. If I am just a vanilla user I need to get somebody to generate host certificates for which they are willing to give me private keys. That may be a problem. Another problem is that I get encryption of the code even though I don't care about encryption. I don't care about keeping it private because I will probably serve it up to anybody who asks. I don't want to keep the code private. I just want to make sure it has integrity.

Using HTTPMD URLs for Integrity

An alternative scheme we've defined in Davis [the next Jini release] is a new type of URL scheme we call HTTPMD, where the MD stands for message digest. An HTTPMD URL includes a message digest of the contents of the code. The digest is a cryptographic checksum on the data in a JAR file.

This scheme is intended to work with JAR files not with directory-based class hierarchies. There is no easy way to compute a digest over the entire set of directory trees from which HTTP can serve class files. If you are willing to serve things up as JAR files, the normal approach in Jini systems anyway, then you as the server locally compute the digests. You must have local access to the JAR file, so you don't have to worry about its integrity yourself. So offline, or online, or through any means that you trust, you get the JAR file and compute its digest.

Then what you send to me as the code base is an HTTPMD URL, which looks like a normal HTTP URL except that it also has this digest attached. And, again, the URL itself—the code base—is sent in-band as part of our communication. I know I got the digest you expected to send me. When I download the JAR file, I don't care about authenticating the server because I don't care where the data comes from as long as I get the right data. As for the idea of a cryptographic checksum, is it is nearly impossible for somebody else to come up with alternative contents that will have the same checksum.

I have a very high probability that if I get something from whomever, and it has the same checksum, that it is, in fact, the same data you expected to send. HTTPMD URLs are a cheaper mechanism than HTTPS URLs in the sense that I can use normal HTTP transfer. This doesn't have any affect on the HTTP server itself. I can use a vanilla HTTP server. The only change is that on the client side the URL protocol handler says, "As I download the contents from this vanilla HTTP server I will compute a checksum. And at the end I will check the actual checksum with the expected checksum. If they are the same, then I am happy. And if they are not the same then something bad happened and I should not use the code."

Both of these mechanisms, HTTPS and HTTPMD URLs, provide integrity of code. They do it in slightly different ways and have different performance implications. They are two example URLs. You can invent others. We set up the system so that you can just plug in new things and say which URLs should be trusted, which URLs give you integrity.

Bill Venners: What do HTTPMD URLs actually look like?

Bob Scheifler: An HTTPMD URL looks exactly like an HTTP URL, except the scheme is HTTPMD and the URL is terminated with a semicolon, message digest algorithm name, an equals sign, and the message digest. So at the end it might look like semicolon, md5, equals a long stream of numbers.

Sending Code Out-Of-Band

Bill Venners: A friend of mine who was learning about RMI asked, "Why can't RMI just send the classes in-band along with the object data?"

Bob Scheifler: There are many issues with sending code in-band. One is a three-party system. Suppose you are a lookup service in which some third service is registered. I want to get the proxy from the lookup service. Should I get that third service's code from you or from the service? Were the code sent in-band, then that means that somehow the service had to give you the lookup service all the code so that you can hand the code on to me. So that is one problem. Do you really want to be the intermediary for all of that code? Another question is, do I have to call back to you to call back to the service?

Another question has to do with what permissions you assign to the code. Code comes from URLs. You can use those URLs as a basis for security policies to decide what permissions to grant to the code. If the code comes inline and there are no URLs associated with it, then how do I talk about it from a security perspective if I want to do static grants to it? There is no notion. If you send me the actual class files and you also claim they are from some URL can I really trust that? Another problem comes up if you think about marshaled objects. If you think the sender has to provide the class files then the marshaled object has to have all of the class files in it.

Code Bases with Multiple JAR Files

Bill Venners: Often service proxies won't be built from just one JAR file. When I make a URL, I'm probably referring to one JAR file, but it may refer to others. Would there be HTTPMD URLs inside those JAR files when they refer to the other JAR files?

Bob Scheifler: There are two cases. One is if your code base is a list of URLs at the top level. Every top-level URL should guarantee integrity. You can just check each one. They don't all have to be HTTPMD. You might say, "This one is HTTPMD; this one is HTTPS; and this one is some other URL scheme that I decided provides integrity." In the case of HTTPMD or even HTTPS, if it has a class path—if it is a JAR file with a class path manifest that points at other JAR files—then the expectation should be that those subsidiary URLs are also integrity protecting URLs. In JAR files, class path entries are generally relative URLs, not absolute URLs. So class path URLs inside a JAR file typically inherit the same URL protocol scheme as the JAR file's URL.

For example, if foo.jar refers to bar.jar in its class path, it doesn't give the full URL httpmd://host:port/bar.jar. It just says bar.jar. The rest of the URL is inherited from the outer one. So if foo.jar was retrieved with an HTTPMD URL, bar.jar will get an automatic HTTPMD addition. You need to worry about getting the right digest in the URL for bar.jar. If it doesn't have the right digest then you will either get a malformed URL exception or a bad digest, and it won't download. Those are deployment considerations when you create a JAR file you want to use with a HTTPMD URL. But the class path itself can have relative HTTPMD URLs with precomputed digests.

Resources

The Jini Community, the central site for signers of the Jini Sun Community Source Licence to interact:
http://www.jini.org

To get involved in the Davis project, in which Jini security is being defined, go to:
http://davis.jini.org/

Talk back!

Have an opinion? Be the first to post a comment about this article.

About the author

Bill Venners is president of Artima Software, Inc. and editor-in-chief of Artima.com. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project that produced the ServiceUI API. The ServiceUI became the de facto standard way to associate user interfaces to Jini services, and was the first Jini community standard approved via the Jini Decision Process. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community. He currently devotes most of his energy to building Artima.com into an ever more useful resource for developers.