Feeds:
Posts
Comments

Introduction

Now we’re going to introduce the JAVA PKI programming scheme. As it was said before, JAVA has a security architecture based on providers, isolating the algorithms implementation from the cryptography services.

Basically, it relies on three packages: JCA, JCE and JSSE. Each package represents a collection of interfaces and abstract classes, specifying cryptographic services available for the developers. Something like the following picture:

JCA Schema

On the top level of picture you can see the API packages, containing interfaces and abstract classes definition. These APIs was defined by Sun, and are intended to be the most generic and independent from any particular standard. On the low level, there are the providers that implement one or more APIs.

First of all, we’re going to introduce the APIs.

JAVA Cryptography Architecture (JCA)

JCA is a provider based cryptographic API. It was intended to be the main API, covering all the high level PKI services and definitions. One doesn’t have to worry about key parameters, hash algorithms details and the using of padding in public key ciphering. He or she only have to think about hashing, signing and ciphering.

The key objects are treated in an abstract manner. You don’t need to go into specific concerns like public or private parameters, or neither the key storage and access details.

JCA provides the following services:

  • Resume (hash) generation;
  • Digital signatures;
  • Digital certificate supporting;
  • Certificate chains and CRLs supporting;
  • Key pair generation and handling.
  • Etc.

JCA is really generic about its services. When it defines the digital signature service, it is not committed to any kind of standard or algorithm, like RSA or DSA. Also, JCA doesn’t define particular schemes or signature presentations, such as PKCS#7 and XMLDsig standards.

Java Cryptography Extension (JCE)

JCE exists mostly due to export control restrictions by the U.S. Commerce Department. As JCA, JCE is a provider based API, and allows that any kind of algorithm, with any key size, can be plugged in the API. The U.S. Exporting policy was an effort to prevent this mechanism of ending in wrong hands (also known as Cuba, Iran, North Korea and other misfits nations).

To be conform to this policy, Sun Microsystems decided to separate the cryptography API in two: JCA and JCE. The second one would be an extension package subject to a jurisdiction policy. By default, this jurisdiction policy would allow applications to use strong specifications for algorithms and key sizes. No restricted nations would be allowed to use the unlimited policy.

We’re going later to see in more detail how to use this policy schema.

Java Secure Socket Extension (JSSE)

JSSE is a provider based API that defines services for secure communication in computer networks, using SSL and TLS connections. It completes Sun architecture, also leaving the implementation issues to the available providers.

Java Architecture Use Case

What is the scenario of using this architecture? If you need, for example, to add a password resume functionality to your application, what steps you have to follow?

First of all, you have to find a suitable hash service offered by JAVA API. You will easily find out that JCA has the MessageDigest service, which one defines methods for generating a resume of a particular message. MessageDigest exposes to you a clear interface, so you’re able to call its methods from your application code.

After deciding which service to use, you may choose a hash algorithm. For password resume, MD5 sounds nice.

Finally, you have to indicate a provider that implements MD5 algorithm for MessageDigest.

And voila!

Advertisements

Cryptography Concepts

I’m not going into theoretical cryptography and other PKI concepts in this blog. I assume that readers are well informed and used to all this science. Our objective, as I’ve already said, is to go into the development journey.

Anyway, I think it’s important to point some definitions, so we can speak the same language during the blog’s existence. Here it goes:

Key

A cryptographic key used in symmetrical cryptographic algorithms.

Public Key / Private Key

Cryptographic keys used in asymmetric cryptographic algorithms.

Message

Any sequence of bytes encoding a message that can be interpreted by a particular system or application. For example, the sequence of bytes 0x48 0x65 0x6C 0x6C 0x6F 0x20 0x57 0x6F 0x72 0x6C 0x64 encodes, using ASCII standard, the message “Hello World”, and can be interpreted by Notepad application. Another example would be the sequence of bytes contained in a JPEG image encoding and that could be interpreted by a Web Browser.

Ciphered message

