ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Java vs .NET Security: Epilogue Java vs .NET Security: Epilogue
Upcoming Security Features

by Denis Piliptchouk

Editor's Note: This series on security has been collected into a PDF eDocument, Java vs .NET Security, which is now available from O'Reilly Digital Publications. In this epilogue written for the PDF, Denis takes a look ahead to where the two platforms are headed in the near future.

This article serves as the epilogue to the ".NET vs Java Security" series that has been published by O'Reilly Network over the last several months. Both platforms (J2SE 1.5 and .NET "Whidbey") are expecting significant new releases in the current year, and a brief preview of the upcoming security features is attempted here.

As before, this publication will focus on the security features of the platforms themselves, avoiding more broad discussion of additional products and services. The security features will be reviewed by protection categories, to ensure that similar items are compared in each case and to see how they augment the existing functionality.

Summary of Future Security Features: Java

In terms of Java security, this is an evolutionary, rather than a revolutionary release, because it does not bring any new, ground-breaking changes. The updates are mostly concentrated in the areas of cryptography and PKI.

Specifically, JSSE experiences a significant change:

  • A new SSL/TLS abstraction layer is added to separate its logic from threading and I/O issues.
  • JSSE will now use JCE providers exclusively.
  • External provider pluggability will be allowed.
  • By default, will use a X.509-PKIX-compliant TrustManager that is based on CertPath provider.
  • Default SunJSSE provider will include support for Kerberos suites.
  • AES_256 cipher suites will be enabled by default in the SunJSSE provider.

JCE is going to see some new functionality as well:

  • A PKCS#11 provider will be included, which adds support for hardware-based accelerators and smartcards.
  • New APIs for ECC will be added.
  • The SunJCE provider will include RSA encryption and several additional algorithms.
  • Several parameters will be added or enhanced to provide support for XML Encryption algorithms.
  • On Solaris, better integration with the OS' cryptographic framework will result in significant performance improvements.

Java PKI is going to be updated as follows:

  • Smartcard-based keystores are going to be available, thanks to the added PKCS#11 provider.
  • Enhanced PKCS#12 implementation will be included.
  • Client-side support for On-Line Certificate Service Protocol (OCSP) will be added, and APIs for indirect CRLs will be extended.
  • CertPath implementation will be PKIX-compliant.

JAR files will benefit from the newly added support for Time-Stamp Protocol (TSP), which will enhance the verification of archives.

The Simple Authentication and Security Layer (SASL) will be supported through new APIs and a SASL provider for JCA.

Finally, the JAAS Kerberos module in 1.5 will have an option for TGT renewals, which should help avoid unnecessary service re-authentications.

Summary of Future Security Features: .NET

For .NET, more changes are in store in the upcoming release, which address existing shortcomings and add new types of functionality. These changes are quite broad in scope and make a number of significant new features available to .NET developers.

Application Identity-Based Security is a .NET buzzword for providing a restricted execution environment, based on information found in application and deployment manifests. New tools will be bundled with the next release to help determine the required application permission set. This identity-based schema is designed to fit into the newly introduced ClickOnce programming model in Windows and allow deployment of semi-trusted applications.

CAS will be extended to include demand choices, which will allow for presenting several choices for satisfying demands, and friend assemblies, similar to friend classes in C++, will be introduced

PKI will be fully integrated in the upcoming release, so falling back on CryptoAPI or WSE will no longer be necessary.

In addition to XML Signature, the upcoming release will include support for XML Encryption, both being fully integrated with the new PKI.

File-based Windows access control will be incorporated into the framework, which will allow setting file ACLs from managed applications.

Many of .NET's communication protection pitfalls are going to be fully or partially resolved in the upcoming release:

  • Allowing decoupling from IIS via adding server-side HTTP listeners.
  • Providing client and server classes for SSL conversation, and means of identity propagation over streams.
  • The new messaging framework, codenamed "Indigo", will incorporate all functionality formerly found in WSE into the core framework.

Last, but not least, ASP.NET 2.0 will include enhancements that take care of the drudgery of programming forms-based authentication and authorization via its new server controls, as well as Membership and Role Management APIs.

Specifics: Cryptography

In its 1.5 release, Java extends its already quite rich offering in the cryptography space, described in Part 2 of this series, with several new features.

Probably the most important addition to JCE is a new PKCS#11 provider, which, in contrast to other existing JCE providers that contain cryptographic implementations themselves, simply serves as a bridge to the installed PKCS#11 v2.0 implementations, to enable support for hardware accelerators and smartcards in Java applications. Its introduction caused a number of updates/enhancements to the existing core JCA/JCE and PKI classes, as well as creating new ones, which will allow communication with hardware tokens and smartcard-based keystores. Tools like Keytool and jarsigner have been updated as well to utilize the extended functionality available with the new provider. Additionally (though only on the Solaris 10 platform), JCE will take advantage of the Solaris Cryptographic Framework's PKCS#11 provider, which will result in significant (i.e., orders of magnitude) performance improvements.

JCE will be furnished with additional APIs to better support Elliptic Curves (ECC). Users, who previously have had to rely on external providers, can now use a number of standard ECC classes from the java.security namespace.

Several classes will be added or extended to support OAEP and PSS padding schemas, as defined in PKCS#1 v2.1 and W3C Recommendations for XML Encryption, enabling full support for the RSA-OAEP Key Transport algorithm.

In the javax.crypto namespace, existing classes are updated to facilitate key-related operations:

  • javax.crypto.EncryptedPrivateKeyInfo is extended with additional overloads of getKeySpec method to enable easier retrieval of private key information.
  • javax.crypto.Cipher class has new methods that allow retrieval of maximum values for key lengths and parameters.

The SunJCE default provider will have several new algorithms, which makes it a more attractive candidate for use in development: HmacSHA (256-512), RSA and RC2 encryption, and additional PBE algorithms.

Java's PKI implementation benefits from the improved PKCS#12 keystore implementation, which will have additional protection algorithms and support keystore read/write operations. This enhancement will substantially facilitate key and certificate exchange, especially when it comes to browsers, which tend to use PKCS#12 format for these operations.

Client-side support for the On-Line Certificate Status Protocol (OCSP), conforming to RFC 2560, will be added to PKI. In case of problems with the OCSP operation, Java applications will fail over to the traditional CRL checking via Certification Path API, which now boasts full PKIX compliance after passing the Public Key Interoperability Test Suite (PKITS) .

.NET's history with PKI has been quite spotty up until now (see Part 3), to say the least. The upcoming release brings the long-overdue integration of full PKI into the .NET framework, exposing managed implementations of Windows APIs for X509 and PKCS#7. Support for the former includes the newly updated X509CertificateEx, which essentially brings the features of X.509 certificate class from WSE into the core framework, and allows access to all certificate properties, as well as validation and chaining. Added support for PKCS#7 means easier interfacing to cryptography applications, written in other systems, particularly in Java, which already supports PKCS#7.

Continuing with its general XML push, .NET adds a fully W3C-compliant implementation of the XML Encryption recommendation. This implementation provides most popular symmetric and asymmetric algorithms, such as 3DES, multiple AES, and RSA, and is flexible enough to allow encryption of multiple sections inside one document with different keys. Both the existing classes for XML Digital Signature and the new ones for XML Encryption take advantage of functions in the integrated .NET PKI to utilize X.509 certificates for their operations.

Pages: 1, 2

Next Pagearrow