|
JAVA CRYPTOGRAPHY: A BIRDÂ’S EYE VIEW |
|
|
|
Written by Atul Kahate
|
|
Jan 01, 2007 at 10:45 PM |
Cryptography in Java has been a topic of interest for quite some time.
Several hurdles had to be crossed before Java cryptography reached the
state of maturity and popularity it enjoys today. In this article we
will look at the origins of Java cryptography, the challenges faced and
where things stands today.
Java Cryptography Challenges
1) Java cryptography had to be made available to all applications,
client-server or Web-based. In other words, the first challenge was to
ensure that regardless of the underlying communication mechanisms (HTTP
or RMI) the same cryptographic APIs should work.
2) The US government had put restrictions on exporting
software including strong cryptography. Strong cryptography generally
meant encrypting plain text with a key of more than 40 bits. Its
counterpart, weak cryptography got its name from the belief that 40-bit
keys could be broken with some amount of work, but anything over 40-bit
keys were tough to crack. This challenge was tougher one to overcome,
since it was not in the scope of Java cryptography designers.
Many western countries, especially the US and NATO allies used to fear
that terrorists could use strong cryptography to encrypt secrets that
could not be understood by the US National Security Agency (NSA).
Therefore, the argument was simple: ban export of strong cryptography!
This was subsequently questioned by several security experts, who
claimed that banning strong cryptography was not the answer to the
problem. Moreover, what one meant by export was not clear. If a person
used strong cryptography to encrypt something in the US and send it out
via an email to another country, would that be considered as export? Or
was carrying a floppy or CD-ROM export? Nobody knew! Consequently,
strong cryptography was allowed.
However, when Java cryptography was born, it was still in the
disallowed state.
Cryptography in Web-based applications
Until JavaÂ’s emergence in this space, cryptography was quite
difficult in Web-based applications. This could be explained as follows.
On the client side, the browser has traditionally been thin. That is,
the browser should not occupy too many resources, and should be as
lightweight as possible.
The server side was a bit chaotic. Various dynamic Web page
technologies had emerged; key examples of which were CGI, ASP,
Coldfusion, and Servlets/JSP. None of them had true cryptographic
capabilities.
To overcome these problems, one had to buy/license cryptographic
toolkits from companies such as RSA, Entrust, and Baltimore. These
toolkits supplied cryptographic APIs in C++ and Java (and in rare
cases, in Visual Basic as well). So, one had to write application
programs that would make use of these APIs to perform cryptographic
operations.
On the server side, usually this was not a problem, since some
server-side application could use the toolkit APIs. But on the client
side, this was cumbersome, since there was no application to make use
of these toolkit APIs in the first place! Applets were slow, ActiveX
controls were perceived to be dangerous, and plug-ins did not work
universally.
JavaÂ’s aim was to change all of this. Let us understand how
Java cryptography designers tried to solve these problems.
Java Cryptography Solutions
To tackle the issue of restrictions on strong cryptography, Java
designers took a novel approach (subsequently also implemented by
Microsoft in its .NET framework). They split the Java cryptographic
operations into two modules, one of which could be exported without any
problems, and the other one could not be. These two modules were:
- Java cryptography Architecture (JCA)
– Dealt with
key management, digital certificates, etc. This was not related to
strong/weak cryptography, and therefore, could be freely used/exported
anywhere. As a result, JCA was made a part of Java Development Kit
(JDK) itself.
- Java cryptography Extensions (JCE)
– JCE was the
module that dealt with actual encryption/decryption operations.
Naturally, the aspects related to strong/weak cryptography were related
to JCE. Wisely, JCE was kept out of JDK, so that it could be used or
restricted, depending on the factors associated with strong
cryptography.
Like most other APIs, Java designers exposed these two modules to the
application programmers in the form of Java packages. Various classes
and interfaces were provided to deal with the various cryptographic
requirements, ranging from using digital certificates or keys to
performing encryption or digital signatures.
Eventually, when the restrictions on strong cryptography were removed
by the US government, JCE was merged into JCA. Starting with Java 1.4,
JCE is no longer considered as a separate entity. Instead, now a
reference to JCA automatically means JCA and JCE. We will consider this
terminology to be applicable to the discussion below.
Java cryptography Architecture (JCA)
The JCA is designed using the standard
Java interface-implementation
paradigm. In other words, an application program wanting to use the
services of JCA needs to make use of standard JCA interfaces and APIs.
These are standard, and remain the same across different
implementations.
A particular implementation of JCA would be provided
by a Cryptographic Service Provider (CSP). This can be provided by Sun
itself, or by companies such as IBM, Apache, etc. Choosing a particular
JCA would completely depend on the licensing aspects as well as cost
requirements. An application programmer is not bothered with the
differences between the various service providers. An application
program has a universal interface to work with.
Client side cryptography
On the client side, cryptography can primarily be done by using either
applets or JavaScript. Applets are quiet slow, and therefore, it is
better to use JavaScript. However, in the future, this may change, as
the browser technology evolves and becomes more programmer-friendly.
Conclusion
Java cryptography is widely used today. It has emerged as a good, free,
cryptographic toolkit as compared to some toolkits that need to be
licensed. At the same time, we must remember here that just because
Java cryptography is free, it is in no way inferior to other products
that need to be purchased separately. It can be easily integrated with
any Java application or server-side Java technology, such as
Servlets/JSP, EJB, etc. Of course, if the Secure Socket Layer (SSL)
technology is used, Java cryptography need not be used for encryption
of data, but it can still be used for digital signatures, which are not
in the scope of SSL.
 Atul
writes about Java Security in this monthly
column on IndicThreads.com. Atul is the author of 13 books including
"Cryptography
and Network Security".
He is currently a Project Manager at i-flex solutions limited, Pune,
India. Atul can be reached at (akahate at gmail
dot com)
---
Related
AJAX
Security Threats and Performance Challenges
Enterprise Java Security
Presentation From The
IndicThreads.com Conference On Java Technology
Professional
Java, JDK 5 Edition: 8I book review
|
|
Home | 