A message transformed by a particular symmetric algorithm, using a cryptographic symmetric key, so the resulted byte sequence can’t be interpreted by the target system or application. The only way to recover the original message is applying an inverse transformation on the ciphered message using the same algorithm and symmetric key.

Ciphered key

A cryptographic symmetric key transformed by a particular asymmetric algorithm and public key, so the resulted byte sequence can’t be used to decipher messages. The only way to recover the original symmetric key is applying an inverse transformation on the ciphered key using the same algorithm and associated private key.

Resume or hash

A message transformed by a particular one-way and deterministic algorithm.

Digital signature

A message resume ciphered by an asymmetric algorithm and a private key. The process of decipher the digital signature using the asymmetric algorithm and the associated public key and comparing the resulting value to the message resume is called signature verification.

Frameworks and Libraries

Before we get started, I think it is worthy to write some words about the supporting frameworks and libraries we’re going to use in the examples here. Definitely this is not a complete list of existing libraries neither it contains the best ones. That’s my list of libraries, what I have been using all this time and about what I can say something.

Java Cryptography Architecture

JCA is Sun cryptography framework. Basically, it has definitions for a set of high level cryptographic services, including hash and digital signature generation, key store and digital certificates manipulation, and so on. The framework depends on cryptographic providers to implement the services, and make an abstraction of algorithms, keys specification and other low level details.

JCA services are defined in java.security package of JRE.

Java Cryptography Extension

JCE is an extension package of JCA. It was originally created in order to separate the cryptographic low level details from the main package, so it could be excluded from JAVA when shipped outside USA. Basically it has services related to ciphering and key specification. That specification has restrictions based on security policies. JCE also depends on providers to implement the cryptographic services.

JCE services are defined in javax.security of JRE.

Bouncy Castle

BC is the most famous JCA/JCE provider available, after the default one shipped with Sun JRE. BC has been providing a great variety of implementation for JCA services, including PKCS#12, Tiger, RSA and other algorithms not available in old versions of Sun default Provider.

BC is also a complete cryptography library, with services not defined by JCA/JCE, for example PKCS#7 package generation and ASN.1 data structure handle.

The library is distributed with an open source license, and has versions for JAVA and C# languages.

Win32 Cryptography API (CAPI)

CryptoAPI is probably the most known and used cryptography library, for just one reason: it supports the Windows family Operating Systems cryptographic environment. We will discuss that environment and CryptoAPI framework in more detail later (future postings).

For now, it is important to say that CAPI is similar to an architecture, like JAVA JCA/JCE. But just similar. It relies in a Win32 C library and proprietary internal structure, and is the base system for all Microsoft PKI development, including COM components and .NET applications.

CAPI is native in Windows OS (starting with Windows 95), doesn’t requiring additional installation.

Cryptography Next Generation (CNG)

CNG, as it stands for, is intended to be the next generation of PKI development for Windows Operating Systems. Eventually, it will replace CryptoAPI, providing application developers with a more robust and truly object oriented library. For now, CNG is available in Windows VISTA and Windows Server 2008, but it coexists together with CAPI, due to compatibility reason.

CNG is pretty much similar to JAVA JCA/JCE, and is based on concepts very close to cryptographic providers. It will be discussed in future postings.

Microsoft .NET Cryptography Namespace

Microsoft .NET framework came out in 2002 counting with a namespace dedicated to PKI: System.Security.Cryptography. Basically, it provided developers with some interfaces to CryptoAPI infrastructure. The first Framework versions, 1.0 and 1.1, was some kind of incomplete, making the library almost a useless peace of classes.

The Framework version 2.0 is a true and coherent library. It encapsulates all CAPI services and structures, enjoying the friendly and well designed programming architecture of .NET. Additionally, Microsoft .NET 3.0 and 3.5 allow programmers to interface with CNG native structures.

OpenSSL

OpenSSL is an open source toolkit devoted to SSL/TLS implementation and general purpose cryptography. It is probably the most trusty library in PKI world, since it counts with the state of art implementations for cryptographic algorithms and, as an open source project, it receives intellectual contributions from the best minds world wide.

