Java vs. .NET Security

Sky-Tiger

This is the second article in a series on Java vs. .NET security comparisons. It deals with the issues of cryptography support and the mechanisms of communication protection on those platforms. The previous article in this series, Part 1, covered configuration and code containment.

In today's world, most of the means of secure data and code storage and distribution rely on using cryptographic schemes, such as certificates or encryption keys. Thus, cryptography mechanisms form a foundation upon which many important aspects of a solid security system are built, and it is crucial for a really secure platform to provide adequate support for these services.

Once an application steps out of the bounds of a single-computer box, its external communication is immediately exposed to a multitude of outside observers with various intentions, their interests ranging from employers scanning the list of web sites an employee visits to business spies looking for a company's "know-how." In order to protect sensitive data while it is en route, applications invoke different methods, most often with some kind of cryptographic protection applied to the data before transmitting it. Any respectable enterprise system has to demonstrate adequate protection measures in this area.

Sky-Tiger

Cryptography: General
Cryptography in .NET is based to a large extent on the Windows CryptoAPI (CAPI) service, with some extensions. Many algorithms are implemented as managed wrappers on top of CAPI, and the key management system is based on CAPI key containers. Most cryptography-related classes reside in the System.Security.Cryptography namespace, with certificate classes separated into X509Certificates and XML digital signature functionality into Xml subpackages. Web Service Extensions (WSE; see Secure Communication section) provides its own set of certificate classes in the Microsoft.Web.Services.Security.X509 package.

However, .NET's Cryptography service is more than just a managed wrapper -- it extends the CAPI in a number of ways. First, it is highly configurable and allows adding custom algorithm implementations in the machine.config file. Second, .NET uses a stream-based model, where all cryptographic transformations (except for asymmetric algorithms) are always performed on streams. Third, the defaults for all algorithms are configured to the strongest and safest settings (subject to Windows OS encryption settings, though), so the default objects that the user receives are most secure from what his Windows encryption settings allow.

The cryptography model of .NET is horizontally organized into several layers, and vertically grouped by types. Each family of algorithms (symmetric, asymmetric, etc.) forms a vertical hierarchy, deriving from a single root class for that family, with (usually) two more levels beneath it: an abstract algorithm level, and its concrete implementation. Family root classes are sealed; i.e. they cannot be extended by applications. This means, for instance, that the family of asymmetric algorithms can not be extended beyond the provided RSA and DSA abstractions. By .NET's convention, the implementation class is called Provider if it is a wrapper around a CAPI object, or Managed if it is a completely new implementation. The (simplified) System.Security.Cryptography class hierarchy is shown in Figure 1:


Figure 1. .NET cryptography class hierarchy
The Java platform's cryptography support has two parts to it: Java Cryptography Architecture (JCA) and Java Cryptography Extension (JCE), which were separated (due to US export restrictions) to gain exportability for the Java platform. All cryptography functions, which are subject to export laws, have been moved to JCE. In JDK 1.4, JCE became an internal part of the Java platform, instead of being an optional package, as it had been up to 1.4.

Sky-Tiger

Both JCA and JCE have a similar provider-based architecture, which is widely employed in many of the Java platform's solutions. Those packages consist of so-called frameworks, which implement the required infrastructure, and a number of additional providers supply cryptography algorithms. JCA and JCE frameworks are internal Java packages, and cannot be replaced or bypassed. The JCE framework authenticates JCE providers, which should to be signed by a trusted Certificate Authority (Sun or IBM) -- see the JCE Provider Reference for details.

Note that prior to v1.4, JCE was an extension and its framework classes could be supplied by a third-party vendor along with the provider itself, so the problem with signing could be avoided by removing Sun's JCE 1.2.2 provider and framework from the configuration. Since JCE has become a standard Java package, this poses a problem for independent vendors, because the involved procedure is rather long and complicated. Thus, with J2SE v1.4, vendors are forced to undertake the signing procedure, or begin developing proprietary solutions and abandon the JCE framework -- see the JCE Reference Guide for further information.

The JCA Provider framework model, shown in Figure 2, consists of the following elements:

Service (or Engine) abstract classes define types of functions available to developers, independent of particular algorithms: Asymmetric, Symmetric algorithms, Digests, etc.
Service Providers Interfaces (SPI) for each of those services link the high-level abstract Services to the provided implementations.
Provider is the central class that registers available implementations with the framework.
Security is the class that handles all providers.

Sky-Tiger

Cryptography: Algorithms
Most common industry-standard cryptographic algorithms (Symmetric, Asymmetric, Hashes, Signatures, PBE) and stream/block ciphers are available out-of-the-box on both platforms.

