| Sign In/My Account | View Cart |
Java vs .NET Security: EpilogueEditor'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.
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:
TrustManager that is based on CertPath provider.JCE is going to see some new functionality as well:
Java PKI is going to be updated as follows:
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.
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:
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.
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 |