Categorizing Security Elements

  

Each security operation requires security elements. The security elements change depending on the security operation and algorithms that the security operation uses. Each security operation has a Java API and underlying security mechanism that implements the operation. The security elements define the security operation; for example, if the security operation uses keys, the security operation is confidentiality.

The principal, credential, key, and hash are all security elements that require management and storage. The management and storage are required for archival and retrieval of security elements. The security elements that are stored are considered trusted and will be used by the security operation. Most security operations will simply check incoming security elements with the trusted security element to ensure that they are valid. When a security element is created and used for a security operation, there must be a mechanism to support the security element creation, management, and storage.

Tip  

The trusted security elements must be stored in a secure store to avoid tampering.

Defining authentication with principal and credential elements

At least one security element is needed for each security operation. Authentication requires a user principal with its associated credential information. Authorization is similar in that it requires at least one principal. The principal for authorization could be a principal or a principal that represents all principals.

Note  

The difference between the authentication and authorization information is that the authentication validates the principal with a credential, and authorization checks the access permissions of the principal on a system resource.

Many principals, like groups and domains, may not have credentials associated with them. These principals cannot be authenticated without at least one credential. The user always has a credential and thus the term user principal . A system could also be a user principal as long as it has at least one credential associated with it. Once a principal is authenticated, most protocols will create a subject. The subject is the new set of principals and credentials retrieved by the authentication mechanism for further authentication and authorization throughout the organization's system. Further authentications and authorizations may be required to enter other organizations and their systems. A user logging in to a Web site could place an order that could interact with several other companies to see the order through. Figure 3-2 shows the user principal and credential association.


Figure 3-2: Authentication principal and credential mapping

For example, I could log in to a Web site using a username and password. If the authentication is valid, the authentication process creates a subject that could contain a set of X.509 certificates for me to access the application server. The authentication mechanisms use both the username and password at the Web server, and use the X.509 certificate to authenticate at the application server. The principal in the X.509 could also be used for authorization to access the resources for the applications, such as the account information in the application server. The first authentication routine uses the username as my principal and the password as my credential. The authentication mechanism reads a store to retrieve my credential and then checks the trusted user principal and credential with the incoming principal and credential. If the principals and credentials pass the check, authentication passes ; otherwise , the authentication fails.

The authentication and authorization process could consist of multiple layers of authentication and authorization mechanisms. The system could require an X.509 to enter the Web site and then a username and password to enter a second tier of security. Alternatively, the authorization could require a Kerberos token to enter a store and place an order, and then an X.509 certificate to read the profile and order history. Each principal mechanism must have an associated credential to validate the identity of the principal. For example, when I log in to a system with a username, how does the system know that the username actually belongs to me? I have to enter a password, which is a form of credential, to validate that the password belongs to me. A principal to a credential is a one-to-many relationship. A user principal requires at least one credential, but it can require more than one. I can easily write a login routine that requires two passwords.

Defining authorization with principal and permission elements

Authorization requires elements and mechanisms just like authentication. The difference is that the elements for authorization are principals and permissions. The principals for authorization can be group , domain, user, and more. No credential is required for this principal. For authorization, it is assumed that the principal has already been authenticated. The authentication confirms that the users entering the system are who they say they are.

Note  

The authentication could be implicit, meaning that some users accessing a resource in a system could be considered valid because it is assumed that they have been authenticated by the operating system. However, assumptions are dangerous.

The authorization mechanism, in most cases, will have a policy file or Access Control List (ACL) associated with the running Java application. The Java application will access a system resource and use the principal to check the entries of the policy file and ACL. The principal either will or will not have an entry. Some policy files will have the implicit entry of an empty principal, which means all principals can use the entry. Once the entry is found, the Java application will check the permission type and permission operation of the system resource and see if the principal has the access.

For example, the user could be Rich , the permission type could be FilePermission , the resource could be secret.key , and the permission operation could be read . When Rich reads the secret.key file, the authorization mechanism will find the entry and check that Rich has permission to read that file. The Java security manager provides this support as an authorization mechanism if the Java application has the security manager defined for being used at startup. See Figure 3-3 for the principal and permission association. If the principal does not have the correct principal for the system resource, then access to the resource is denied .


Figure 3-3: Authorization principal

Defining confidentiality with key elements

Confidentiality is the ability to change, or encrypt, data or messages into ciphertext and give only a selected group of users the ability to read, or decrypt, the original data and messages. The selected group can decrypt the message because they have been given keys to read it. Since messages are now constantly sent across the Internet in the form of e-mail, network packets, and more, no one can control who accesses these messages. However, a person can encrypt the message so that the people who sniff the message cannot understand it unless they have a key to unlock the message's meaning.

The selected groups of users who get the keys need to receive the keys in a secure distribution to ensure that only those who should receive the keys receive them and not the attackers of the system. If the keys are simply passed to the users on the Internet, anyone who is watching the data on the networks can pick up the keys and use them to decrypt the secure messages. In this case, the messages are no longer secure to those who were watching the data on the networks. The key distribution may be viewed as a form of key agreement. This is because it involves a method of different parties agreeing on which keys to use.