The following families of algorithms are supplied in System.Security.Cryptography namespace of .NET:

AsymmetricAlgorithm: digital signatures and key exchange functionality is also implemented by these family's providers (DSA,RSA).
HashAlgorithm: KeyedHashAlgorithm, MD5, multiple SHA.
SymmetricAlgorithm (DES, 3DES, RC2, Rijndael): additional parameters are specified by PaddingMode and CipherMode enumerations.
RandomNumberGenerator.
These asymmetric algorithm helpers are used together with configured asymmetric providers to do their jobs:

AsymmetricKeyExchangeFormatter/Deformatter: provides secure key exchange mechanism using OAEP or PKCS#1 masks.
AsymmetricSignatureFormatter/Deformatter: creates/verifies PKCS#1 v1.5 digital signatures, using any configured by name hash algorithm.
The .NET Cryptography library provides Password Based Encryption (PBE) functionality through its PasswordDeriveBytes class. It uses the specified hashing algorithm to produce a secret key for the targeted symmetric encryption algorithm. A sample application that demonstrates symmetric encryption with PBE to encrypt/decrypt is available as a .zip file for download.

Symmetric and hash transforms in .NET are stream-based, so multiple transformations can be chained together without creating temporary buffer storage. The CryptoStream class derives from the System.IO.Stream, and plugs into any framework where stream interfaces are acceptable: memory, data, network, and other kinds of data. CryptoStream accepts the ICryptoTransform interface, which it then uses internally to transform the data block-by-block by calling TransformBlock repeatedly. This interface is implemented differently by symmetric and hash providers:

Sky-Tiger

. Using Streams with Symmetric Algorithms
In case of a symmetric algorithm, the top-level SymmetricAlgorithm class defines the abstract methods CreateEncryptor/Decryptor. These methods' implementations in derived classes (providers) create an instance of CryptoAPITransform class, appropriate for the particular algorithm, and return it to use with CryptoStream. The CryptoAPITransform class internally hooks to the CryptoAPI Windows service to do the job using the _AcquireCSP and _EncryptData private unmanaged functions, as shown in Figure 3:


Figure 3. Streams with .NET symmetric algorithms

Sky-Tiger

2. Using Streams with Hash Algorithms
The HashAlgorithm family root class itself implements the ICryptoTransform interface, so any derived object can be used directly with CryptoStream. Its implementation of the TransformBlock method simply delegates the call to the derived class' implementation of the abstract method HashCore, as demonstrated in Figure 4:


Figure 4. Streams with .NET hash algorithms

In Java, the following services are defined in the JCA framework (java.security.* packages), and Sun supplies two JCA providers ("SUN" and "RSAJCA") with J2SE v1.4.2:

MessageDigest: data hashing algorithms (MD5, SHA-1).
Signature: data signing and signature verification (DSA, RSAwithSHA1, RSAwithMD5).
KeyPairGenerator: generation of public/private pair of keys for algorithms (DSA, RSA).
KeyFactory: key conversions (DSA, RSA).
KeyStore: managing keystores (JKS).
CertificateFactory: certificate creation and CRL management (X.509).
AlgorithmParameters: algorithms' parameter management, including their encoding (DSA).
AlgorithmParameterGenerator: algorithms' parameter creation (DSA).
SecureRandom: random numbers generators (SHA1PRNG).
As explained before, JCE has been separated out due to export restrictions. Its framework classes reside in javax.crypto.* packages and the Sun-supplied default provider "SunJCE" is shipped with J2SE v1.4.2:

Cipher: objects carrying out encryption/decryption according to an algorithm, mode, or padding (AES, DES, 3DES, Blowfish, PBE). Java ciphers have the additional functionality of wrapping/unwrapping secret keys to make them suitable for transfer or storage. The implementation and algorithm varies by provider (this can be a PBE, for instance).
CipherStream: combining input/output streams with a Cipher (CipherInputStream, CipherOutputStream).
KeyGenerator: generating keys for symmetric algorithms and HMAC.
SecretKeyFactory: conversions between key representations (AES, DES, 3DES, PBE).
SealedObject: protecting a serialized object's confidentiality with a cryptographic algorithm.
KeyAgreement: implementing Diffie-Hellman key agreement protocol (DH).
MAC: producing cryptographically secured digests with secret keys (HMAC-MD5, HMAC-SHA1, PBE).
Additionally, Sun's provider supplies some JCA algorithms used by JCE: KeyPairGenerator; AlgorithmParameterGenerator for DH; AlgorithmParameters managers for DH, DES, 3DES, Blowfish, and PBE; and KeyStore implementation for "JCEKS".