OpenSSL is written in standard C and is intended to compile in any platform. It is used in the most known open source projects, such as Apache Web Server. Despite its recognized algorithms implementations, OpenSSL fails somewhat when we need to interact with key repositories and cryptographic devices.

We’ll be using OpenSLL here as it makes necessary.

Mozilla NSS

NSS (stands for Network Security Services) is the Mozilla library inherited from Netscape. It supports all the security functionality of Mozilla applications, such as Firefox and Thunderbird.

Mozilla architecture has its own cryptographic repositories, independent from Windows CAPI architecture. It interfaces with cryptographic devices using PKCS#11 standards.

There is a JAVA wrapper available for NSS, called JSS. Mozilla applications is shipped with a JCA/JCE provider, which one makes the interface with JAVA security schema.

We’ll be covering NSS later on this blog, since it takes special attention and efforts.

Web Application Libraries

One can use a couple of different solutions providing cryptography functionality for client site web applications, depending on the platform and purpose. For example, you could make use of JAVA Applets, ActiveX or XPCOM components.

When we need to achieve simple purposes, like an authentication using challenge response or an ordinary digital signature, and we can focus on a specific platform, there is two “libraries” that may help you kindly well.

One of this “libraries” is CAPICOM. It is a COM component encapsulated in a .cab file, and that is allowed to be distributed freely. It provides Windows CAPI store access, PKCS#7 signatures and envelopes and digital certificate validation. Unhappily, CAPICOM is only available for Windows and Internet Explorer web clients.

The other one, much simpler, is Mozilla Crypto. It is a Firefox internal wrap for NSS infrastructure, providing Javascript access to PKCS#7 detached signatures and NSS cryptographic store. It also handles key pair and CSR generation. In short, it is a good approach when you need a simple functionality and are focusing Mozilla Firefox browsers.

We’ll be discussing more about this and maybe other libraries as the blog goes on.

Overture

For the last 30 years, Computer Science has been well covered in a lot of books, magazines, courses and academic papers. Even before the Internet coming, the amount of technical information available for programmers, operators, system administrators and end users have been fair enough provided.

The same cannot be said about Information Security field. This subject had been out of books, specialized media and academic Computer Science courses for a considerable time. I am a good example: I took my Computer Science university course from 1994 until 1999. And I haven’t heard  a single word about InfoSec coming out from the mouths of my teachers.

I think that Internet could be seen as the turning point for InfoSec literature. Computer Networks brought to the IT agenda the security worries. Now it’s very easy to find blogs, articles, forums and portals dedicated to security. And there’s good universities around the world offering extension and postgrad courses to attend the Information Security market and research demands.

The purpose of this blog is not to discuss Information Security itself, but to focus on an specific InfoSec area: cryptography. You probably know a couple of blogs and literature covering Public Key Infrastructure (PKI). But we will be more specific here, because this blog is also about software development.

If so little has been said about PKI technology, almost nothing has been written or made available in any format about developing PKI software. The few available PKI literature in general covers an excessive scientific aspect of this technology: how to implement a hash algorithm, how to code the PKCS#1 standard in a more efficient way, C++ code implementations for the elliptic curve algorithm, etc. But, there’s much more people interested in put some cryptography functionality in their J2EE or .NET enterprise systems than hard nerds willing to be the coders of the next faster and best public key algorithm.

That’s the blog’s audience: people like me 6 years ago, when I was lost in a vast ocean of problems and and had no directions. All this years I’ve been trying myself a lot of available cryptography libraries, using C++, C#, JAVA and whatever was at hand. And today I think I can help you saving your time, so you can put all your attention in your software business. I’m sure you will find some helpful code or tip here. And I also expect to make this blog a place for ideas exchange, since I’m still looking for some directions. 🙂

Thank you for your visit.

Let’s make PKI technology a reality.


Bruno Ribeiro.

Welcome!

Welcome to the Cryptography Developer Blog!