Categorizing Security Components in Java
Categorizing Security Components in JavaMany Java components make up Java security. The components can be broken down into element use and security operation . The security operation is used to check the security elements and validate them to ensure that they match trusted security elements. An example of a trusted security element is a secure hash that is trusted to validate the message. The only security element that doesn't perform is the confidentiality operation. The key is not checked, but if it decrypts the message, then the key is considered valid from the user who encrypted the message. Each of the security elements that have been discussed so far are created, managed, and stored. The Java security components can be broken down into those components that support the creation, management, and storage of the security elements and the security operations that are performed on those elements. For instance, the Java KeyStore is a very important security component for supporting the storage and management of keys. Beyond key storage and management, the KeyStore is not used in any particular security operation. The KeyStore does provide authentication and authorization, but only for storing keys. The KeyStore uses multiple security operations to keep the keys secure. Since key storage and key management is needed to have a trusted set of keys to perform any confidentiality, the KeyStore makes up the necessary supporting utilities and APIs in order to ensure keys can be used for confidentiality. The use of the security elements for creation, management, and storage are supporting protocols, APIs, utilities, and mechanisms that are crucial for supporting the security operations. Some of the most important mechanisms that are part of the Java API are Java Authentication and Authorization Service (JAAS), Java Secure Socket Extensions (JSSE), and Java Generic Security Service Application Program Interface (GSS-API). The JAAS handles authentication and authorization for securing system resources. The JAAS uses login modules that are defined in the configuration file and uses the Java 2 security manager to access privileged actions.
The JSSE provides a Java API for Secure Socket Libraries (SSL) and Transport Layer Security (TLS). The JSSE uses X.509 certificates for its key material. The X.509 certificate is a secure data structure format for managing public keys. JSSE provides key exchange, authentication, confidentiality, and message integrity.
The Java GSS-API provides authentication, confidentiality, and message integrity using different authentication mechanisms. By default the GSS-API uses Kerberos tickets as its key material and the Kerberos Server for authentication.
Components that provide authenticationWhen logging on to a system, the principal in the form of a username and the credential in form of a password can be entered. To authenticate the username and password, the authentication mechanism must check the username and password with the ones retrieved by the authentication mechanism. The check compares the usernames and passwords and marks them as valid or invalid. JAAS, JSSE, and the Java GSS-API all provide some form of authentication. The JAAS supports the ability to change the authentication mechanisms in a configuration file. Java GSS-API supports the ability to change the authentication mechanism by passing in a different Object Identifier (OID) in the initialization of the security context. Implementing principal and credential elements with Java componentsThe security elements for authentication are principals and credentials. A principal could be the name of a user or other system that is named. The authentication operation uses a user principal, meaning that it cannot accept the group principal or any other principal that does not have a credential associated with it. Many types of principals are given in the Java API. The name of a principal is derived from the java.security.Principal interface. The Principal interface has many implementations that are distributed in the JDK 1.4. The different implementations are defined according the different protocols and operating systems that are being supported. The different principals that are defined for Microsoft WinNT operating system and subsequent uses in the Microsoft operating systems are as follows :
The SID for Microsoft WinNT is the security identifier that uniquely identifies the group, user, or domain. From the Microsoft WinNT principal set, the Microsoft WinNT system can uniquely identify a domain, group, or user that contains properties specific for the Microsoft WinNT system. Like the Microsoft WinNT distinction of principals, UNIX also uniquely identifies the principals modeled after the UNIX operating system format. The different UNIX operating system principals are:
The Numeric number is the UNIX group identification number (GID) for the group principal or the user's UNIX identification number (UID) for the user principal. The UNIX principals can uniquely identify a user or group by using the UNIX operating system's GID or UID. The UNIX principals allow the named principal to be used in a format for UNIX. Other principal formats are specific to the protocol being used for JSSE and Java GSS-API. JSSE uses the X.509 certificate format. The X.509 certificate format uses the X.500 protocol for the naming conventions. The JSSE can use the javax.security.auth.x500.X500Principal class for its API. The Java GSS-API uses Kerberos by default, so the Kerberos principal must be defined in Java. The Kerberos principal is defined as the javax.security.auth.kerberos.KerberosPrincipal class. These principals make up all the different types of principals that are shipped with the JDK 1.4, however not all these principals are user principals. While all these principals can be used for authorization, not all of them can be used for authentication. Authentication requires credentials. User principals, such as NTUserPrincipal , can use credentials.
Credentials are the security element that identifies a principal. Most credentials take the form of a password. The password could be the same password that unlocks the keystore for that particular user to retrieve an X.509 certificate. There are normally many layers of authentication and authorization throughout an organization's system. Each layer throughout the system could provide a different path based on the authentication and different accesses of the resources based on the principal that was validated . It is important to map the authentication and resource paths that can be taken by different users, systems, and groups. An architect must ensure that a path or resource cannot be accessed unless it is defined by a set of requirements to be used.
Validating principal and credential elements with Java componentsAll the authentication components support the notion of a credential. In JAAS, users are normally prompted for a series of passwords and their usernames. The series of passwords are given in a byte array and are dependent on the login module. The login module is the authentication mechanism that is defined for the JAAS client. The JAAS component can have multiple login modules. The login modules are defined in a configuration file for which ones are required and initialized . The username is normally given in the form of a string. After successful authentication, the JAAS creates a subject, which will contain principal entries and credential entries for further authentications and authorizations. Most of the authentication work is hidden in the login modules that provide the authentication mechanisms. The subject may provide a completely different set of principals and credentials for further use throughout the system. If an NT login module is defined, there will be lookups in the Microsoft WinNT domain to also authenticate the user. In the KeyStore login module, there may be two sets of passwords, one for the administration rights to the keystore and one for the alias. The alias is the mapping of a logical name, usually the username, to an X.509 certificate. There are many login modules that can be changed to support different authentication mechanisms. The user can be prompted for the passwords and username so that the login modules can be changed without changing any code. The login module checks the username and password with the stored username and password that the login module manages. The only management of the user principal and password that is needed is if there is any automation to logging in from the JAAS client. Other than that, the login module manages the username and password for validation. For example, to validate the username and password for the NTLoginModule , the username and password must be defined and managed in the Microsoft Windows WinNT domain. See Figure 3-7 for the JAAS interface.  Figure 3-7: The JAAS interface The credential for the JSSE API is normally the X.509 certificate. The X.509 certificate is normally stored in the KeyStore . The application surrounding the JSSE protocol normally has to retrieve the certificate from the KeyStore . In order to retrieve the certificate, the applications must use the alias, which consists of a name-associated certificate and the password to retrieve the certificate. The issuer's information and keys are defined in the X.509 certificate, and the origin of the certificate can be traced through a certificate path. The information in the X.509 is used for authentication. The JSSE protocol can also be set to use a username and password. The JSSE will use Java sockets as the transfer mechanism to exchange keys and perform authentication from the server to the client. When authentication is from the client to the server, it is called one-way authentication . The JSSE authentication may also require mutual authentication , where the authentication is also from the client to the server. The Java GSS-API uses the org.ietf.jgss.GSSName and org.ietf.jgss.GSSCredential to define the principal name and credentials to be authenticated. A Kerberos server must be set up on the organization's domain to do the authentication. The Java GSS-API transport mechanisms are Java streams or byte arrays. Since Java streams are used, the streams can be written to Java sockets for network interaction. The implementation to Java sockets is not part of the GSS-API mechanism.
Components that provide authorizationThe only authorization that JSSE and Java GSS-API provides is the capability to keep anyone from reading the plaintext messages except for those individuals who possess the public or secret key. The confidentiality of JSSE and the GSS-API prevents other users from reading the original messages. JAAS and Java applications can enforce the access to system resources with the SecurityManager .
Implementing principal and permission elements with Java componentsThe principal was discussed in the authentication section. The permission set is a number of permissions that are defined with a system resource. For example, the FilePermission may be defined in a policy file with read permissions on a temp.txt file. The FilePermission will always have a principal associated with it to define which principals can have the permission to the system resource. If one is not defined with the permission set in the policy file, it simply means that all principals have the permissions. The resource permissions are implementations of the java.security.Permission interface . The permissions are collected in a collection data type in the java.security.PermissionCollection class. Validating principal and permission elements with Java componentsThe SecurityManager uses the policy file that is defined in its system properties. The SecurityManager will look up the principal that is currently defined in its thread context in the policy file and get the permission set. When an operation is performed on a system resource, the operation will check with the SecurityManager to see if the operation is allowed on the resource. In the FilePermission example, if a SecurityManager is defined and the application is reading the temp.txt file, the read operation will check with the SecurityManager to see if it is allowed. If no SecurityManager is defined, then all system resources can be accessed. The principals and permissions are managed in the form of policy files or ACLs used by databases or LDAP servers. The policy file that contains the principal and permission set must be trusted and secure to prevent attackers from modifying the policy file to give everyone access to the system resources. ACLs are normally stored in the database or LDAP to protect the access to the principals and permissions. The JAAS component uses the SecurityManager in the manner just described, except the principals it will use are the principals returned in the subject. When a JAAS application successfully completes authentication, the login module returns a subject with the principals and credentials that are used for further authentication and authorization. See Figure 3-8 for the SecurityManager .  Figure 3-8: Security Manager Components that provide confidentialityConfidentiality is the act of encrypting data or a message with a key (which keeps attackers from understanding the message) and providing selected users with a key to unlock to understand the message. When selected users unlock the message to understand it, it is called decrypting the message . The JSSE and GSS-API components provide encryption. There are also Java APIs to encrypt a messages and data directly. In order to use a key, a key must be created, managed, and stored. The key to unlock the message must be given only to the selected users to decrypt the message. If others access the key, then they also can read the message. Implementing key elements with Java componentsThe first step in using a key is to create it. A key can be created using the keytool utility that is shipped with the JDK, which will store the key in a keystore (database). Other Java APIs that support generating keys are the java.security.KeyPairGenerator for generating a key pair and the javax.crypto.KeyGenerator for generating a secret key.
After the key is created, it needs to be stored for later use. Keys can be stored in several ways. Some organizations may manage keys in their databases or LDAP server. One way to organize X.509 keys is to use the keystore. The keystore is a repository for X.509 certificates that is supported by the utility keytool , which is distributed with JDK. Java APIs also supports the keystore. The javax.net.ssl.KeyManager and javax.net.ssl.TrustManager are used to retrieve X.509 certificates from the keystore for use by JSSE. The TrustManager will retrieve X.509 certificates that are mark trusted from the keystore. When a certificate is mark trusted, it means that the organization knows to trust the certificate issuer.
Using key elements with Java componentsThe purpose of the key elements is to encrypt and decrypt data or messages. When a message is encrypted, it is called ciphertext . When a message is decrypted, it is called plaintext . The cipher algorithms to encrypt and decrypt are created with the javax.crypto.Cipher class. Other Java components that are used to encrypt and decrypt messages, byte arrays, and streams are JSSE and the Java GSS-API. The JSSE will encrypt and decrypt messages going across Java sockets. Java GSS-API will encrypt and decrypt messages across Java streams and byte arrays. When using a key pair combination, a private key is used to encrypt the message and only the associated public key can decrypt the message. Because only that particular public key can decrypt the message, some may say that establishes a form of authentication; however, this is not so. The authentication of the person refers to verification that he is who he says he is. The credential, in this case, is the public key.
When decrypting the message, the public key is being used. This does not imply that the user principal has been authenticated. Also, the public key may be distributed to many users instead of a specific user, so the validation of the user's identity really identifies the user as being a member of the group that receives the public key. Even though the keytool is the utility for storing the key pairs, it is called a keystore because the resulting file is used to store keys. The keystore is used only in the key pair storage. Since the Java API does provide interfaces in the form of the KeyStore class, a Java application can be written to store secret keys. The keytool utility was never designed to store secret keys. Other key distribution mechanisms will have to be used in order to distribute and manage secret keys. In olden days, it was easy, but time consuming, to pass secret keys through the sneaker net. Sneaker net refers to when a developer has a floppy and walks to all the computers and installs the files. In this case, the file contained the secret keys to use. Secret keys and the keystore files can still be passed in this manner to keep hackers from reading the transfer of the key files. Since secret keys do not normally use the keystore, secret keys require a different kind of access security than the key pair. Since the secret key cannot be managed in a keystore, other key agreement algorithms need to be supported. Java supports several key agreement algorithms to distribute a secret key through the javax.crypto.KeyAgreement class. Key agreementKey agreement is the ability for different parties to agree upon a key to use without transmitting the key over a network for fear of eavesdroppers getting a copy of the key. Most of the time, the parties simply calculate the same key. The keys are changed at periodic intervals to keep eavesdroppers guessing. Sometimes the periodic interval is every session of communication of messages. When the key changes every session, it is termed a session key . The most famous of the key agreement protocols is the Diffie-Hellman (DH) algorithm.
The public key from the key pair is distributed in the form of an X.509 certificate. There are many associated protocols and third-party organizations that are used for the distribution of the X.509 certificate to update, distribute, revoke, and manage certificates. Public Key Infrastructure (PKI) is a means to provide the management and distribution of public keys.
The JSSE and Java GSS-API can be set to automatically encrypt and decrypt messages during transportation and message passing. Components that provide integrityIt has been mentioned that message and data integrity is accomplished through a hash or message digest. The term message digest is sometimes used because it is a digest, or unique block, representing the original message. When the message is ever so slightly different, so is the message digest. The JSSE and GSS-API support message integrity. Other Java APIs also directly support message integrity, however some work must be done to define what to do if the message does not check to be valid.
The three forms of the message digestThere are three forms of the message digest, or one-way hash: message digest , message authentication code (MAC), and the digital signature . The differences between the message digests are their levels of security.
The java.security.MessageDigest class in the JDK 1.4 supports the generic message digest. The MessageDigest creates a digest using a specific algorithm to create the hash. The algorithm to create the hash could be a MD5 or SHA-1. These algorithms are described in detail in a later chapter. The algorithms are actually implemented at the SPI layer of the Java API, like most other security algorithms, so that they may be updated or so that algorithms may be added without changing the Java API. The algorithms create a unique hash when a different message or data is passed in.
Hash vs. message digestSometimes I may use the term hash instead of message digest because the hash can be produced from a file, data from a database, and from more types of data than a message. The MessageDigest supports data in the form of a byte array. The result of the hash is also a byte array. The MessageDigest class does not define the storage and management of the hashed byte array. Again, the storage and management in most organizations are in the forms of databases, LDAP, and files. The LDAP server formats its database structure in the form of the X.500 protocol. The X.500 protocol defines groups and users and their information in the form of a tree structure. The tree structure of X.500 is how the X.509 certificates are named and stored. If the organization is using a database or file structure, the interface for X.500 support will have to be written and supported from the organization to extend any matching use of X.509. The file structure will need further security for authentication and authorization to protect the files from attackers. The database will have to be structured to support tree queries and X.500 support. LDAP provides a lot of functionality out of the box for security support by using the X.500 protocol.
The first hash that the MessageDigest class will produce needs to be saved to a trusted store as the trusted hash. When the message is in question, the message is passed through a MessageDigest class again to produce a new hash. The trusted hash byte array and the new hash array are compared byte by byte. If the bytes are equal, then the message has not changed. A message authentication code (MAC) is basically a keyed message digest. Like a message digest, a MAC takes an arbitrary amount of input data and creates a short digest value. Unlike a message digest, a MAC uses a secret key to encrypt the digest. Only those individuals who possess the secret key can check the message digest. The purpose of encrypting the message digest is to keep attackers from seeing the true message digest. If it happens that two unlike messages can produce the same message digest, an attacker can change the message data. The message digest will say that message is the same as long as the resulting digests are equal. The MAC is also used to encrypt the digest so that it may be stored in a secure form. The purpose of the MAC is simply to encrypt and decrypt the digest to secure it. The MAC is useful for protecting the integrity of data that is sent over an insecure network. The JDK 1.4 supports the MAC with the javax.crypto.Mac class. To guarantee that the message can only come from a specific user, the user signs the message by using a private key. There is a one-to-one correspondence between the user and message because the private key can only originate from that specific user. This concept is referred to as a digital signature . The digital signature offers a higher level of security. When using a key pair, there is a private and public key that is created by a user. The user only distributes the public keys for selected users to decrypt the messages that they encrypt. The private key is used for encryption and cannot be duplicated . If the public key from that user decrypts the message, it can only have been encrypted with that specific private key. If only one user owns the private key, the people who decrypt the message know that the message derived from that particular user. The message could have been modified in transportation; but with the use of a message digest, it can be determined if the message has been altered . In addition, the private key encrypts the message digest and only the originator of the message has the private key. Therefore, the message is valid.
Legal ramificationsIn fact, some organizations will use the digital signature as a means to prove that a particular individual signs information. The digital signature has even been recognized by some law organizations as a means to verify that a specific individual, through a digital medium, has said something specific. If a contract has been negotiated through the Internet, the digital signature is a form of proof that it came from a specific individual because of his encrypting the digest that validates the message and his encryption with the private key. The digital signature is supported in Java from the java.security.Signature class.
Figure 3-9 demonstrates the different security levels of the hashed digest. The message digest is not encrypted, the MAC is secured through a secret key, and the digital signature is secured through a key pair.  Figure 3-9: The message digest security level
 Java Security Solutions ISBN: 0764549286
EAN: 2147483647 Year: 2001
Pages: 222 Authors: Rich Helton, Johennie Helton
flylib.com © 2008-2017. If you may any questions please contact us: flylib@qtcs.net |