This sample application demonstrates symmetric encryption and PBE to encrypt/decrypt a data file.

Surprisingly, however, many third-party providers (both commercial and free) provide a better selection of algorithms. For comparison, check the list of algorithms provided by an open source implementation from Bouncy Castle.

Note: Both platforms supply plenty of algorithms with default installations. There are quite a few independent Java vendors who offer even better selection than Sun's defaults.

Sky-Tiger

Cryptography: Configuration
Cryptography systems on both platforms use configurable plug-in architectures -- new algorithms, or updated implementations of existing ones can be added without code changes, by changing just few properties in the system configuration files.

A distinct feature of .NET's symmetric, asymmetric, and hash crypto family hierarchies (see the Algorithms section) is their configurability -- all abstract classes in the hierarchies define static Create methods, allowing name-based lookup of the requested algorithm implementation in the machine.config file. New implementations may be mapped to existing (or new) names and will be picked up by the calls to the Create method, as explained later in this section. Classes of the Cryptography namespace that are not in those hierarchies do not follow this hierarchical approach and are not configurable by name.

At the heart of .NET Cryptography configuration lies the CryptoConfig utility class, which maps implementation classes to algorithm names, as configured in the machine.config file (or with the use of hardcoded defaults):

<cryptographySettings>
<cryptoNameMapping>
  <cryptoClasses>
   <cryptoClass MySHA1Hash="MySHA1HashClass,
                MyAssembly Culture='en',
                PublicKeyToken=a5d015c7d5a0b012,
                Version=1.0.0.0"/>
  </cryptoClasses>
  <nameEntry
     name="SHA1" class="MySHA1Hash"/>
  <nameEntry
     name="System.Security.Cryptography.SHA1"
     class="MySHA1Hash"/>
  <nameEntry
name="System.Security.Cryptography.HashAlgorithm"
     class="MySHA1Hash"/>
</cryptoNameMapping>
<oidMap>
  <oidEntry OID="1.3.14.33.42.46" name="SHA1"/>
</oidMap>
</cryptographySettings>
Application developers have the following choices when creating a configurable algorithm object:

Invoke the new operator on the specific implementation class. This approach completely bypasses the .NET configuration mechanism.
Call the CryptoConfig.CreateFromName method to map an abstract name to a specific algorithm implementation class.
Using the factory pattern, call an overloaded static Create method on one of the abstract classes in the algorithm's family hierarchy (family root, or algorithm abstraction). Both overloads of Create will end up calling CryptoConfig.CreateFromName to retrieve the implementation class.
Continuing with the previous configuration example:

//all calls return an instance of MySHA1HashClass

HashAlgorithm sha1 =
  System.Security.Cryptography.SHA1.Create();

HashAlgorithm sha1 =
  System.Security.CryptoConfig.CreateFromName("SHA1");

HashAlgorithm sha1 =
  System.Security.Cryptography.HashAlgorithm.Create();
Configuration's nameEntry tags form a lookup table, which is consulted when CryptoConfig.CreateFromName is called. Any string can be used as a name, as long as it is unique (see "Specifying Fully Qualified Type Names" in the MSDN documentation for character restrictions). The OID mapping is optional; it allows mapping ASN.1 Object Identifiers to an algorithm implementation. If no algorithm-name configuration is specified, the following defaults are used. Note the following strong defaults for algorithm families:

System.Security.Cryptography.HashAlgorithm: SHA1CryptoServiceProvider
System.Security.Cryptography.AsymmetricAlgorithm: RSACryptoServiceProvider
System.Security.Cryptography.SymmetricAlgorithm: TripleDESCryptoServiceProvider
In order to be usable after having been installed, Java's JCE providers should be made known to the runtime system. A Provider can be configured either declaratively in the java.security file:

// adding a crypto provider at the third position
security.provider.3=com.MyCompany.ProviderClassName
or programmatically by the code at runtime:

// appending a provider to the list
Security.addProvider(
          new com.MyCompany.ProviderClassName());
// adding a crypto provider at the third position
Security.insertProviderAt(
        new com.MyCompany.ProviderClassName(),3);
Programmatic runtime configuration assumes that the necessary permissions are granted to the executing code by the security policy (note that the providers themselves may require additional permissions to be specified):

