MSBTE STATE LEVEL
TECHNICAL PAPER PRESENTATION
(Computer Engg. Group)
Title of the Paper :
JAVA CRYPTOGRAPHY ARCHITECTURE
Name of Authors :
1. Ms. Sonali Tharwani
2. Ms. Bharti Mulchandani
3. Ms. Naina Saita
Name of Institute :
INSTIUTE OF TECHNOLOGY, ULHASNAGAR
JAVA CRYPTOGRAPHY ARCHITECTURE
Abstract :
Cryptography isn't all there is to security. But rendering information unintelligible
to those without the proper key usually plays a big role in any networked data-sharing
system.
The Java language includes lots of classes that are designed to facilitate cryptography.
Key management classes, random-number generators, signed applets, and other parts of
the Java security mechanism are the key points to gain attention. Java Cryptography
teaches you how to write secure programs using Java's cryptographic tools. It includes
thorough discussions of the java.security package and the Java Cryptography Extensions
(JCE), showing you how to use security providers and even implement your own
provider.
* The Java Cryptography Architecture (JCA)
* The Java Cryptography Extension (JCE)
* Cryptographic providers
* The Sun key management tools
* Message digests, digital signatures, and certificates (X509v3)
* Block and stream ciphers
* Implementations of the E-mail signature and cipher algorithms
* A network talk application that encrypts all data sent over the network
* An email application that encrypts its messages
CONTENT :
Introduction :
Cryptography, the science of secret writing, is the biggest, baddest security tool in
the application programmer's arsenal.
Cryptography provides three services that are crucial in secure programming. These
include a cryptographic cipher that protects the secrecy of your data; cryptographic
certificates, which prove identity (authentication); and digital signatures, which ensure
your data has not been damaged or tampered with.
While speaking about java cryptography architecture the points that would seek attention
include:
Until modern times, cryptography referred almost exclusively to encryption, the
process of converting ordinary information (plaintext) into unintelligible gibberish (i.e.,
ciphertext).[1] Decryption is the reverse, moving from unintelligible ciphertext to plaintext. A
cipher (or cypher) is a pair of algorithms which perform this encryption and the reversing
decryption. The detailed operation of a cipher is controlled both by the algorithm and, in each
instance, by a key. This is a secret parameter (ideally, known only to the communicants) for a
specific message exchange context. Keys are important, as ciphers without variable keys are
trivially breakable and therefore less than useful for most purposes. Historically, ciphers were
often used directly for encryption or decryption, without additional procedures such as
authentication or integrity checks.JCA provides an implementation of cryptography-related
core classes. These include APIs for digital signatures and message digests and certificate
management infrastructure to support X.509 v3 certificates, including a key and certificate
store.
Engine Classes and Algorithms
An engine class provides the interface to a specific type of cryptographic service,
independent of a particular cryptographic algorithm or provider. The engines either
provide:



Cryptographic operations (encryption, digital signatures, message digests, etc.),
generators or converters of cryptographic material (keys and algorithm
parameters), or
Objects (keystores or certificates) that encapsulate the cryptographic data and can
be used at higher layers of abstraction.
The following engine classes are available:











SecureRandom: used to generate random or pseudo-random numbers.
MessageDigest: used to calculate the message digest (hash) of specified data.
Signature: initilialized with keys, these are used to sign data and verify digital
signatures.
Cipher: initialized with keys, these used for encrypting/decrypting data.
Message Authentication Codes (MAC): like MessageDigests, these also generate
hash values, but are first initialized with keys to protect the integrity of messages.
KeyFactory: used to convert existing opaque cryptographic keys of type Key into
key specifications (transparent representations of the underlying key material),
and vice versa.
SecretKeyFactory: used to convert existing opaque cryptographic keys of type
SecretKey into key specifications (transparent representations of the underlying
key material), and vice versa. SecretKeyFactorys are specialized KeyFactorys that
create secret (symmetric) keys only.
KeyPairGenerator: used to generate a new pair of public and private keys suitable
for use with a specified algorithm.
KeyGenerator: used to generate new secret keys for use with a specified
algorithm.
KeyAgreement: used by two or more parties to agree upon and establish a specific
key to use for a particular cryptographic operation.
CertificateFactory: used to create public key certificates and Certificate
Revocation Lists (CRLs).
Message Digests
An algorithm that takes an input of any size and produces as output a "fingerprint" of the
input data. Message digest algorithms are similar to hashing functions. A good message
digest algorithm will have an extremely low probability of producing the same digest
value for any unique output.


