The Java Cryptography Architecture (JCA) is a framework for working with cryptography using the Java programming language. It forms part of the Java security API, and was first introduced in JDK 1.1 in the package.

The Java platform strongly emphasizes security, including language safety, cryptography, public key infrastructure, authentication, secure communication, and access control.

The JCA is a major piece of the platform, and contains a "provider" architecture and a set of APIs for digital signatures, message digests (hashs), certificates and certificate validation, encryption (symmetric/asymmetric block/stream ciphers), key generation and management, and secure random number generation, to name a few. These APIs allow developers to easily integrate security into their application code. The architecture was designed around the following principles:

  1. Implementation independence

Applications do not need to implement security algorithms. Rather, they can request security services from the Java platform. Security services are implemented in providers (see below), which are plugged into the Java platform via a standard interface. An application may rely on multiple independent providers for security functionality.

  1. Implementation interoperability

Providers are interoperable across applications. Specifically, an application is not bound to a specific provider, and a provider is not bound to a specific application.

  1. Algorithm extensibility

The Java platform includes a number of built-in providers that implement a basic set of security services that are widely used today. However, some applications may rely on emerging standards not yet implemented, or on proprietary services. The Java platform supports the installation of custom providers that implement such services.

Other cryptographic communication libraries available in the JDK use the JCA provider architecture, but are described elsewhere. The JavaTM Secure Socket Extension (JSSE) provides access to Secure Socket Layer (SSL) and Transport Layer Security (TLS) implementations. The Java Generic Security Services (JGSS) (via Kerberos) APIs, and the Simple Authentication and Security Layer (SASL) can also be used for securely exchanging messages between communicating applications.


COOPERATIVE LINUX, abbrieviated as coLinux, is a software that lets Microsoft Windows cooperate with the Linux kernel, to run both in parallel, on the same machine. Cooperative Linux utilizes the concept of a Cooperative Virtual Machine (CVM). In contrast to the traditional Virtual Machines(VMs), the CVM shares, the resources that already exist in the host OS. In traditional (host) VMs, resources are virtualized for every (guest) OS. The Cooperative Virtual Machine(CVM) gives both operating systems complete control of the host machine, while the traditional VM sets every guest OS in an unprivileged state to access the real machine.

The term cooperative is used to describe two entities working in parallel. In effect, Cooperative Linux turns the two different operating system kernels into two big *coroutines. Each kernel has its own complete CPU context and address space. Each kernel also decides when to give control back to its partner. However, while both kernels theoretically have full access to the real hardware, modern PC hardware is incompatibly designed to be controlled by two different operating systems at the same time. Therefore the host kernel is left in control of the real hardware, while the guest kernel contains special drivers that communicates with the host and provide various important devices to the guest OS. *program components that generalize subroutines to allow multiple entry points and suspending and resuming of execution at certain locations.

Dan Aloni originally started the development of Cooperative Linux based on similar work with User-mode Linux and LINE. He opened the source to the software under the GNU General Public License. Other developers have since contributed various patches and additions to the software.

Cooperative Linux is significantly different from traditional virtualization solutions such as VMware, plex86, Virtual PC, QEMU and other methods such as Xen, which generally work by running the guest OS in a less privileged mode than that of the host kernel. In contrast, the CPL0 approach simplified design with an early-beta development cycle of only one month -- starting from scratch by modifying the vanilla Linux 2.4.23-pre9 release until reaching to the point where KDE could run.

The only downsides to the CPL0 approach are stability and security. If it's unstable, it has the potential to crash the system (on earlier releases before ioperm was disabled, attempting to start a normal X server under coLinux would crash the host). However, measures can be taken, such as cleanly shutting it down on the first internal Oops or panic. Another disadvantage is security. Acquiring root user access on a Cooperative Linux machine can potentially lead to root on the host machine if the attacker loads specially crafted kernel module or (if the coLinux kernel was compiled without module support) the attacker finds some other way to inject code into the running coLinux kernel