The Recovery agent is a trustworthy organizations that issue and sign public key certificates. This organization should be an entity independent of entities owning the iFolder server's infrastructure, or, independent of the IT department if deployed in a corporate environment.
Recovery agent certificates are the public key certificates used for encrypting the data encryption key. The user selects one of these certificates to perform the data key encryption for later key recovery. The supported certificate formats are *.cer and *.der(X.509).
You can use the self-signed certificates if the iFolder is deployed in a trusted environment.The certificates are generated by using the YaST CA Management plug-in or OpenSSL tools.
To protect user data from access by unauthorized people, the user data is encrypted by using keys that always occur in private and public key pairs. The keys are applied to the user data in a mathematical process, producing an altered data record in which the original content can no longer be identified.
Private Key: The private key must be kept safely by the key owner. Accidental publication of the private key compromises the key pair and can also be a security threat. The private key is either held by the Recovery agent or the user.
Public Key: The key owner circulates the public key for use by third parties.
Certified Authority (CA): The public key process is popular and there are many public keys in circulation. Certified Authorities are the trustworthy organizations that issue and sign public key certificates. The CA ensures that a public key actually belongs to the assumed owner. The certificates that a CA holds contain the name of the key owner, the corresponding public key, and the electronic signature of the person or entity issuing the certificate. The iFolder Recovery Agents are examples of one kind of CA.
Public Key Infrastructure (PKI): Certificate authorities are usually part of a certification infrastructure that is also responsible for the other aspects of certificate management, such as publication, withdrawal, and renewal of certificates. An infrastructure of this kind is generally referred to as a Public Key Infrastructure or PKI. One familiar PKI is the X.509 Public Key Infrastructure (PKIX). The security of such a PKI depends on the trustworthiness of the CA certificates. To make certification practices clear to PKI customers, the PKI operator defines a certification practice statement (CPS) that defines the procedures for certificate management. This should ensure that the PKI issues only trustworthy certificates.
X.509 Public Key Infrastructure: The X.509 Public Key Infrastructure is defined by the IETF (Internet Engineering Task Force) that serves as a model for almost all publicly-used PKIs today. In this model, authentication is made by certificate authorities (CA) in a hierarchical tree structure. The root of the tree is the root CA, which certifies all sub-CAs. The lowest level of sub-CAs issue user certificates. The user certificates are trustworthy by certification that can be traced to the root CA.
X.509 Certificate: An X.509 certificate is a data structure with several fixed fields and, optionally, additional extensions. The fixed fields mainly contain the name of the key owner, the public key, and the data such as name and signature relating to the issuing CA. For security reasons, a certificate should only have a limited period of validity, so a field is also provided for this date. The CA guarantees the validity of the certificate in the specified period. The CPS usually requires the issuing CA to create and distribute a new certificate before expiration. The extensions can contain any additional information. An application is only required to be able to evaluate an extension if it is identified as critical. If an application does not recognize a critical extension, it must reject the certificate. Some extensions are only useful for a specific application, such as signature or encryption.
Table 6-1 X.509v3 Certificate
YaST-Based PKI: YaST contains modules for the basic management of X.509 certificates. This mainly involves the creation of CAs and their certificate. YaST provides tools for creating and distributing CAs and certificates, but cannot currently offer the background infrastructure that allow continuous update of certificates and CRLs. To set up a small PKI, you can use the available YaST modules. However, you should use commercial products to set up an official or commercial PKI.
Start YaST and go to
.Click
.Enter the information for creating the CA in the dialog boxes. The following table summarizes the decisions you make.
Click
.Enter a password in the second dialog. This password is always required when using the CA for generating certificates. The following table summarizes the decisions you make.
YaST displays the current settings for confirmation.
Click
.The root CA is created then appears in the overview.
iFolder key recovery mechanism uses the X509 certificates to manage the keys. You can either get a certificate from an external Certified Authority, for instance Verisign* or generate a self-signed certificate if deployed in a trusted environment, where a trusted user-admin relationship exists.
NOTE:In certificates intended for e-mail signature, the e-mail address of the sender (the private key owner) should be contained in the certificate to enable the e-mail program to assign the correct certificate. For certificate assignment during encryption, it is necessary for the e-mail address of the recipient (the public key owner) to be included in the certificate. In the case of server and client certificates, the hostname of the server must be entered in the Common Name field. The default validity period for certificates is 365 days.
This section discusses creating self-signed certificates for encryption and self-signed key certificate for key recovery using YaST.
Start YaST and go to
.Select the required CA and click
.Enter the password for the CA if asked for.
YaST displays the CA key information in the Description tab.
Click Certificates tab.
Click
.Enter the information for creating the certificates in the dialog boxes. The following table summarizes the decisions you make.
Enter a password in the second dialog.The following table summarizes the decisions you make.
YaST displays the current settings for confirmation.
For information on encryption, see the Novell iFolder 3.7 Security Administration Guide.
Click Export drop-down and select
.Select
.Specify a password of minimum length of five characters.
Click
to find a location to save the file, then specify a filename for the certificate you have created.Click
to save the certificate.Convert the certificate in PEM format to DER format using OpenSSL command as given below:
openssl x509 -in <certificate>.pem -inform PEM -out <certificate>.der -outform DER
Copy the certificate in DER format to the location you have configured for loading Recovery Agent Certificate during iFolder configuration.
If the certificate is expired, you need to load the new certificates again to this location.
Restart the iFolder server to load the Recovery agent certificates.
Click Export drop-down and select
.Select
.Specify a new password and re-enter that for confirmation.
This password is used with the certificate and the keys exported to a file in XML format.
IMPORTANT:You must use a password different from the one you have used for certificate creation.
Specify a filename for the certificate you have created and click Browse to find a location to save the file.
Click
to save the certificate.Each iFolder has a unique data encryption key which is auto-generated during iFolder creation. The key is encrypted by using a passphrase provided by individual user and also by using the public key with the Recovery agent. If the user forget the secret passphrase, he or she cannot access either the iFolder data or the encrypted key used for recovering it unless the passphrase is saved locally (enabling Remember passphrase). To avoid this problem, user export the keys using the
option in the client and send it manually to the Recovery agent using the e-mail address provided in the Export dialog box in the client GUI. The Recovery agent retrieves the keys and sends back to the user through e-mail or any other communication channel. User can then import the keys and use them to reset the passphrase.NOTE:The keys are exported to a file in XML format. It is recommended to save the file as <filename>.xml
This section help you understand the process followed by a Recovery agent to retrieve the key.
Go to the location where iFolder is installed.
Run KeyRecovery or KeyReovery.exe based on the platform you use and follow the on-screen instructions.
The following table summarizes the decisions you make.
Send the decrypted key usually by replying to the mail attached with the encrypted keys and the one-time passphrase (if the key is encrypted using the one-time passphrase) to the user.
Send the one-time passphrase (if the key is encrypted using the one-time passphrase) to the user through any other communication channel other than the one you used to exchange the key files.
The self-signed certificates for iFolder services change when they are expired, revoked, or replaced with a new certificate by a new CA.
Client: When a new certificate is created, the user has to approve of from the client side. The client prompts for the new certificate for the user to accept it.
Web Admin Server: The change in the certificate is not automatically communicated to the Web Admin server. You must reconfigure the Web Admin server for the new certificate to be accepted. By default, the new certificate is accepted in the server side. In the front-end, the browser is updated automatically when the server is updated with the new certificate.
Web Access Server: The change in the certificate is not automatically communicated to the Web Admin server. You must reconfigure the Web Access server for the new certificate to be accepted. By default, the new certificate is accepted in the server side. In the front-end, the browser is updated automatically when the server is updated with the new certificate.