Glossary

The Java^TM Tutorial

Start of Tutorial > Start of Trail > Start of Lesson

Search
Feedback Form

Trail: Security in Java 2 SDK 1.2
Lesson: Summaries

Glossary

Below are definitions and explanations of some general security and JDK security-specific terms and concepts, in alphabetic order.

Certificate

A certificate is a digitally signed statement from one entity (person, company, etc.), saying that the public key of some other entity has some particular value. If you trust the signature on the certificate, you trust that the association in the certificate between the specified public key and the other entity is authentic.

Cryptography Algorithm

A cryptography algorithm is an algorithm used to help ensure one or more of the following:

the confidentiality of data

authentication of the data sender

integrity of the data sent

nonrepudiation; a sender cannot deny having sent a particular message

A digital signature algorithm provides some of these characteristics. Also see message digest algorithms. Digital signature and message digest algorithms are available in JDK 1.1.
A separate release (Java Cryptography Extensions) provides APIs and algorithms related to encryption and decryption.

Decryption

Decryption is the inverse of encryption; the process of taking ciphertext (encrypted data) and a cryptographic key, and producing cleartext (the original unencrypted data).

Digital Signature

A digital signature is a string of bits that is computed from some data (the data being "signed") and the private key of an entity. The signature can be used to verify that the data came from the entity and was not modified in transit.
Like a handwritten signature, a digital signature has many useful characteristics:

Its authenticity can be verified, via a computation that uses the public key corresponding to the private key used to generate the signature.

It cannot be forged, assuming the private key is kept secret.

It is a function of the data signed and thus can't be claimed to be the signature for other data as well.

The signed data cannot be changed; if it is, the signature will no longer verify as being authentic.

Domain or Protection Domain

A protection domain ("domain" for short) encloses a set of classes whose instances are granted the same set of permissions.
In addition to a set of permissions, a domain is comprised of a CodeSource, which is a set of PublicKeys together with a codebase (in the form of a URL). Thus, classes signed by the same keys and from the same URL are placed in the same domain. Classes that have the same permissions but are from different code sources belong to different domains.
Currently in JDK 1.2, protection domains are created "on demand" as a result of class loading.
Today all code shipped as part of the JDK is considered system code and runs inside the unique system domain. Each applet or application runs in its appropriate domain, determined by its code source.

Encryption

Encryption is the process of taking data (called cleartext) and a cryptographic key and producing ciphertext, which is data meaningless to anybody who does not know the key.

Engine Class

An "engine class" defines a cryptographic service in an abstract fashion (without a concrete implementation).
A cryptographic service is always associated with a particular algorithm or type, and it either provides cryptographic operations (like those for digital signatures or message digests), generates or supplies the cryptographic material (keys or parameters) required for cryptographic operations, or generates data objects (keystores or certificates) that encapsulate cryptographic keys (which can be used in a cryptographic operation) in a secure fashion. For example, two of the engine classes are the Signature and KeyFactory classes. The Signature class provides access to the functionality of a digital signature algorithm. A DSA KeyFactory supplies a DSA private or public key (from its encoding or transparent specification) in a format usable by the initSign or initVerify methods, respectively, of a DSA Signature object.
API clients request and utilize instances of the engine classes to carry out corresponding operations. The following engine classes are defined in JDK 1.2:

MessageDigest - used to calculate the message digest (hash) of specified data.

Signature - used to sign data and verify digital signatures.

KeyPairGenerator - used to generate a pair of public and private keys suitable for a specified algorithm.

KeyFactory - used to convert opaque cryptographic keys of type Key into key specifications (transparent representations of the underlying key material), and vice versa.

CertificateFactory - used to create public key certificates and Certificate Revocation Lists (CRLs).

KeyStore - used to create and manage a keystore. A keystore is a database of keys. Private keys in a keystore have a certificate chain associated with them, which authenticates the corresponding public key. A keystore also contains certificates from trusted entities.

AlgorithmParameters - used to manage the parameters for a particular algorithm, including parameter encoding and decoding.

AlgorithmParameterGenerator - used to generate a set of parameters suitable for a specified algorithm.

SecureRandom - used to generate random or pseudo-random numbers.

An engine class provides the interface to the functionality of a specific type of cryptographic service (independent of a particular cryptographic algorithm). It defines "Application Programming Interface" (API) methods that allow applications to access the specific type of cryptographic service it provides. The actual implementations (from one or more providers) are those for specific algorithms. The Signature engine class, for example, provides access to the functionality of a digital signature algorithm. The actual implementation supplied in a SignatureSpi subclass (see next paragraph) would be that for a specific kind of signature algorithm, such as SHA1 with DSA, SHA1 with RSA, MD5 with RSA, or even some proprietary signature algorithm.
The application interfaces supplied by an engine class are implemented in terms of a "Service Provider Interface" (SPI). That is, for each engine class, there is a corresponding abstract SPI class, which defines the Service Provider Interface methods that cryptographic service providers must implement.
An instance of an engine class is created by a call to the getInstance factory method of that engine class, which encapsulates the selected provider's SPI implementation in it and returns it to the caller. Each API method of the generated engine class instance invokes the corresponding SPI method of the encapsulated SPI object.
The name of each SPI class is the same as that of the corresponding engine class, followed by "Spi". For example, the SPI class corresponding to the Signature engine class is the SignatureSpi class.

Message Digest Algorithm (or One-Way Hash Function)

A message digest is a function that takes arbitrary-sized input data (referred to as a message) and generates a fixed-size output, called a digest (or hash). A digest has the following properties:

It should be computationally infeasible to find another input string that will generate the same digest.

The digest does not reveal anything about the input that was used to generate it.

