Java vs. .NET Security

Sky-Tiger

Secure Communication: Application
For finer control over applied security mechanisms, an application can use an application-level, token-based protection mechanism, abstract from the underlying transmission protocol. This approach has an advantage over channel blanket encryption by being smarter and protecting only sensitive data. For instance, web services (see later in this section) use this paradigm for message protection, where only particular details of messages are signed and encrypted.

As already explained, J2SE includes GSSAPI, which may be utilized on the application level to provide token-based protection using the Kerberos V 5. GSSAPI framework, is quite a thin wrapper, delegating all requests to the underlying mechanism providers. The Java GSS mechanisms do not perform user logins themselves -- they should be done using JAAS prior to invoking GSSAPI services, and the credentials should be stored in some cache accessible to the GSS mechanism provider. Using JAAS and Kerberos tickets in GSS provides not only transport-level security protection, but also a principal delegation mechanism over the network. See "Authentication" in Part 4 for more information about JAAS and delegation.

GSS classes reside in the org.ietf.jgss package; check the online documentation for details and code examples.

Overall, Java offers a choice of platform-level (JSSE) and application-level (GSS) protection services with similar security goals: client-server authentication and protection of transmitted data. Listed below are a few criteria that can help to decide which service is more appropriate for a particular application:

JSSE is very easy to use from client's code -- no action besides establishing the proper socket factory is needed. GSS setup and coding are significantly more involved.
Java's "Single Sign-On" mechanism is based on Kerberos V5, which is supported only by GSS.
JSSE implementations are socket-based and typically use TCP as the underlying protocol. GSS is token-based and can use any communication channel for token transmission -- the code is responsible for establishing the channel, though.
GSS is capable of client credential delegation.
JSSE encrypts all data sent through the socket. GSS, being token-based, can encrypt tokens selectively, thus significantly lowering computational load.
JSSE implements TLS 1.0 and SSL 3.0 communication protocols. GSS supports only the Kerberos V5 protocol (known as "SSPI with Kerberos" on Win32), and provides implementation of IETF's generic GSS-API framework.
Web services security specifications and toolkits also look at protecting individual messages, or tokens. This area has been rapidly evolving, and has not yet been fully standardized. Because of this lack of standards, both platforms provide only partial support for it via extensions or external products. However, since the topic of web services security alone warrants a whole separate book, it is not addressed here in any significant detail. Of all competing standards in this area, only SAML and WS-Security have been so far accepted for standardization by OASIS, with the latter still undergoing committee reviews.

For web services security, Microsoft is actively promoting its Web Service Architecture (WSA, formerly GXA), and adds support for all released up-to-date specifications via its Web Services Extension (WSE) pack for .NET. WSE is currently at 1.0 release, with 2.0 coming soon -- check the MSDN documentation for updates and new releases. Notably, WSE (and .NET in general) lacks support for SAML, even though the WS-Security specification does define binding for SAML assertions as one of the supported token types. In other areas, WSE provides relatively complete support of WS-Security and a number of other specifications. Additionally, WSE's certificate classes (located in the Microsoft.Web.Services.Security.X509 package) are much more convenient to deal with than .NET's original ones. The code sample below shows how to sign a request using WSE:

// Get SOAP context from the Web service proxy
SoapContext reqCxt =
               serviceProxy.RequestSoapContext;

// Retrieve the certificate to be used for signing
Microsoft.Web.Services.Security.X509.X509Certificate crt = ...;
// Create a X509 security token
X509SecurityToken token =
                     new X509SecurityToken(crt);

// Sign the request by adding
//a signature to the request
reqCxt.Security.Tokens.Add(token);
reqCxt.Security.Elements.Add(
                       new Signature(token));

// Use the signed request to call the service...
serviceProxy.Hello();
The extensible architecture of .NET's Remoting has allowed for the development of quite interesting approaches to transport security, whereas Remoting's RPC-style invocations are transmitted and protected by the means of SOAP-based web service messages. In principle, this is not very different from the Microsoft solution described earlier, but it allows applying WSA-family protection (in particular, WS-Security) to individual messages, which ensures standard-based authentication, integrity, and authorization at the message level, as opposed to the non-standard approach of blank encryption of the former solution. For explanations and code samples, read the excellent publications at the CodeProject web site, in particular ""Remoting over Internet"" and related articles.

