Creating top-level decrypting relays

When an action is deployed, thousands of clients might report back in a short time frame, typically to a relay. If you have chosen to encrypt these reports, the relay bundles the reports together and passes them to the server, which must then split up and decrypt each one of them.

With many thousands of clients, this can impose a significant computational burden on the server.

To improve performance, you can lighten the load on your server by allowing your top-level relays to do the bulk of the decryption. If you have over 50,000 clients, you might be able to substantially reduce the load on your server by moving decryption down into the relay chain. If the relay has its own decryption key, it can first decrypt the client messages into plain text and then bundle thousands of them into a single archive. This can then be compressed, encrypted, and passed to the server. At that point, the server can perform a single decryption on the entire archive, noticeably reducing its overhead.

To spread the decryption tasks, distribute your encryption keys to your top-level relays. For normal server-level encryption, HCL creates an encryption key for you and places it in the program folder:

On Windows systems:

      %PROGRAM FILES%\BigFix Enterprise\BES Server\Encryption Keys

On Linux systems:

      var/opt/BES Server/Encryption Keys

To allocate the load to your top-level relays, place the encryption key in the equivalent relay directory:

On Windows systems:

      %PROGRAM FILES%\BigFix Enterprise\BES Relay\Encryption Keys

On Linux systems:

      var/opt/BES Relay/Encryption Keys

These top-level relays decrypt all the documents received, bundle them together, and then re-sign them with a single signature. You can put as many keys as you want in the folder and the relay attempts to use each of them when it gets an encrypted client report. clients encrypt against the key found in the masthead file, which should be the last key created. However, it is possible that a client transmits a report with an older version of the masthead (and thus a different encryption key) if it has not gathered the latest actionsite for any reason.

When you use top-level encryption, consider the following best practices:

  • You must manually transfer the key file from the server to the relay every time you create a new encryption key.
  • During the transfer process, it is important not to expose your private key file. This means that you must not move the key over the internet because anyone listening might be able make a copy of your private key file. Instead, physically transfer the key from one computer to another, for example, with a USB key.
  • During the encryption key creation process, you have the option to create the private key file, but not propagate it out in the masthead. This step gives you time to transfer the new key file to the relays before clients start posting encryption messages with that key.