// java.policy
// granting permissions for programmatic configuration
grant codeBase "file:/home/mydir/*" {
        permission java.security.SecurityPermission
                        "Security.setProperty.*";
        permission java.security.SecurityPermission
                     "Security.insertProvider.*";
        permission java.security.SecurityPermission
                     "Security.removeProvider.*";
}
Whether they were added declaratively or programmatically, all Providers end up in a single list and are queried for the requested algorithms (with optional parameters like mode and padding) according to their positions in the list (one being the highest) until finding a match. This process is shown in Figure 5. Algorithm and parameter names are hardcoded inside of the providers and cannot be changed. Developers can optionally request using only a particular provider, when they create an instance of an algorithm. This can be used, for example, when the developers want to use only particularly certified providers (for instance, DoD):

//requesting an implementation
//from only a single provider
Signature sigAlg1 = Signature.getInstance(
                "SHA1withDSA","MyGreatProvider");

//requesting the first matching implementation
Signature sigAlg2 = Signature.getInstance(
                "SHA1withDSA");

Sky-Tiger

Secure Communication
During transmission, data can be protected on three levels: hardware, platform, and application. These can be used independently, or combined for better results. In all cases, there is some kind of cryptographic protection applied to the data prior to communication, but the amount of required application code and its complexity increases, with application-level solution being the most involved. While wire-level protocols (IPSec, for instance) may be implemented at the hardware level for speed and efficiency, they are not discussed in this article in order to keep the primary focus on the platforms themselves.




At the platform level, SSL is the de facto industry standard of transport protection. Both platforms support (to some extent) the latest SSL 3.0 specification that allows mutual authentication of both client and server. Recently, TLS 1.0 specifications were released by IETF (RFC 2246) as a new standard for Internet communication security, which is supposed to gradually replace SSL.

Additionally, both platforms expose -- albeit at different levels -- implementations of the Generic Security Service API (GSSAPI) (RFC 1508, 1509) common standard, which defines a generic programming interface for different authentication and communication protocols.

Sky-Tiger

Secure Communication: Platform
Windows OS implements GSSAPI in the so-called Security Support Provider Interface (SSPI) to select one of the configured providers for securing data exchange over networked connections, which is used internally by .NET itself. However, as ridiculous as it sounds, .NET applications have only SSL configuration in IIS at their disposal for protection of HTTP-based traffic, while non-IIS based applications, such as standalone Remoting (the successor to DCOM) or HTTP servers, have no means of protecting their data en route. Not surprisingly, during the first year after .NET 1.0's release, protection of Remoting communication was one of the most frequently asked questions on the web forums.

There still exists no officially supported solution for securing Remoting communication, but fortunately, its highly flexible sink architecture allowed for the development of a number of low-level solutions that can be plugged into the infrastructure and server as a substitute for platform-level protection. Microsoft also apparently realized its omission, and released a fix in the form of two assemblies in the samples namespace, Microsoft.Samples: Security.SSPI and Runtime.Remoting.Security. The former exposes a managed SSPI wrapper, and the latter uses it to implement a Remoting sink featuring symmetric encryption. Another article, which appeared at MSDN Magazine, outlined an alternative approach to Remoting security using asymmetric encryption.

The Java platform offers Java Secure Socket Extensions (JSSE) as a platform-level service for securing TCP/IP-based communication in vanilla J2SE applications, and J2EE's servlet specifications declare options for configuring SSL protection and refusing unprotected connection attempts.

Additionally, application servers from various vendors usually include some means to configure the SSL protocol for their HTTP servers. Since these are proprietary solutions, they are not going to be further pursued in this document.

JSSE, originally an extension to J2SE, was incorporated as a standard package as of version 1.4, so any Java application may count on using its services. The standard JSSE API is located in the javax.net.* packages (javax.security.cert is obsolete and should not be used). It is quite rich; readers should consult the Javadocs for the specified packages and the online documentation for the class model and operation overview.

The example below shows a simple scenario of a client/server application, which will be satisfactory in most cases. Normal sockets are replaced with SSL ones by specifying different factory implementations, which are consequently used to obtain input/output streams:

//client establishing a connection
SSLSocketFactory clientFactory =
(SSLSocketFactory)SSLSocketFactory.getDefault();
SSLSocket sslSocket = (SSLSocket)
clientFactory.createSocket(host,port);

//use as a normal socket
OutputStream out = sslSocket.getOutputStream();
InputStream in = sslSocket.getInputStream();

...

//server accepting a connection,
//requesting mutual authentication
SSLServerSocketFactory serverFactory =
  (SSLServerSocketFactory)
   SSLServerSocketFactory.getDefault();
SSLServerSocket ss = (SSLServerSocket)
serverFactory.createServerSocket(port);
ss.setNeedClientAuth(true);

//use as a normal socket
SSLSocket socket = ss.accept();
OutputStream out = socket.getOutputStream();
InputStream in = socket.getInputStream();

...
A connection between two peers in JSSE is represented by a javax.net.ssl.SSLSession object. Among other things, this session contains negotiated shared secrets and information about ciphers used in the session. The master shared secret keys are not exposed through the JSSE API, and remain known only to the underlying implementation classes. Cipher information, however, is available for analysis, and the server may refuse a connection if the client does not use strong enough ciphers:

SSLSocket socket = ss.accept();
SSLSession session = socket.getSession();
String cipher = session.getCipherSuite();
if (cipher.equals("SSL_RSA_WITH_RC4_128_SHA") ||
cipher.equals("SSL_RSA_WITH_RC4_128_MD5")) {
        //sufficient strength, may continue
        ...
} else {
        throw new SSLException(
            "Insufficient cipher strength!");
}

Sky-Tiger

JSSE providers follow general JCE guidelines, and are pluggable into the provider-based JCA architecture. As a result, they may be configured in the java.security file, or added in code just like other security providers. Consequently, if a JCE provider, implementing the same algorithms as a JSSE one, is configured higher (i.e. it has a lower ordinal number -- see JCE Providers Configuration) in the crypto providers list than the JSSE provider, JSSE operations will use the JCE provider's implementations instead of the built-in ones. Note, however, that the JSSE cryptography algorithm implementations are private and not available for public usage. Also, as a departure from the usual provider model due to export restrictions, the default SSLSocketFactory and SSLServerSocketFactory cannot be replaced.

In JDK 1.4.2, Sun provides a reasonably good reference JSSE implementation named "SunJSSE," whose features are highlighted below. For the complete list, check the JSSE guide.

API and implementations of SSL 3.0 and TLS 1.0 algorithms.
Stream-based I/O classes: SSLSocket and SSLServerSocket.
One-way and mutual authentication. Certificate management is required and key and trust stores on both client and server should be set up appropriately.
Implementation of HTTPS. Actually, JSSE services can be applied to many application-level protocols, such as RMI, FTP, LDAP, etc.
Internal implementations for some cryptography algorithms.
Read-only implementation of PKCS#12 keystore, in addition to the default Java KeyStore (JKS).
Key and trust store management. For easier control, JSSE defines several system properties to control behaviors of appropriate classes from the command line.
The following properties (all starting with javax.net.ssl) may be specified on the command line or set in code: keyStore, keyStorePassword, keyStoreType, trustStore, trustStorePassword, and trustStoreType. For example:

java -Djavax.net.ssl.trustStore=AppTrustStore SecureApp
Java applications using RMI communication are pretty much limited to using JSSE for protection. Sun is working on separate specifications for secure RMI, which will include authentication, confidentiality, or integrity mechanisms, but they are not going to be available any time soon -- the JSR 76 "RMI Security for J2SE" was rejected in February 2001. Custom solutions are possible (such as subclassing SSLServerSocket), but they are non-trivial.

The J2EE specification promotes usage of SSL/TLS across all of its components by mandating support for the following ciphers:

TLS_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_MD5
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_RC4_40_MD5
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
In most cases, cipher suites will be either SSL_RSA_WITH_RC4_128_SHA or SSL_RSA_WITH_RC4_128_MD5 (or their TLS equivalents), as they are currently the strongest commonly used SSL ciphers.

The servlet specification defines the transport-guarantee element in the deployment descriptor, which is used to require a certain level of call protection from the servlet container. Possible values are: NONE, INTEGRAL, and CONFIDENTIAL, and can be specified in the /WEB-INF/web.xml file. The names for the constraints are pretty self-descriptive, and implementation interpretation is left at the vendor's discretion. However, the servlets have an option to programmatically reject a HTTP connection if the HttpRequest.isSecure method shows that the connection is not secure. Below is an example of specifying the transport guarantee element:

<security-constraint>
  <user-data-constraint>
    <transport-guarantee>
      CONFIDENTIAL
    </transport-guarantee>
  </user-data-constraint>
</security-constraint>
EJBs do not have an option to determine connection's security settings. EJB specifications, however, require passive support for remote calls' security; i.e., if a call is made using a secure connection, EJB server also uses a secure connection for further calls. Remote EJB calls use the IIOP protocol, with support for SSL 3.0 and TLS 1.0 support mandated by EJB 2.0 and J2EE specifications.

Note: Besides IIS, .NET does not offer any standard means for communication protection at the platform level, while Java has a complete solution in this space.