The Java platform does not provide direct support for web services security yet. Currently, there are two web services security-related JSRs at work: JSR 155 "Web Services Security Assertions", and JSR 183 "Web Services Message Security APIs". When accepted (although they have been in review stage for over a year now), these specifications should provide assertions support and transport-level security to web services written in Java. Although not a standard part of Java platform, IBM's Emerging Technologies Toolkit v1.2 (ETTK), formerly known as Web Services Development Kit, or WSTK, adds support for the current draft of WS-Security and some other specifications from the WSA family, of which IBM is a co-author.

Note: The .NET platform stays very current with the latest developments in web services security, while their support in Java is not standardized and is limited to offerings from individual vendors.

Sky-Tiger

This is the third article in a series of Java vs. .NET security comparisons. It deals with the issues of code protection and distribution, and Code Access Security (CAS) mechanisms on those platforms. Previous articles of this series covered configuration and code containment in Part 1, and cryptography support and the mechanisms of communication protection in Part 2.

Once code or an algorithm has been written, it becomes an asset that requires protection. Such a protection is needed not only against theft, but also against unauthorized or unintended use. On the other hand, when somebody purchases a software package, he wants to be confident that he is not dealing with a counterfeit product. To answer all of these challenges, various techniques, broadly divided into cryptography-based and everything else, are employed for code protection and verification.

Code-access security is also known as policy-based security. It allows minimizing the risks of executing certain application code by providing policies restricting it to only a particular, well-defined set of operations that the code is permitted to execute. Of course, the underlying services (platform or application) have to actually carry out those checks for the policy to become effective.

Sky-Tiger

Code Protection: General
Issues discussed in this section are applicable, to a certain degree, to both platforms. They also employ similar protection mechanisms to combat those problems.

The possibility of the reverse engineering of distributed bytecodes needs to be taken into account when planning the security aspects of an application, because bytecode formats are well-documented for both Java and .NET (see also GotDotNet), so any hardcoded data or algorithms may be easily restored with readily obtainable decompiling tools. This point is especially important for avoiding hardcoding user credentials or non-patented algorithms in client-based application modules.


While there is no ideal way around this issue, short of shipping encrypted code and providing just-in-time decryption, an average perpetrator's task may be made harder by using so called obfuscators; i.e., tools that intentionally scramble bytecodes by using unintelligible names and moving entry points around. In addition to the obfuscator tool available with VS.2003, a number of decompiling/obfuscating tools can be found at the Microsoft web site. For Java, a great number of commercial or free Java decompilers and obfuscators can be found by running a simple search on the Web.

Finally, OS-level protection mechanisms need to be utilized, along with the platform ones, in order to ensure good protection of the stored data. All of the hard work at the platform level is useless if code or data can be obtained and inspected as raw binary files. Therefore, any normal OS operation security rules (like ACL, minimizing attack surface, the principle of "least privilege," etc.) should be employed in addition to the platform-specific ones, in order to ensure blanket protection.

Sky-Tiger

Certificate Management
Before addressing cryptography-based code protection features, the issue of certificate management in general needs to be covered, because all cryptography-based solutions deal, in one way or another, with certificates or keys. First of all, certificates need to be created and stored, and then accessed from the applications. Both platforms supply tools to issue certificate requests, as well as APIs for accessing the stored certificates.

.NET, as usual, heavily relies on Windows certificate stores to deal with certificates — they are used to store X509 certificates and certificate chains of trusted signers. There are a number of tools included with the .NET SDK to help accessing those stores, manage certificates, and sign assemblies using those certificates.

.NET's Certificate API is represented in its System.Security.Cryptography.X509Certificates namespace, where the X509Certificate class is of particular interest to us. Unfortunately, this class is rather poorly designed; it does not support accessing certificates in certificate stores, but works only with binary ASN.1 DER format, and does not provide any way to use it in asymmetrical encryption. The official suggestion from Microsoft is to stick with using unmanaged CryptoAPI (CAPI) functions, in particular CryptExportKey/CryptImportKey. See MSDN articles for details of bridging .NET's managed certificate implementation with CAPI.

