|
|
|
|
|
|
Administering Public Key Security
The most effective way to make a distributed ATMI application secure is to combine link-level encryption with public key encryption. Public key encryption is the framework on which public key security is built.
Public key security allows you to incorporate message-based digital signatures and message-based encryption into your ATMI applications. Together, these capabilities provide data integrity and privacy, which are especially important when an ATMI application interacts with other ATMI applications or Workstation clients from outside the company.
Recommended Practices for Public Key Security
Assigning Public-Private Key Pairs
Application administrators and developers need to choose a Certification Authority to provide public-private key pairs and the digital certificates associated with them. Then they must decide how to assign the key pairs to the ATMI application. There are many options for assigning key pairs. An administrator can assign one or more of the following:
Application administrators and developers are responsible for choosing a method of assigning key pairs and assigning them. Once key pairs are assigned, however, no more administrative work is required; the plug-ins for public key security distribute and manage the keys.
Setting Digital Signature Policy
As the administrator, you use the following configuration parameters to set the digital signature policy for your ATMI application.
Setting a Postdated Limit for Signature Timestamps
SIGNATURE_AHEAD is specified at the domain-wide level of the configuration hierarchy, meaning that the value you assign to it applies to all processes running in the ATMI application. Domain-wide parameters are set in the RESOURCES section in the UBBCONFIG file, and the T_DOMAIN class in the TM_MIB.
The SIGNATURE_AHEAD parameter establishes the maximum permissible time difference between (1) the timestamp attached to the incoming message buffer and (2) the current time shown on the verifying system's local clock. The minimum value is 1 second; the maximum, 2147483647 seconds. The default is 3600 seconds (one hour).
If the attached timestamp shows a time too far into the future, the signature is considered invalid. This parameter is useful for rejecting signatures that are postdated, while allowing a certain amount of leeway for unsynchronized local clocks.
Example UBBCONFIG Entries for Postdated Limit
*RESOURCES
SIGNATURE_AHEAD 2400
Setting a Predated Limit for Signature Timestamps
SIGNATURE_BEHIND is specified at the domain-wide level of the configuration hierarchy, meaning that the value you assign to it applies to all processes running in the ATMI application. Domain-wide parameters are set in the RESOURCES section in the UBBCONFIG file, and the T_DOMAIN class in the TM_MIB.
The SIGNATURE_BEHIND parameter establishes the maximum permissible time difference between (1) the current time shown on the verifying system's local clock and (2) the timestamp attached to the incoming message buffer. The minimum value is 1 second; the maximum, 2147483647 seconds. The default is 604800 seconds (one week).
If the attached timestamp shows a time too far into the past, the signature is considered invalid. This parameter is useful for resisting replay attacks, in which a valid signed buffer is injected into the system a second time. However, in a system with asynchronous communication—for example, in a system in which disk-based queues are used—buffers signed a long time ago may still be considered valid. So, in a system with asynchronous communication, you may want to increase the SIGNATURE_BEHIND setting.
Example UBBCONFIG Entries for Predated Limit
*RESOURCES
SIGNATURE_BEHIND 300000
Enforcing the Signature Policy for Incoming Messages
SIGNATURE_REQUIRED may be specified any of the following four levels in the configuration hierarchy:
Setting SIGNATURE_REQUIRED to Y (yes) at a particular level means that signatures are required for all processes running at that level or below. For example, setting SIGNATURE_REQUIRED to Y for a machine named mach1 means that all processes running on mach1 will accept only incoming messages that are digitally signed.
You may specify both SIGNATURE_REQUIRED=Y and ENCRYPTION_REQUIRED=Y together at the domain-wide level, machine level, group level, or service level. See Enforcing the Encryption Policy for Incoming Messages for a description of ENCRYPTION_REQUIRED.
Qualifier
The enforcement policy for SIGNATURE_REQUIRED applies only to application services, application events, and application enqueue requests. It does not apply to system-generated service invocations and system event postings.
Example
To configure SIGNATURE_REQUIRED for a machine named mach1, follow these steps.
*MACHINES
mach1 LMID="machine_logical_name"
TUXCONFIG="absolute_path_name_to_tuxconfig_file"
TUXDIR="absolute_path_name_to_BEA_Tuxedo_directory"
APPDIR="absolute_path_name_to_application_directory"
SIGNATURE_REQUIRED=Y
In the preceding example, when tmboot(1) starts the ATMI application, it passes the SIGNATURE_REQUIRED=Y parameter to the machine named mach1. At that point, all application services advertised by mach1, including those advertised by gateway processes, are allowed to accept only messages that include valid digital signatures. If a process controlled by mach1 receives a message that does not include a valid digital signature, the system takes the following actions:
Note: A NULL (empty) buffer cannot be digitally signed, meaning that the system rejects any NULL buffer received by a process requiring digital signatures, in the manner stated in the preceding bullet list.
How the EventBroker Signature Policy Is Enforced
When digital signatures are attached to a posted message buffer, these signatures are preserved and forwarded along with the message buffer to subscribers for the relevant event.
If the TMUSREVT(5) system server is running in a domain, machine, or server group that requires digital signatures, it rejects any incoming posting without a TPSIGN_OK composite signature status—see Understanding the Composite Signature Status.
Possible subscription notification actions that the TMUSREVT server might take include invoking a service or enqueuing a message. If the target service or queue requires a valid digital signature, but one is not attached to the posted message, the subscription notification action fails.
System events (events that are posted by the system itself and processed by the TMSYSEVT server) may be digitally signed. The administrative policies regarding digital signature do not apply to the TMSYSEVT(5) server.
How the /Q Signature Policy Is Enforced
When digital signatures are attached to a queued buffer, the signatures are preserved in the queue and forwarded to the dequeuing process. Also, if a message is processed by TMQFORWARD(5) to invoke a service, signatures are preserved.
If the TMQUEUE(5) system server is running in a domain, machine, or server group that requires digital signatures, it rejects any incoming enqueue request without a TPSIGN_OK composite signature status—see Understanding the Composite Signature Status. In addition, the TMQUEUE server requires a digital signature if such a policy is in effect for the service name associated with the queue space.
How the Remote Client Signature Policy Is Enforced
If the workstation handler (WSH) is running in a domain, machine, or server group that requires digital signatures, it rejects any incoming message buffer containing application data without a TPSIGN_OK composite signature status—see Understanding the Composite Signature Status.
Setting Encryption Policy
As the administrator, you use the following configuration parameter to set the encryption policy for your ATMI application.
Enforcing the Encryption Policy for Incoming Messages
ENCRYPTION_REQUIRED may be specified at any of the following four levels in the configuration hierarchy:
Setting ENCRYPTION_REQUIRED to Y (yes) at a particular level means that encryption is required for all processes running at that level or below. For example, setting ENCRYPTION_REQUIRED to Y for a machine named mach1 means that all processes running on mach1 will accept only incoming messages that are encrypted.
You may specify both ENCRYPTION_REQUIRED=Y and SIGNATURE_REQUIRED=Y together at the domain-wide level, machine level, group level, or service level. See Enforcing the Signature Policy for Incoming Messages for a description of SIGNATURE_REQUIRED.
Qualifier
The enforcement policy for ENCRYPTION_REQUIRED applies only to application services, application events, and application enqueue requests. It does not apply to system-generated service invocations and system event postings.
Example
To configure ENCRYPTION_REQUIRED for a server group named STDGRP, follow these steps.
*GROUPS
STDGRP LMID="machine_logical_name"
GRPNO="server_group_number"
ENCRYPTION_REQUIRED=Y
In the preceding example, when tmboot(1) starts the ATMI application, it passes the ENCRYPTION_REQUIRED=Y parameter to the server group named STDGRP. At that point, all application services advertised by STDGRP, including those advertised by gateway processes, are allowed to accept only messages protected by an encryption envelope. If a process controlled by STDGRP receives an unencrypted message, the system takes the following actions:
Note: A NULL (empty) buffer cannot be encrypted, meaning that the system rejects any NULL buffer received by a process requiring encryption, in the manner stated in the preceding bullet list.
How the EventBroker Encryption Policy Is Enforced
When a posted message buffer is encrypted, encryption envelopes are preserved and forwarded, along with the encrypted message content, to subscribers for the relevant event.
If the TMUSREVT(5) system server is running in a domain, machine, or server group that requires encryption, it rejects any incoming posting message that is not encrypted.
Possible subscription notification actions that the TMUSREVT server might take include invoking a service or enqueuing a message. If the target service or queue requires encrypted input, but the posted message is not encrypted, the subscription notification action fails. Also, if the subscriber does not possess an appropriate decryption key, the event notification action fails.
System events (events that are posted by the system itself and processed by the TMSYSEVT server) may be encrypted. The administrative policies regarding encryption do not apply to the TMSYSEVT(5) server.
How the /Q Encryption Policy Is Enforced
When a queued message buffer is encrypted, this status is preserved in the queue, and the buffer is forwarded, in encrypted form, to the dequeuing process. Also, if a message is processed by TMQFORWARD(5) to invoke a service, encryption status is preserved.
If the TMQUEUE(5) system server is running in a domain, machine, or server group that requires encryption, it rejects any incoming enqueue request that is not encrypted. In addition, the TMQUEUE server requires encryption if such a policy is in effect for the service name associated with the queue space.
How the Remote Client Encryption Policy Is Enforced
If the workstation handler (WSH) is running in a domain, machine, or server group that requires encryption, it rejects any incoming message buffer containing an unencrypted application data buffer.
Initializing Decryption Keys Through the Plug-ins
As the administrator, you use the following configuration parameters to specify principal names and decryption keys for the system processes running in your ATMI application.
This trio of configuration parameters can be specified at any of the following four levels in the configuration hierarchy:
A principal name and decryption key at a particular configuration level can be overridden at a lower level. For example, suppose you configure a principal name and decryption key for machine mach1, and a principal name and decryption key for a server called serv1 running on mach1. The processes on mach1 behave as follows:
Configured decryption keys are automatically opened when an ATMI application is booted. The following figure demonstrates how the process works.
How a Decryption Key Is Initialized Example
Each time you invoke tmloadcf to load the configuration, you are prompted to enter the password for each of the decryption keys configured with SEC_PRINCIPAL_PASSVAR. If you want to avoid having to enter each password manually, you can write a script that automatically enters the passwords. The script must include a definition of each password variable, and it must end with the following line:
tmloadcf -y ubbconfig_name < /dev/null
No application process has permission to close a decryption key opened during ATMI application booting. The decryption keys stay open until you run the tmshutdown(1) command to shut down the ATMI application.
Example UBBCONFIG Entries for Principal Names and Decryption Keys
*RESOURCES
SEC_PRINCIPAL_NAME "Tommy"
SEC_PRINCIPAL_LOCATION "/home/jhn/secsapp/cert/tommy.pvk"
SEC_PRINCIPAL_PASSVAR "TOMMY_VAR"
.
.
.
*SERVERS
"TMQUEUE" SRVGRP="QUEGROUP" SRVID=1
CLOPT="-s secsdb:TMQUEUE"
SEC_PRINCIPAL_NAME= "TOUPPER"
SEC_PRINCIPAL_LOCATION="/home/jhn/secsapp/cert/TOUPPER.pvk"
SEC_PRINCIPAL_PASSVAR= "TOUPPER_VAR"
Failure Reporting and Auditing
This topic explains how the system manages errors found through digital signatures and message encryption.
Digital Signature Error Handling
If message tampering is detected (that is, if the composite signature status is either TPSIGN_TAMPERED_MESSAGE or TPSIGN_TAMPERED_CERT—see Understanding the Composite Signature Status), the system takes the following actions:
If any individual signature associated with an expired certificate, revoked certificate, expired signature, or postdated signature is detected, the system takes the following actions:
If a process that requires a valid digital signature (based on the SIGNATURE_REQUIRED=Y setting) receives a message with the composite signature status TPSIGN_UNKNOWN, the system takes the following actions:
Encryption Error Handling
If a process receives an encrypted message but does not possess an open decryption key matching one of the message's encryption envelopes, the system takes the following actions:
If a process that requires encrypted input (based on the ENCRYPTION_REQUIRED=Y setting) receives an unencrypted message, the system takes the following actions:
See Also
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|
