Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 6 Secure Daemons (rvsd and rvsrd) : Security Factors

Security Factors
Store Files
The secure daemon store file contains very sensitive information. Store it on the local file system of the secure daemon’s host computer, with tight file access, in a physically secure environment. Ensure timely backup to secure media.
Core-Dump Files
Secure daemon process storage contains sensitive information in unencrypted form. Similarly, user program storage can contain passwords or private key data. It is essential to deny access to these processes and their core image files. We strongly recommend arranging operating system parameters to prevent creation of core files.
Daemon Certificates
Administrators must implement a secure mechanism to distribute the secure daemon’s public certificate to users (that is, either programmers of client programs or end users).
Ensure that users verify daemon certificates before using them with client programs. Ensure that users keep daemon certificates in files that are secure from unauthorized modification or tampering. Remember, a false certificate can give a rogue daemon access to user passwords.
CA-Signed Certificates
Rendezvous does not support separating a leaf certificate from its signing CA certificate. When arranging certificate data, you may supply either a self-signed certificate, or a complete certificate trust chain, including leaf, intermediate (which are optional), and root certificates—all in one certificate data file. In either case, the entire certificate chain is contained in one package, and Rendezvous components verify trust by comparing the entire package.
To better understand the way in which Rendezvous uses certificates and certificate trust chains, compare it to the familiar model of web browser security.
In the familiar model, web browsers generally store a set of certificates representing trusted certificate authorities (CAs), and use them to deduce the authenticity of many certificates—any certificate signed using one of those trusted CA certificates.
In contrast, to authenticate a user (or another daemon), Rendezvous secure daemons require that a client-supplied certificate must exactly match a trusted certificate previously stored with the daemon. Daemons use certificates to verify digital signatures and message integrity, but they do not use CA certificates to authenticate client certificates. Similarly, Rendezvous clients verify certificates from Rendezvous daemons by matching them against trusted certificates previously registered with the client program.
If you require CA-signed certificates, or if your organization already uses CA-signed certificates, you may use them by packaging each one together with its CA root certificate and intermediate certificates—a complete trust chain for each certificate. You can use standard certificate utilities to create certificate files in the appropriate encoding formats.
Level of Trust—CA-Signed versus Self-Signed Certificates
When client connects to a daemon, both forms of certificate (CA-signed and self-signed) represent equivalent levels of trust.
The daemon accepts the client’s certificate only if the daemon is configured to accept that certificate as the identity of a valid user, or as the identity of another trusted daemon.
The client accepts the daemon’s certificate only if the client has previously registered that certificate as the identity of a trusted daemon.
In these situations, self-signed certificates can be more convenient than CA-signed certificates, with no degradation in security.
However, when a browser connects to a daemon’s browser administration interface, CA-signed daemon certificate chains do represent a stronger level of trust than self-signed daemon certificates. Furthermore, using CA-signed daemon certificates can help avoid browser security warnings.
Passwords

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved