Java vs. .

Net Security: Comparative study

Vishan Singh1 Dr. Dharminder Kumar2
Department of Computer Science and Engineering
Guru Jambheshwer University of Science & Technology
Hisar (Haryana)-125001
1
vishansingh139@gmail.com
2
dr_dk_kumar_02@yahoo.com

Abstract collection of standard classes which must be present

Now a days many systems execute untrusted
programs (developed in either Java or .Net) in virtual
machines (VMs) to limit their access to system
resources. Java is developed by Sun and .Net by
Microsoft for this purpose. Both platforms share
many design and implementation properties, but
there are key differences between Java and .NET that
have an impact on their security. There are a lot of
papers that have been presented for comparing these
two technologies. The intention of this paper is to
discuss Java and .Net at a high level from a security
perspective, examining the tools and methodologies
the platforms use to provide secure development and
deployment environments.
Keywords: code safety, code access security,
cryptography, communication, configuration, code
protection, user authentication, user access security,
JAAS, IIS .
on any supported platform. Standard classes for file
and network I/O, graphical user interfaces and
advanced topics like encryption or database access
allow many programs to run without bundled
libraries.
The Java environment is called Java Runtime
Environment (JRE), the .NET counterpart is Common
Language Runtime (CLR). Figure 1 shows the
conceptual architecture common to both
environments. The class loader is used to read byte
code from disk or other sources. The code is then
immediately checked for validity by the code verifier.
During runtime, the access controller ensures that
resources are protected. Byte code is called managed
code in .NET, to distinguish it from native code
which executes directly on the CPU. The roles of
those components are explained later.

1. Introduction
Java and .NET are both platforms for
executing untrusted programs with security
restrictions. There can be many types of risks while
using these programs such as these programs can be
Malevolent, Intrusive, faked etc [1] .
Java is both a programming language and a
runtime environment. What C# is for .NET is the Java
language for the Java runtime environment. When
Java is mentioned here, think about the environment.
Both .NET and Java programs could be written in
different languages. While for the .NET platform,
compilers for many languages exist, for Java only few Figure 1. Virtual Machine
compilers for other languages exist1. A reason The VM interprets the code and executes the
why .NET has more compilers for different languages program2. The most direct consequence is that
might be the Common Type System (CTS), which Java / .NET programs are not platform specific. On
defines the standard types needed in a .NET language, whatever architecture the VM has been ported, any
and the precise specification of interoperation of program can be executed. While Java has been ported
programs with the Virtual Machine (VM). to about every platform from Mainframe to the more
Both Java and .NET programs are executed powerful PDA’s, .NET is only available for windows
by a Virtual Machine (VM) which emulates a well systems. To make matters worse, it is highly
specified platform. The source code is compiled into depending on other Microsoft products like the
so-called byte code for Java respectively into the Internet Information Server (IIS).
Microsoft Intermediate Language (MS-IL) for .NET. Many research works have been done on
The runtime environment consists of the VM and a this topic in the recent years. Nathanael Paul and