Another, much better alternative is using WSE (already covered in Part 2). It provides the Microsoft.Web.Services.Security.X509 namespace with several useful classes, among them another version of X509Certificate, derived from the .NET-supplied one. This class recognizes the shortcomings of its predecessor and provides a very convenient interface for accessing certificate stores, as well as extracting public/private key information in a format appropriate for asymmetric encryption. As an added benefit, it can read certificates stored in Base64 text format. Together with the X509CertificateStore class, they make .NET's certificate API pretty well rounded. The following MSDN example shows how they can be used together:

// Open and read the Personal certificate store for
// the local machine account.
X509CertificateStore myStore =
  X509CertificateStore.LocalMachineStore(
  X509CertificateStore.MyStore);
myStore.OpenRead();

// Search for all certificates named "My Certificate"
// add all matching certificates
// to the certificate collection.
X509CertificateCollection myCerts =
  myStore.FindCertificateBySubjectString(
          "My Certificate");
X509Certificate myCert = null;

// Find the first certificate in the collection
// that matches the supplied name, if any.
if (myCerts.Count > 0)
{
  myCert = myCerts[0];
}

// Make sure that we have a certificate
// that can be used for encryption.
if (myCert == null ||
    !myCert.SupportsDataEncryption)
{
  throw new ApplicationException(
    "Service is not able to encrypt the response");
  return null;
}

Sky-Tiger

The Java platform implements RFC 3280 in the Certification Path API, which is supplied in the default "SUN" provider. This API, however, allows read-only — retrieving, accessing attributes, etc. — access to certificates, because they are considered to be immutable entities in Java. Classes implementing Certification Path API, belong to the JCA framework and can be found in the java.security.cert package. There are three classes of interest there:

Certificate: An abstract class for dealing with certificates.
X509Certificate: An abstract class for dealing specifically with X.509 certificates, stored using Base64 encoding, with BEGIN CERTIFICATE/END CERTIFICATE markers serving as delimiters.
CertificateFactory: A factory for generating certificate objects from their encoded formats.
Java uses so-called keystores for storing certificates. They can have different formats, as supplied by JCA providers (see Part 2); the default is Sun's proprietary JKS format. There are common keystores that contain keys, both public and private (or symmetric, if desired), and truststores, which are used to establish certificate chains. The JVM uses truststores (lib/security/cacert by default) to store the trusted certificates, and keystores for accessing key information. Having keystores as separate files is a nice feature in Java, as it is easy to move them around and manage them (compared to .NET's reliance on CAPI containers). Both stores can be specified as parameters on the command line, or accessed directly from code:

java -Djavax.net.ssl.keyStore=MyKeyStore
    -Djavax.net.ssl.keyStorePassword=password
    -Djavax.net.ssl.trustStore=MyTrust MyClass
Compared to the standard .NET certificate implementation, Java provides very convenient facilities of working with certificates. The examples below demonstrate how easy it is to obtain certificates from a keystore:

FileInputStream fin = new FileInputStream("MyKeyStore");
KeyStore ks = KeyStore.getInstance("JKS");
ks.load(fin,"password");
Certificate cert = ks.getCertificate("MyEntry");
or from a file:

FileInputStream fin =
            new FileInputStream("MyCert.cer");
CertificateFactory factory =
            CertificateFactory.getInstance("X.509");
X509Certificate cert = (X509Certificate)            
            factory.generateCertificate(fin);

Sky-Tiger