MD5 - Message Digest 5 - Developed by Ronald Rivest in 1991. Produces a 128bit message digest value. Implemented by the SUN provider.
SHA-1 - Secure Hash Algorithm - Developed by the National Institute of
Standards and Technology and the National Security Agency. SHA-1 produces a
160-bit message digest value. Implemented by the SUN provider.
Signatures
Attached to plaintext messages to verify that the message has not been tampered with in
transit and that it originated from a specific person. A signature is a digest of the message
produced with the signer's private key. The digest can then be decrypted by the recipient
using the signer's public key.

DSA - Digital Signature Algorithm - Developed by the National Security Agency
and standardized by the National Institute of Standards and Technology. DSA
uses a key between 512 and 1024 bits (in 64 bit increments). Implemented by the
SUN provider.
Authenticating a User
1. Message Digests provide an easy and secure way to authenticate a user in a clientserver application. The user types their username and password in at the log in
screen on the client side
2. The client generates a random number and a time stamp.
3. The username, password, random number and time stamp are fed to a message
digest algorithm which produces a meaningless digest of the information.
4. The client then generates a second message digest using the first digest value and
a second random number and time stamp
5. The following information is then transmitted to the server:
1. The username
2. The two random numbers
3. The two time stamps
4. The second message digest
6. When the server receives this information, it first checks the time stamps that it
received against the current time. If more than a specified amount of time has
passed, a login timeout has occurred
7. The server then looks up the user name to see if the user is in the database. If the
user is not in the database, the user is not verified.
8. Using the information sent by the client and the password associated with the user
in the database, the server generates its own copy of the password message digest.
9. If the client side digest and the server side digest is the same, the password is
correct and the user is authenticated.
Use of cryptography
Cryptography is important for the same reasons that photo IDs are important and
fences are important. In the digital world, cryptography offers three essential services that
protect you and your data from theft and fraud. These services are authentication,
integrity, and confidentiality.
There's a saying that "on the Internet, nobody knows you're a dog." One of the
things that's attractive about the Internet is the anonymity it offers. But if you're trying to
conduct business, it's a nightmare. Customers need to know that they're ordering goods
and services from real businesses. Cryptography offers "certificates" as a solution.
Certificates are sometimes called "digital IDs," because they can be used to verify the
identity of someone you don't know. This process is called "authentication", where you
decide whether someone is authentic or not.
Certificates can be used with another technique, "digital signatures", to ensure that
nobody can impersonate you. It's very easy to forge email, but it's really hard to forge a
digitally signed email message. And similarly, it's very hard for somebody else to modify
a message that you have digitally signed. This is called protecting the integrity of data.
It's very easy to eavesdrop on email, or any other transaction that takes place on a
computer network. How can you be sure that nobody finds out about your financial
transactions, or your medical records, or your secret business deals? Again, cryptography
has a solution, something called a "cipher". A cipher knows how to encrypt and decrypt
data. Before you send sensitive data over a network, or store it on a disk, you can encrypt
it, which turns it into an unreadable mess. When you need the data again, you use the
cipher to decrypt the data. If you play your cards right, you are the only person that will
be able to decrypt the data. If you're sending data to someone, you can ensure that only
that person is able to decrypt the message. Ciphers provide confidentiality because they
keep information secret.
Limitations!!
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.
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!
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:
1. 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.
2. 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.
References :
1. Java Cryptography -by O'reilly Publications.
2. Java2 Unleashed –by Sams Publications.
3. Search Engine.