Message digest algorithms are used to produce unique and reliable identifiers of data. The digests are sometimes called the "digital fingerprints" of data.
Some digital signature algorithms use a message digest algorithm to compute the hash of the data that is being signed, and then digitally sign the hash value rather than the original data, since digitally signing the original data could be very expensive.

Opaque Key Representation

An opaque key representation is one in which you have no direct access to the key material that constitues a key. In other words: "opaque" gives you limited access to the key - just the three methods defined by the "Key" interface: getAlgorithm, getFormat, and getEncoded.
This is in contrast to a transparent representation, in which you can access each key material value individually, through one of the "get" methods defined in the corresponding specification class.

Opaque Parameter Representation

An opaque parameter representation is one in which you have no direct access to the parameter fields; you can only get the name of the algorithm associated with the parameter set and some kind of encoding for the parameter set. This is in contrast to a transparent representation of parameters, in which you can access each value individually, through one of the "get" methods defined in the corresponding specification class.

Permission

A permission represents access to a system resource. In order for a resource access to be allowed for an applet (or an application running with a security manager), the corresponding permission must be explicitly granted the code attempting the access.
The policy in effect for a Java application environment specifies which permissions are available for code from various sources (see Policy).
A permission typically has a name (often referred to as a "target name") and, in some cases, a comma-separated list of one or more actions.
The JDK has a number of built-in permission types (classes), and new types may be added by clients.

Policy

The policy in effect for a Java application environment specifies which permissions are available for code from various sources.
The source location for the policy information is up to the Policy implementation. The JDK contains a default Policy implementation that obtains its information from static policy configuration files.

Policy File

The policy for a Java application environment (specifying which permissions are available for code from various sources) is represented by a Policy object.
The source location for the policy information utilized by the Policy object is up to the Policy implementation. JDK 1.2 has a default Policy implementation that obtains its information from static "policy configuration files", also known simply as "policy files".

Private Key

A private key is a number that is supposed to be known only to a particular entity. That is, private keys are always meant to be kept secret. They can be used to generate digital signatures. A private key is always associated with a single public key.

Privileged

Whenever a resource access is attempted, all code traversed by the execution thread up to that point must have permission for that resource access, unless some code on the thread has been marked as "privileged". That is, suppose access control checking occurs in a thread of execution that has a chain of multiple callers. When the AccessController checkPermission method is invoked by the most recent caller, the basic algorithm for deciding whether to allow or deny the requested access is as follows:
If the domain for any caller in the call chain does not have the requested permission, AccessControlException is thrown, unless the following is true: a caller whose domain is granted the said permission has been marked as "privileged" (see below) and all parties subsequently called by this caller (directly or indirectly) all have the said permission.
(Note: System code automatically has all permissions.)
Marking code as "privileged" enables a piece of trusted code to temporarily enable access to more resources than are available directly to the code that called it. This is necessary in some situations. For example, an application may not be allowed direct access to files that contain fonts, but the system utility to display a document must obtain those fonts, on behalf of the user. In order to do this, the system utility becomes privileged while obtaining the fonts.

Protection Domain

See Domain.

Provider

Implementations for various cryptography algorithms are provided by Cryptographic Service Providers. Providers are essentially packages that implement one or more engine classes for specific algorithms. For example, the Java Development Kit's default provider, named "SUN", supplies implementations of the DSA signature algorithm and of the MD5 and SHA-1 message digest algorithms. Other providers may define their own implementations of these algorithms or of other algorithms, such as an implementation of an RSA-based signature algorithm or the MD2 message digest algorithm.

Public Key

A public key is a number associated with a particular entity (for example, an individual or an organization). A public key is intended to be known to everyone who needs to have trusted interactions with that entity. A public key is always associated with a single private key, and can be used to verify digital signatures generated using that private key.

Security Manager

Currently, all JDK system code invokes security manager methods to check the policy currently in effect and perform access control checks. There is typically a security manager (SecurityManager implementation) installed whenever an applet is running; the appletviewer and most browsers, including those from Netscape and Microsoft, install a security manager. The security manager prevents applet code from accessing resources unless it is explicitly granted permission to do so by an entry in a policy file.
A security manager is not automatically installed when an application is running, and thus the application has full access to resources (as was always the case in JDK 1.1). To apply the same security policy to an application found on the local file system as to downloaded applets, either the user running the application must invoke the Java Virtual Machine with the new "-Djava.security.manager" command-line argument or the application itself must call the setSecurityManager method in the java.lang.System class to install a security manager.

Self-Signed Certificate

A self-signed certificate is one for which the issuer (signer) is the same as the subject (the entity whose public key is being authenticated by the certificate).

Signature

See Digital Signature.

Signed Code

An abbreviated way of saying "code in a class file that appears in a JAR file that was signed". See Digital Signature.

Transparent Key Representation

A transparent representation of keys means that you can access each key material value individually, through one of the "get" methods defined in the corresponding specification class. For example, DSAPrivateKeySpec defines getX, getP, getQ, and getG methods, to access the private key x, and the DSA algorithm parameters used to calculate the key: the prime p, the sub-prime q, and the base g.
This is in contrast to an opaque representation, as defined by the Key interface, in which you have no direct access to the key material fields.

Transparent Parameter Representation

A transparent representation of a set of parameters means that you can access each parameter value in the set individually, through one of the "get" methods defined in the corresponding specification class. For example, DSAParameterSpec defines getP, getQ, and getG methods, to access the DSA community parameters p, q, and g, respectively.
This is contrasted with an opaque representation, as supplied by the AlgorithmParameters class, in which you have no direct access to the parameter fields; you can only get the name of the algorithm associated with the parameter set (via getAlgorithm) and some kind of encoding for the parameter set (via getEncoded).

Start of Tutorial > Start of Trail > Start of Lesson

Search
Feedback Form