Java provides a tool for generating keys, keytool, which has a number of options. Among them are importing/exporting certificates, creating test certificates, creating certificate signing requests, etc. This tool picks up the keystore types (JKS, PKCS#12, etc.) defined in the java.security configuration file, and can use plugged-in provider types to operate on various types of keystores. By default, keytool generates only X.509 v1 certificates, which may be restricting for some applications.

Becoming a Certificate Authority (CA) on your own is problematic, but not impossible, with Java. One can either purchase a commercial library, or build his or her own CA using sun.security.x509 classes, although they only work with JKS keystores. However, the latter solution is neither portable nor documented. There are also a number of open source libraries that allow you to deal with certificate management, including CA functionality. A good free implementation is OpenSSL.

Note: Java provides a solid API for dealing with certificates. .NET programmers have to turn to unmanaged CAPI functions to access certificates, unless they use WSE, which adds a lot of useful functionality.

Sky-Tiger

Code Protection: Cryptographic
Cryptography-based mechanisms include certificates, digital signatures, and message digests, which are used to "shrink-wrap" distributed software and data. They establish software origin and verify its integrity with a high degree of reliability, subject to the strength of the underlying cryptography algorithm.




In their simplest forms, CRC or digests are used to verify software integrity. For more involved implementations, Message Authentication Code (MAC), or Hash-based MAC (HMAC), specified in RFC 2104, may be applied, which add cryptographic protection (using symmetric secret keys) for improved protection. Both platforms support most common digest, MAC, and HMAC functions in their respective cryptography namespaces. See Part 2 of this series for details of supported algorithms. Numerous code samples are available on the Web for both Java and .NET (also see MSDN).

These sample applications for .NET and Java demonstrate signing capabilities.

For application distribution, .NET supports software signing to prove application or publisher identities. For the first task, it provides so-called strong names, and for the second, signing with publisher certificates. These approaches are complementary and independent; they can be used individually or jointly, thus proving the identities of both the application and publisher. The users can configure .NET CAS policy based either on strong names, or on the software publisher, because they both provide strong assurances about the signed code. Because of their high levels of trust, strong-named assemblies can call only strong-named assemblies.

Strong names are used to prove authenticity of the assembly itself, but they have no ties to the author, as it is not required to use the developer's certificate to sign an assembly. A strong name can be viewed as a descendent of GUID mechanism, applied to the assembly names, and composed of text name, version number, culture information, plus the assembly's digital signature and a unique public key, all stored within the assembly's manifest, as shown in Figure 1:


Figure 1. Manifest of a Strong-Named Assembly

Sky-Tiger

The same key pair should not be reused for signing multiple assemblies — unique key pairs should be generated for signing different assemblies. Note that a version is not guaranteed by the strong name due to applying CLR versioning policy, as the same key will be reused to sign a newer version of the particular assembly. .NET provides a tool named sn.exe to generate key pairs and perform a number of validation steps related to strong names. Generated keys can either be picked up by AssemblyLinker, or added to the assembly declaratively by using an attribute:

[assembly: AssemblyKeyFile(@"CommonLib.snk")]
Clients, linked against a strong-named assembly, store a PublicKeyToken representing the assembly, an eight-byte hash of the full public key used to create its strong name, as shown in Figure 2. This is done transparently by the compiler when a strong-named assembly is referenced. This is an example of early binding.


Figure 2. Manifest with Public Key Token
Late binding can be achieved by using Assembly.Load and calling the full display name of the assembly, including its token:

Assembly.Load("CommonLibrary,
   Version= 1:0:1385:17444,
   Culture=neutral,
   PublicKeyToken=F5BE3B7C2C523B5D");
The CLR always verifies an assembly's key token at runtime, when it loads the referenced assembly. Two strong names are configured in security policy by default: one for Microsoft code, another for .NET's components submitted to ECMA for standardization.

Sky-Tiger

The CLR always verifies an assembly's key token at runtime, when it loads the referenced assembly. Two strong names are configured in security policy by default: one for Microsoft code, another for .NET's components submitted to ECMA for standardization.

Publisher certificates establish the identity of the code distributor by requiring him to use a personal certificate to sign a whole assembly or individual files in an assembly. The signature is then stored inside of the file and verified by the CLR at runtime. .NET provides the Signcode.exe tool to perform the publisher signing operation. To do its job, it should have access to both the publisher certificate (with a valid trust chain), and the private key for that certificate, which will be used to sign the file(s).

Publisher certificates, as opposed to the strong names concept, are used to sign multiple applications and cannot uniquely identify a particular code module, nor are they intended to. Their intent is to identify a broad set of applications as originating from a particular vendor, in order to assign appropriate permissions based on the level of trust in this company.

As far as signing distributives goes, Java offers a single route that is similar the publisher-signing paradigm in .NET. However, there are significant differences in the approaches, since JAR specifications permit multiple signers and signing of a subset of the JAR's content.

Quite surprisingly, in Sun's default distribution of JDK 1.4.2, only jce.jar is signed -- all of the other libraries do not have any signature. As a standard part of the JDK, Sun ships the jarsigner tool, which works with Java keystores to obtain private keys and certificates for signing and verification to validate certification chains. This tool operates on existing JAR files (it does not create them), which are a standard distribution format in Java.

jarsigner -keystore PrivateKeystore.jks
          -sigfile DP -signedjar DemoApp_Sig.jar
          DemoApp.jar denis
When a JAR file is signed, its manifest is updated and two new files are added to the META-INF directory of the archive (see the JAR Guide for details): class signature and signature block.

Sky-Tiger

The manifest file is called MANIFEST.MF and contains digest records of all signed files in the archive (which may be a subset of the archive!). Those records conform to the RFC 822 header specification and consist of a file name and one or more tuples (digest algorithm, file digest). As a rule, either SHA1 or MD5 digest algorithms are used. It is the manifest itself, not the physical JAR file, that is signed, so it is important to understand that once a JAR is signed, its manifest should not change -- otherwise, all signatures will be invalidated.

Manifest-Version: 1.0
Created-By: 1.4.2-beta (Sun Microsystems Inc.)

Name: javax/crypto/KeyGeneratorSpi.class
SHA1-Digest: HxiOMRd8iUmo2/fulEI1QH7I2Do=

Name: javax/crypto/spec/DHGenParameterSpec.class
SHA1-Digest: zU+QpzVweIcLXLjmHLKpVo55k0Q=
A signature file represents a signer, and an archive contains as many of these files as there are signatures on it. File names vary, but they all have the same extension, so they looks like <Name>.SF. Signature files contain "digests of digests" they consist of entries with digests of all digest records in the manifest file at the time of signing. Those records conform to RFC 822 header specification and have the same format as the manifest's ones. Additionally, this file also contains a digest for the entire manifest, which implies that the JAR manifest may not be changed once signed. Incidentally, this means that all signers have to sign the same set of files in the JAR — otherwise, if new files have been added to the JAR prior to generating another signature, their digests will be appended to the manifest and invalidate already existing signatures.

An important point to observe is that when a JAR file is signed, all of the files inside it are signed, not only the JAR itself. Up until JDK 1.2.1, signed code had a serious bug: it was possible to alter or replace the contents of a signed JAR, and the altered class was still allowed to run. This problem was rectified starting with version 1.2.1 by signing each class inside of a signed JAR.

Signature-Version: 1.0
Created-By: 1.4.2-beta (Sun Microsystems Inc.)
SHA1-Digest-Manifest: qo3ltsjRkMm/qPyC8xrJ9BN/+pY=

Name: javax/crypto/KeyGeneratorSpi.class
SHA1-Digest: FkNlQ5G8vkiE8KZ8OMjP+Jogq9g=

Name: javax/crypto/spec/DHGenParameterSpec.class
SHA1-Digest: d/WLNnbH9jJWc1NnZ7s8ByAOS6M=
A block signature file contains the binary signature of the SF file and all public certificates needed for verification. This file is always created along with the SF one, and they are added to the archive in pairs. The file name is borrowed from the signature file, and the extension reflects the signature algorithm (RSA|DSA|PGP), so the whole name looks like <Name>.RSA.

The JAR-signing flexibility comes from separating digest and signature generation, which adds a level of indirection to the whole process. When signing or verifying, individual signers operate on the manifest file, not the physical JAR archive, since it is the manifest entries that are signed. This allows for an archive to be signed by multiple entities and to add/delete/modify additional files in the signed JAR, as long as it does not affect the manifest (see the explanations in the signature file paragraph).

Note: Strong names in .NET offer an improved approach to versioning. JAR files, on the other hand, have more options for signing, so this category is a draw.