A simple form of key agreement is when two parties e-mail each other and agree to use key number 104 out of the 500 keys they have in separate files on their box. Key agreement is part of key management. The key management mechanisms can also interact with a key storage device in which the keys are stored. If the keys are stored, they need to be secure so that attackers cannot access them and decrypt the messages. Some types of key stores have the key encrypted.

There are two types of key elements. One uses a secret key for both encryption and decryption, and the other uses a separate private key and public key for encryption and decryption, respectively. This is called a key pair. See Figure 3-4 for the secret key and Figure 3-5 for the key pair.


Figure 3-4: The secret key

Figure 3-5: The key pair

The key pair requires both the private and public key to encrypt and decrypt the message or data. Only the public key from the associated private key can decrypt the message. No other public key can decrypt the same message. The most common key storage form for the public key is the X.509 certificate. The X.509 certificate can be stored in an unsecured key store because the certificate itself contains a public key. Following the path of the certificate can only decrypt the public key.

Cross-Reference  

X.509 certificates are described in Chapter 24 in more detail.

For the secret key agreement, there are algorithms that agree on which key to use. For example, two people have the same 12 keys, designated by the month, and each user uses the key based on the current month. Attackers watching the users know that the users might agree to the key of the month. But if the user's keys are not transmitted, the attackers will not know the agreed 12 keys.

The problem with this scenario is how the two users get the 12 keys originally. They could mail each other floppies, but there is always the chance that somebody might pick up the floppy from a mailbox and substitute keys that are known to an attacker. Therefore, the users not only need to agree on which key to use but also how to securely transmit the keys in the first place.

Defining integrity with secure hash elements

Message integrity is checked to find out whether a message has been modified. When a message has been changed, it could have been changed to do harm. Software is pulled down from Web sites and online services all the time, and a message or program could be pulled down, have a virus added, and be put back on the Web site. Integrity is the ability to check that the data of the software has not been altered. A rudimentary way to check the data is to check the size of the file and the date that it was created. The problem with this method is that a file can have a virus introduced into it and be modified so that the size remains the same. The date of the machine can be altered for a few minutes so that when the file is uploaded it retains the original creation date, so the integrity check is easily broken in this scenario.

A more trusted method is to store an exact copy of the file in a trusted location and to periodically compare the entire stored file to the one that is used for downloading. The problem with this method, comparing entire questionable files and messages with an exact copy of trusted files and messages, is that a lot of storage is required. To avoid the storage problem, the file or message is hashed to a resultant block called a hash or digest . The hash is called a one-way hash because the original data cannot be reconstructed from the hash. Once the first hash is created, it is saved to a trusted store. When the message or file is questionable or needs a periodic check, it is hashed again into a new hash. The hash from the trusted store is retrieved and checked with the new hash. If the two hashes are identical, the original data has not been modified.

For a simple understanding of the hash and the hash function, I will start out with an XOR (exclusive-or) of a text message. The text message will be converted to ASCII. ASCII is a representation of text by digital numbers . As shown in Listing 3-1, the XOR function works by any two like digits resulting in a "0" and any two opposite digits resulting in positive "1."

Listing 3-1: Understanding an XOR
start example
 1 ^ 1 = 0 1 ^ 0 = 1 0 ^ 0 = 0 
end example
 

A very simple sample hash function is to take two text messages, convert them to ASCII, and XOR each ASCII digit. Listing 3-2 demonstrates two messages that are converted to ASCII. Then each ASCII digit is converted to binary. Finally each binary value is XOR'd with the next binary value.

Listing 3-2: Understanding a hash
start example
 "This is a hash  =" Changing the text in ASCII format will read the following: 84 104 105 115 32 105 115 32 97 32 104 97 115 104 32 61 The result is 114 --------------------------------------------------------------------- "This hash is different ="  Changing the text in ASCII format will read the following: 84 104 105 115 32 104 97 115 104 32 105 115 32 100 105 102 102 101 114  101 110 116 32 61 The result is 118 
end example
 

The two results of XOR'ing the text messages execute two different results. Since the results are different, the messages are not the same. This is just a simple example to demonstrate how a hash function may work. The difference between this hash function and a real-world example is that a real-world hash function is a lot more complex to ensure that results of different messages can never equal. If the hashes do not match, the messages are different. If the hashes match, then the messages are the same. In order to compare the hash messages, a previous hash of the message is executed and saved into a trusted environment. When the message needs to be checked to see if it has been altered, the trusted hash is retrieved from the trusted store. The one-way hash can only generate an exact hash digest as a result. The data cannot be re-created from the hash result. See Figure 3-6 for the one-to-one hash association.


Figure 3-6: The hash
Cross-Reference  

Chapter 9 describes hash functions in more detail.

  


Java Security Solutions
Java Security Solutions
ISBN: 0764549286
EAN: 2147483647
Year: 2001
Pages: 222

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net