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.
|
The already-thorough Java offerings for communication protection at the platform and application levels, described in Part 2, are updated by enriching the existing JSSE model and further extended by adding SASL support.
Java's platform-level mechanism, JSSE, undergoes a significant facelift with the addition of a SSLEngine (fully described in the JSSE Reference Guide Addendum), which nicely abstracts the logic of SSL/TLS layer and allows advanced applications to take complete control of I/O and threading issues. At the same time, the simplicity of traditional socket-stream SSL programming has been preserved, and the SSLSocket class still implements that functionality.
An important change for JSSE is switching to using JCE providers exclusively -- in version 1.4, it still contains internal cryptographic code, which will be gone in the new release. Thus, JSSE will be able to take advantage of any configured JCE provider, including hardware accelerators.
Additionally, as a result of relaxing U.S. export restrictions, JSSE will now allow plugging in external providers, which should support a specific set of cipher suites. The JSSE Reference Guide Addendum contains the complete listing of required ciphers.
Kerberos suites have been included in the default SunJSSE provider, which provide support for Kerberos-based TLS communication, as described in RFC 2712.
At the application level, the existing GSS provider is augmented by adding a SASL implementation, which provides a lightweight authentication and security services for network communication. SASL is utilized by several popular modern Internet protocols, among them LDAP v3 and IMAP v4. Its advantage over JSSE and GSS lies primarily in very lightweight infrastructure requirements, whereas those two require complex setup, like PKI and Kerberos. However, it is expected that JSSE, GSS, and SASL mechanisms will be layered on top of each other in many implementations.
.NET, which has been clearly lagging in the communication space (see Part 2), finally catches up by providing a managed SSL/TLS implementation that is capable of protecting TCP-based socket-level communication. It operates via the SslClientStream and SslServerStream classes, and is very similar to the model used in Java. Fortunately, .NET does not stop there, and adds support for a standalone HTTP listener (implemented in the HTTPWebListener class), essentially removing mandatory application reliance on IIS for web interactions. Actually, a similar class has existed in .NET's Remoting infrastructure since v1.0 -- it was used in standalone applications under the covers for exposing Remoting services on HTTP channels. Now its functionality will be upgraded to include support for authentication and SSL.
The new "Indigo" messaging framework will incorporate all security standards from Web Services Architecture (WSA) released to date, which were formerly found in WSE. It further generalizes the concept of secure messaging by applying similar message-based security protection to different types of messaging mechanisms, such as ASMX and EnterpriseServices. The "Indigo" framework partitions security functionality in three security layers: TurnKey, Custom, and Extensibility. A majority of applications (80 percent) is expected to fall into the TurnKey category, which requires fully declarative support from the developers by adding declarative attributes and editing policy settings. The latter two categories are used for programmatical customization of the framework at different levels.
The signing process for Java's main code distribution vehicles, JAR files, has been described in Part 3 of this series. One of the shortcomings of the existing process is the inability to determine the validity of the archive relative to the certificate's expiration time. The addition of Signature Timestamps solves this problem by adding timestamps to the JAR signatures, thus allowing for checking whether the signing certificate was valid at the time of signing. The jarsigner tool will be updated to include new signing options, and the JAR API in the java.security package will extended with new classes and methods to access the timestamp information.
.NET extends its existing deployment model (XCOPY- or MSI-based) by introducing the ClickOnce deployment and update mechanism for server-based installations. It is based on using signed manifests and deployment files, similar to the model J2EE has been using for EJB deployments.
However, there are significant improvements waiting ahead -- for details of the manifest, see the preliminary MSDN Longhorn documentation. First, the application manifest will include security requirements of the application (not those of individual assemblies). These trust requests and the application's evidence are evaluated by the newly introduced TrustManager, and presented for the user's consent if an application requires additional permissions outside of the Secure Execution Environment (SEE). The results of this evaluation and the user's decision are stored on per-user and per-machine levels and used later for CAS decisions (see CAS section). Secondly, deployment manifests specify update policy, which allows secure, XML Digital-Signature-based application updates. An interesting detail about the manifest's structure is that it is the application manifest itself that is signed, and not the individual assemblies comprising the application -- they are represented in the manifest by their digests. In this respect, structure of .NET's application manifest resembles signed JAR files in Java.
The designers of .NET's Base Class Library (BCL) introduced a new feature for limiting code exposure: friend assemblies. The premise is that the internal classes in a particular assembly are declared to be accessible from another assembly, referenced by its PublicToken, much like how the friend declaration works in C++ for classes. Following the general .NET approach, this extension is introduced via a new assembly-level attribute, InternalsVisibleTo.
.NET's CAS model, described in Part 3, offers an excellent framework for code access security. However, it is rendered completely unusable for locally installed applications, which are blankly granted FullTrust by the default policy, meaning that any CAS permission check will succeed. The upcoming release of the .NET framework includes the ApplicationSecurityManager and TrustManager, which will make the decision of granting application trust requests based on the machine policy in effect and the application manifests (see the Deployment section).
At the same time, developers are urged to develop their applications targeting the Internet permission set, as an application sandbox with low trust and a "safe" permission set (preliminarily named Secure Execution Environment, or SEE) will be introduced in the Longhorn Windows OS (due in 2005) for executing applications. However, according to the preliminary MSDN Longhorn documentation, Longhorn's security system, as it is presently designed, does not attempt to verify trust of local .exe files that do not have deployment manifests, and simply grants them the same FullTrust as before. Hopefully, this policy will change by the release time, because, with its present design, this setup presents an unfortunate way to bypass the system checks in local scenario.
To allow several choices for attribute-based CAS demands, the CLR adds DemandChoice and LinkDemandChoice actions. Their logic is similar to the ordinary demands, but they allow specifying several attributes with different permission sets. Satisfying any of them is sufficient for the success of the overall check.
Java's flexible Authentication and Authorization Service (JAAS), which was reviewed in detail in Part 4, offers Krb5LoginModule among other so-called Pluggable Authentication Modules (PAMs). Presently, it does not include an option for TGT renewal, which causes their expiration in long-running services and requires either restarting the process or user intervention for re-authentication. Setting the newly introduced configuration option, renewTGT, to true will now result in automatic TGT renewals whenever expired tickets are retrieved from the ticket cache.
ASP.NET 2.0, which remains the primary web development platform for .NET, brings a whole slew of improvements for its existing forms-based authentication model (Part 4). Most importantly, it introduces Membership and Role Management APIs (found in the System.Web.Security namespace), which take care of tedious programming tasks by essentially eliminating, or significantly reducing the need for, writing security plumbing.
The Membership API takes care of the issues commonly present in password-based systems, such as secure credential operations (CRUD), finding and authenticating users, and password management. The Role Management API, based on ASP.NET Role model in 1.x, works together with the Membership API (although it can be accessed separately) to solve the user-to-role mapping issue and can be used programmatically and declaratively, in Web.config. Both APIs use a Provider Model design pattern, and are highly extensible (providers for SQL Server and Access are included in the default installation). If these APIs eventually are made available outside of the ASP.NET umbrella (like WSE Pipeline), they will provide a great and flexible addition to many types of .NET applications besides web-based ones.
New server-based GUI controls for ASP.NET take advantage of these new APIs, further reducing the amount of required programming, often making it as simple as dropping the controls on the form. The following controls will be made available, among others, in the new release: Login, LoginName, LoginStatus, LoginView, and PasswordRecovery.
Java does not offer any significant new features in the upcoming release, instead extending its offerings in existing categories.
.NET, on the other hand, aggressively pursues new security functionality. It will catch up with (or even pass) Java on several topics where Java currently holds an advantage, and extend its lead in the areas of its dominance. Most prominently, it catches up in the categories of communication protection and PKI, and it goes one more step ahead by adding full support for the W3C XML Encryption recommendation.
However, it is worth noting that with incorporation of .NET into the core Windows OS (starting with Windows 2003 Server), it is becoming progressively harder to distinguish .NET-specific features from OS features, as in the upcoming versions they are often designed to complement each other. This confusion might stem from the fact that Microsoft authors and spokespeople often do not specifically distinguish between the two in their publications and presentations, thus muddying the overall picture.
Incidentally, adding support for the WSA family of standards into the core .NET libraries prior to submitting them for approval by OASIS (with the exception of WS-Security, which already goes through the technical committee review) means that Microsoft probably does not expect any significant changes to the released set of specifications, or does not intend to submit them at all. Its intentions remain to be seen, but they certainly do not make life easier for Sun's developers, who have to shoot at a moving target in this case.
Denis Piliptchouk is a senior technical member of BEA's AquaLogic Enterprise Security group, participates in OASIS WSS and WS-I BSP standards committees, and regularly contributes to industry publications.
Return to ONJava.com.
Copyright © 2009 O'Reilly Media, Inc.