Now that a significant number of JSRs are being developed as open source projects, I thought it would be interesting to explore the implications of this for security.
First, let's start with the basics. Security is fundamental to the Java platform - it's built in to the Java Language and the Java Virtual Machine specifications.
In the early days it was expected that a primary use of Java would be "executable content" downloaded from the Web. (See this paper from 1995 on security in Java - "A new programming language from Sun Microsystems".) Obviously the security implications of running arbitrary "foreign" code are serious. Java took these into account.
At the most fundamental level, the Java compiler and virtual machine use several mechanisms to ensure security. These include strong data typing and automatic memory management to guard against problems like buffer overflows, bytecode verification to ensure that the contents of Java class files are consistent with the specifications, and secure class loading to ensure that untrusted code cannot interfere with the running of other Java programs.
Security for applets was originally enforced using a simple "sandbox" mechanism. Untrusted code was permitted to execute only in a "sandbox" where it was prohibited from performing many potentially harmful actions such as reading or writing to the local disk or making new network connections. While this simple approach provided effective security, it proved to be too restrictive, making it difficult for benevolent but technically untrusted programs to do anything useful.
Java 1.1 introduced a code-signing and authentication mechanism that made it possible to remove the sandbox restrictions on code that had been digitally signed by a trusted third party. However, in practice this still proved too inflexible, since it adopted an all-or-nothing approach. (Either code was completely trusted and could do anything, or it was completely untrusted and severely restricted.) Finally, Java 1.2 (Java 2), introduced a sophisticated fine-grained security policy, making it possible to grant or deny specific permissions to all Java code (not just applets).
Building on the security features of the language and virtual machine, a variety of APIs provide flexible and extensible support for cryptography, secure communication, authentication, access control, and public key infrastructure. (Click here for details - probably more than you want to know!)
Because security is fundamental, the majority of these APIs were developed and evolved as part of the base Java SE platform JSRs rather than as standalone JSRs. However, there have been several JSRs that specifically addressed security:
It goes without saying that standards are fundamental to security. If we can't agree on encryption algorithms or on secure communication protocols, then we have nothing. Standards, and their public nature, make security possible. However, standards by themselves are not sufficient. Implementations must conform to the standards (conformance test suites, or TCKs, can help to ensure this), and of course the implementations must be free of bugs that would otherwise compromise security. How can we ensure this? Does the public nature of the open source development process help or hinder the development of secure implementations?
Some argue that opening up the source code to public scrutiny is dangerous - that it makes it more likely that "hackers" will discover and exploit security flaws. Others argue that public exposure is the best defense -the more people who study the source code the more likely it is that security problems will be discovered and corrected. A detailed review of the arguments can be found here.
I don't believe that open source development processes necessarily result in secure software, any more than they guarantee high quality. It's just as easy to write buggy or insecure code "in the open" as it is behind closed doors. However, if the source code is available for public scrutiny, and if others are free to modify it, this may make it possible to discover and correct problems that would otherwise go undetected. As Whitfield Diffie, the co-inventor of public-key cryptography and chief security officer at Sun Microsystems has pointed out, "all of the popular cryptographic systems used on the Internet are public...It's simply unrealistic to depend on secrecy for security in computer software." (Risky business: Keeping security a secret.)
The public nature of the JCP's standards-development process, coupled with open source coding practices, are the best guarantees of Java's security.
While it may be more interesting and more exciting to push a new JSR through the process, we shouldn't forget the importance of ongoing maintenance. A standard that is defined but that doesn't evolve is not very useful. This month JSR 927: Java TV, led by Sun, submitted its fourth Maintenance Review. Java standards for TV have been under development for several years and seem likely to reach their full potential soon as OCAP-compatible set-top boxes reach the market. (The "900 number" of the JSR, by the way, signifies that this specification was developed before the JCP was created, and was "grandfathered in" to the process for maintenance purposes.) Similarly, JSR 82: Java APIs for Bluetooth, led by Motorola, issued its third Maintenance Release six years after the initial release of the specification. The spec leads for both of these JSRs are to be commended for their ongoing commitment.
JSR 290: Java Language & XML User Interface Markup Integration, led by Sun, released its Proposed Final Draft. If you, like me, are intrigued by the possibility of combining Java user interfaces with XML markup, check out this JSR, which enables the creation of rich user interfaces on mobile devices by leveraging W3C XML markup specifications such as Scalable Vector Graphics and the Compound Document Format.
Finally, JSR 311: JAX-RS: The Java API for RESTful Web Services - one of the "open and transparent" JSRs that I wrote about last month - is currently in its Final Approval Ballot process.
While we're talking about ballots, if you're a JCP member you will soon have the opportunity to vote in our annual elections. (If you're not, now is a good time to join. It's easy and free for individuals.) More on this next month.
© 2008 SYS-CON Media Inc.