IBM’s Java Security

To improve Java’s security, IBM works hand-in-glove with Sun. Bob Blakley, IBM’s Lead Security Architect for Network Computing Software says, "Security is provided by the core Java Virtual Machine and standard extensions to Java - IBM ... does not modify the Java programming interface ... [but rather] works with Sun in design and implementation so our security requirements are met."

Blakley says there are four forms of Java — Applications, Applets, Servlets and Aglets. Each poses unique security challenges:

*Applications load from diskettes like applications in other languages — their security issues are similar.

*Applets load from the Web. The JVM running them has permissions-based security to activate digital signatures ("signs") and access programs/data on local/client file systems beyond their "sandbox," the secure browser environment where applets operate. Sun’s new Java Development Kit security model provides a "Protection Domain Architecture" system of permissions and policies that renders applets "trusted" or "non-trusted" — "trusteds" may broach the sandbox and tap underlying resources; "untrusteds" may not. Some applications are also subject to this type of security.

*Servlets are Java server-side functionality loaded from a local disk or over a network. They invoke underlying server functions using a standard programming interface and use a servlet Java sandbox with a security policy designed for the server environment. The policy is the standard Java sandbox policy but also allows trusted, signed servlets more access to server resources and can be customized by the server administrator.

*Aglets are mobile Java agents that independently roam from system to system via public and private networks and perform specific missions like monitoring particular Web sites. In visiting foreign systems, says Blakley, aglets can contract viruses or be intentionally rewritten to breach home system security upon returning. So an aglet security system must verify that aglet code hasn’t been changed. Aglet security uses a restricted but standard Java sandbox and checks an aglet’s "signature" to ensure the code isn’t altered.

Blakley says four disciplines govern Java forms’ security, and the first three come with Sun’s core JVM. Access Control permits the Java forms to be activated by Java Virtual Machines. Authentication reinforces access control - authentication means like security certificates are passed between the Java form and JVM to verify the program hasn’t been changed. Encryption codifies data so it’s indecipherable to third parties who intercept it on public networks.

IBM is independently developing the fourth discipline, Non-repudiation, for electronic commerce apps. Blakley says it requires e-com buyers give e-com sellers a stamp indicating the time of the transaction, the buyer’s electronic signature, and policy information (say, the period for reporting a stolen credit card before they’re liable for subsequent purchases). Non-repudiation creates an unforgettable electronic record proving you performed a transaction and functions as a receipt you refer to when, say, you return goods.