1
David Evans [1] does there work on this topic
concentrating on code safety and polices used in both
platforms. David Buchmann [2] had worked on
permission management, language security and byte
code language. Ger Mulcahy [16] has compared the
architecture and cryptographic support of Java and
.Net. Eduardo B. Fernadez, Michael Thomsen, and
Minjie H. Fernandez [9] have also compared the
architectures of Java and .Net in their paper. Denis
Piliptchouk [10, 11, 12, 13] have given a series of
papers on java and .Net security.
2. Summary of work:
2.1 Low level code safety:
Low-level code safety comprises the
properties of code that make it type, memory, and
control-flow safe. Without these properties,
applications could circumvent nearly all high-level
security mechanisms. Type safety ensures that objects
of a given type will be used in a way that is
appropriate for that type [1] . Memory safety ensures
that a program cannot access memory outside of
properly allocated objects. Buffer overflow attacks
violate memory safety by overwriting other data by
writing beyond the allocated storage. Control safety
ensures that all jumps are to valid addresses. Without
control safety, a program could jump directly to
system code fragments or injected code, thereby
bypassing security checks.
In both environments, the respective VM
starts out with bytecode, which it verifies and
executes. The bytecode format is well known and can
be easily checked for potential violations, either at
loading or at execution time. Some of the checks
include stack integrity, overflow and underflow,
validity of bytecode structure, parameters' types and
values, proper object initialization before usage,
assignment semantics, array bounds, type
conversions, and accessibility policies. Both Java and
CLS languages possess memory- (or type-) safety
property; that is, applications written in those
languages are verifiably safe, if they do not use unsafe
constructs (like calling into unmanaged code). After
studying deeply the verification process in both
environments we found that JVM does not verify
local code by default. On the other hand, JVM always
preserves the bytecode stack for runtime checks,
while .NET relies on a combination of static analysis
and injection of verification code at runtime.
Now if the instruction sets of both languages
is compared then one main difference between the
instruction sets is that JVML has separate versions of
instructions for each type, whereas .NET uses a single
instruction to perform the same operation on different
2
types. This makes the verification process in java
more complex.
2.2 Code access security:
Code-access permissions represent
authorization to access a protected resource or
perform a dangerous operation, and form a foundation
of CAS. They have to be explicitly requested from the
caller either by the system or by application code, and
their presence or absence determines the appropriate
course of action.
Permissions: Code-access permissions represent
authorization to access a protected resource or
perform a dangerous operation, and form a foundation
of CAS. They have to be explicitly requested from the
caller either by the system or by application code, and
their presence or absence determines the appropriate
course of action. Both Java and .NET supply an
sample choice of permissions for a variety of system
operations. The runtime systems carry out appropriate
checks when a resource is accessed or an operation is
requested. .NET defines a richer selection here,
providing permissions for role-based checks [13] and
evidence-based checks. Also, some of its permissions
reflect close binding between the .NET platform and
the underlying Windows OS (EventLogPermission,
RegistryPermission) [12]. These bindings of the
permissions of .Net with the windows OS is a weak
point for it.
Polices: Code Access Security is evidence-based.
Each application carries some evidence about its
origin: location, signer, etc. This evidence can be
discovered either by examining the application itself,
or by a trusted entity: a class loader or a trusted
host(for further details see reference [12] ). A policy,
maintained by a system administrator, groups
applications based on their evidence, and assigns
appropriate permissions to each group of applications.
Evidence for the .NET platform consists of various
assembly properties [15].
For Java, two types of code evidence are
accepted by the JVM -- codebase (URL, either web or
local), from where it is accessed, and signer
(effectively, the publisher of the code). Both
evidences are optional: if omitted, all code is implied.
Policy links together permissions and evidence by
assigning proper rights to code, grouped by similar
criteria [14].
Policy-based security causes problems for
applets. It's unlikely that a web site's users will be
editing their policy files before accessing a site. Java
does not allow runtime modification to the policy, so
the code writers (especially applets) simply cannot
obtain the required execution permissions. IE and
Netscape have incompatible (with Sun's JVM, too!)
approaches to handling applet security. JavaSoft's
Java plug-in is supposed to solve this problem by
providing a common JRE, instead of the browser-
provided VM. If the applet code needs to step outside
of the sandbox, the policy file has to be edited
anyway, unless it is an RSA-signed applet. Those
applets will either be given full trust (with user's
blessing, or course), or if policy has an entry for the
signer, it will be used [14].
Policy in .NET has a much more
sophisticated structure than in Java, and it also works
with many more types of evidences. Java defines very
flexible approach to adding and overriding default
policies -- something that .NET lacks completely
[12].
2.3 Language Security:
The programming languages provide
important security features. Most important are the
public / protected / private and final modifiers for
fields and methods. A class can contain sensitive data
that might not be accessed by other classes. For
example, think of an applet requiring a valid credit
card number before processing. To save the state, a
private field has Paid is set to true. If the protection
would not be enforced, you could write code to set the
field to true. If “final” would not be enforced at
runtime, you could overwrite some important method.
Now we discuss the problems with pointers
used in the code. A pointer is just the address of a
memory cell. It can be used to read or write to
arbitrary cells. Other than spying on private data and
destroying data, a malicious program with direct
access to memory can make the CPU execute
uncontrolled code by writing it at the appropriate
location.
Neither Java nor normal .NET code can
therefore use pointers and operate directly on the
memory. This way, the Virtual Machine (VM) can
avoid that a process could gain access to memory
sections other than its own. In C, arrays are just
pointer to a memory segment. In C# and Java, arrays
contain a mandatory boundary check for any access.
The VM tests if casts are possible and throws
an exception on any illegal cast attempt. The VM
must prevent stack corruption too, as this again could
provide access to protected areas like private member
fields of other classes. Local variables may not be
used uninitialized, member variables are always
initialized to zero.
To enforce as much of those requirements
and language features, the byte code verifier is used.
When a VM loads code, it is first passed through the
verifier to check the security properties and any code
violating them is rejected. Such verified code which
executes under the control of the VM is called
“managed code” in .NET [2] .
3
Now for running the unsafe code a sandbox
is used for both java and .Net. The .NET sandbox is
called application domain. It is fixed when the
program is started. Additional assemblies are loaded
only loaded from the same application domain, so the
initial policy can always be used. To use code from
other domains, .NET remoting has to be used. The
Java protection domain is dynamic. For each access,
the currently valid protection domain is determined.
As long as the same class loader loaded them, classes
can use other classes directly. Only between different
class loaders, RMI is needed. While the Java
approach is more flexible, it is also more complicated.
This results in a speed penalty and may lead to
implementation errors, opening security holes in the
sandbox.
Both Java with the Java Native Interface
(JNI) and .NET with Platform Invoke (PInvoke)
allow the execution of code running directly on the
processor. This is important for projects to integrate
with existing libraries not written in a language
supported by the VM. But the VM can not verify
what that code does. It gives up control to the native
code which can do whatever it wants, allowing for all
the security issues discussed above to be violated.
Because of this, access to native libraries should not
be granted to untrusted code. The JNI is not often
used. The C# language however makes it simple to
mangle safe code with none-safe sections, by just
specifying the PInvoke keyword. The .NET
framework uses the term “unmanaged code” for such
native code, to emphasize that the VM has no control
over it(for more details see reference [2]).
2.4 Security Configuration:
Configuration on both platforms is handled
through XML or plain-text files, which can be
modified in any text editor, or through the supplied
tools. However, the platforms differ significantly in
how they handle configuration hierarchies.
In the .NET world, Mscorcfg.msc and
Caspol.exe can be used to modify all aspects of
security configuration. On the other hand, Caspol.exe
provides a number of command-line options,
appropriate for use in scripts and batch routines.
Here's how it would be used to add full trust to an
assembly: caspol -af MyApp.exe.
Java platform provides a single GUI-based
tool, policytool.exe for setting code- and Principal-
based security policies. This tool works with arbitrary
policy files (as long as they are in the proper format),
as opposed to .NET, where names and locations of the
configuration files are fixed (see Reference [10]).
J2SE does provide significant runtime
flexibility by using a number of command-line
application parameters, which allow the caller, on a
per-application basis, to set keyfiles, trust policy, and
extend the security policy. By allowing command-line
JVM parameters, Java provides a significantly more
flexible and configurable environment, without
conflicts among multiple JVM installations.
2.5 Cryptography:
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.
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. 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 [11].
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. A number of industry standard
cryptographic algorithms(Symmetric, Asymmetric,
Hashes, Signatures, PBE) and stream /block ciphers
are available for both platforms. with default
installations. There are quite a few independent Java
vendors who offer even better selection than Sun's
defaults.
Both java and .Net provides good
configurability. In the coding of .Net if the name of
the algorithm is not given then it takes it by default.
On the other hand in java provides name as well as
additional algorithm details as default. Defaults for
algorithm names are a convenient feature in .NET.
Java, on the other hand, allows specifying additional
algorithm details besides the name.
4
2.6 Secure Communication:
Data has to be exchanged over the network,
which is termed as communication. In both java
and .Net there are various mechanisms for this. In this
part we will discuss on these mechanisms.
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.
In case of .Net all the security while
communication depends mainly on the IIS, Non-IIS
applications have no means for protecting there data
on route. 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.
So after studying a lot on this it is found that
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. On
the other hand at the application level 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.
Now after studying deeply over
communication security provided by both platforms it
is concluded that Java fares much better by providing
a choice of both platform and application-level
solutions, it clearly lags behind .NET. When it comes
to support for web services security, here, Java
developers would have to turn to independent vendors
for the desired features.
2.7 Code protection:
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. 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.
Finally, OS-level protection mechanisms need to be
utilized, along with the platform ones, in order to
ensure good protection of the stored data [12].
At first we discuss certificate management as
a mechanism for both java and .Net platforms. 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.
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
(See Reference [12]). Becoming a Certificate
authority is problematic but not impossible for 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.
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.
2.8 User Authentication:
The process of authentication starts right
after identification by collecting caller credentials,
confirming the identity claim, and securely
communicating them to the server. Those credentials
(possibly several types of them, so it's called multi-
factor authentication) are matched against the
registered account information and a positive or
negative answer is returned regarding the claimed
identity. To do this work, application developers can
either utilize standard platform facilities, as described
below, or roll out some custom authentication
5
solution (for instance, biometric readers), which is
outside of the scope of this paper.
.NET includes a web solution for the server
side: ASP.NET, which is coupled with IIS for
processing HTTP requests (for details see reference
[13]). The Java platform defines two solutions for
user authentication to the servers: JAAS and servlets.
Although EJB does not have its own authentication
facilities [14]. Java servlets is the Java platform's
HTTP-oriented server layer, which performs HTTP
processing functions similar to those of the ASP.NET
layer [14]. Correspondingly, the servlet's security
model is intended specifically to handle the
requirements of web applications. JAAS may be used
to add authentication and authorization to any Java-
based application (executable, bean, applet, etc) [14].
In both systems, a principle and his identity (or
identities) are established as a result of the
authentication process, which serve to represent the
user in the application during his further requests.
Now in case of web services .NET delegates
all types of user authentication (except for forms) to
IIS, and barely consumes the results. J2EE requires
support for all standard authentication mechanisms
from the compliant servers. .NET provides good
support for impersonation on Windows-only
networks, but delegation across the Internet is not
possible. Java can do application-level impersonation
and is capable of supporting delegation across the
Internet.
Finally it is concluded that .NET suffers
from tight integration with IIS, without which it is not
really capable of performing authentication. In terms
of access control, it does provide a convenient
mechanism that meshes nicely with its CAS features.
2.9 User access security:
Once a distinguished principle has been
identified as a result of the authentication step and
attached to the call context (usually associated with
threads), it can be used in determining resource access
rights. In role-based systems, application code may
operate not only with specific principals, but also with
their abstract roles, which results in a more flexible
system configuration. So after establishing a
principle, the server goes through an additional step
of mapping it to the possible application roles. .NET
has a very convenient, permission-based user access
system. However, it can only restrict the total
permission set for an assembly, never extend it. JAAS
makes use of dynamic policies in Java to extend a
granted permission set with user-specific permissions.
For extended access checks, both systems
provide an adequate level of declarative support. Java,
in addition to the standard authentication types, offers
the powerful JAAS mechanism as its primary vehicle
for adding authentication and Principal-based
authorization to Java applications, which adds a lot of
flexibility to the design choices.
3. Conclusion:
Java and .Net are two comparable platforms,
very similar to each other. In this paper we have tried
to compare .Net and Java platforms and to find out
differences between them with regards to security.
In case of code containment both platforms
have pretty strong offerings, with .NET having
slightly more choices and being more straightforward
to use.
CAS features in .NET are significantly better
than the ones Java can offer, with a single exception
-- flexibility. Java, as it is often the case, offers ease
and configurability in policy handling that .NET
cannot match.
In Java language security features as
discussed above are more secure then .net, on the
other hand .Net provides more functionality then java.
In case of security configuration java offers a
lot of advantages then .Net discussed above.
Both platforms come out pretty even in
terms of cryptographic features, although Java has a
more complicated solution due to the obsolete US
export restrictions.
In case of communication protection -- while
Java fares much better by providing a choice of both
platform and application-level solutions, it clearly
lags behind .NET when it comes to support for web
services security.
While code protection came out more or less
even, CAS features in .NET are significantly better
than the ones Java can offer, with a single exception
-- flexibility.
We now come to the point of user
authentication .NET suffer from tight integration with
IIS, without which it is not really capable of
performing authentication. In terms of access control,
it does provide a convenient mechanism that meshes
nicely with its CAS features.
At last we come to the point of user access
security Java, in addition to the standard
authentication types, offers the powerful JAAS
mechanism as its primary vehicle for adding
authentication and Principle-based authorization to
Java applications, which adds a lot of flexibility to the
design choices.
4. References:
[1] Nathanael Paul, David Evans. Comparing
Java and .NET Security. University of
Virginia, Department of Computer
Science. [nate, evans]@cs.virginia.ed
[2] David Buchmann. Basic Security: Java vs.
.NET. University of Fribourg, Switzerland,
Department of Informatics, Software
Engineering Group, May, 2003.
http://diuf.unifr.ch/softeng/
[3] Frank Yellin. Low Level Security in Java. 4th
International WWW Conference, December
1995.
[4] David Evans and Andrew Twyman. Policy-
Directed Code Safety. IEEE Symposium on
Security and Privacy. May 1999.
[5] Sun Microsystems. Permissions in the Java 2
SDK. http://java.sun.com/j2se/1.4.2/docs/guide/
security/permissions.html
[6] .NET Framework Developer’s Guide.
Permissions.
http://msdn.microsoft.com/library/
default.asp?url=/library/en-
us/cpguide/html/cpconpermissions.asp
[7] Microsoft Corporation. Technology Overview.
http://msdn.microsoft.com/netframework/
previous/v1.0/overview/default.aspx
[8] Scott Oaks. Java Security 2nd Edition.
O’Reilly, 2001.
[9] Eduardo B. Fernadez, Michael Thomsen, and
Minjie H. Fernandez, Comparing the
Security architectures of Sun ONE and
Microsoft .NET. Department of Computer
Science and Engineering,
Florida Atlantic University.
[10] Denis Piliptchouk. Java vs .NET Security, Part
1 Security Configuration and Code
Containment. Nov, 2003.
[11] Denis Piliptchouk. Java vs .NET Security, Part
2: Cryptography and
Communication. Dec. 2003.
[12] Denis Piliptchouk. Java vs .NET Security, Part
3: Code Protection and Code Access
Security (CAS). Jan., 2004.
[13] Denis Piliptchouk. Java vs .NET Security, Part
4: User Authentication and
Authorization. Feb 2004.
[14] J2EE Security, for servlets, EJBs and web
services, Pankaj Kumar, Pearson Education.
[15] .Net Framework Security, Brian A. Lamacchia,
Sebastion, Mathew Lyons, Rudi Martin,
Kevin T Price, Pearson Education(Asia).
[16] Ger Mulcahy, J2EE and .Net security. Feb
2002.