Inside Echoworx: S/MIME Walkthrough and Demonstration

Implementing boundary-based S/MIME removes the need for desktop software or endpoint certificates. Encryption happens entirely at the boundary, eliminating endpoint requirements. This allows communication through S/MIME on mobile, desktop, or tablets without additional software deployment.

All encryption is performed at the boundary. For outbound communication, S/MIME encryption or digital signatures are applied. Inbound communication is decrypted at the boundary, enabling secure archiving, journaling, and compliance with DLP (Data Loss Prevention) requirements. Decrypted messages are securely delivered over TLS to your gateway or email hygiene solution.

Echoworx supports external directory lookups, such as LDAP directories, for recipients' public certificates. This allows dynamic encryption based on certificate availability. External recipients can also upload their certificates directly to the Echoworx platform, enabling broader adoption and seamless communication.

The administration interface allows you to import existing key pairs into the platform. This can be done manually or through a bulk upload process.

Private key pairs can be uploaded manually or through bulk invite functionality, making it easier to manage larger migrations.

For more advanced needs, we offer API integration. This allows customers to perform bulk imports of private and public keys directly into the system through automated processes.

All key migration features are accessible through the administration interface or via API integration, based on your requirements.

From an outbound perspective, the general topology flow follows a straightforward process. A sender tags a message (or multiple messages) for encryption at the outbound boundary. This tagging can occur through:

• The Echoworx optional add-on
• A DLP rule
• A subject tag indicating the message needs to be encrypted

Once flagged, the DLP or SEG gateway, or M365, routes the message through security actions to Echoworx.

Echoworx encrypts the message based on an applied policy. This policy determines if a public certificate for the recipient is available. The certificate can be located either:

• Locally, within the LDAP directory (if a public certificate was previously received for the recipient)
• Through external directory services to locate a public certificate

If a certificate is identified for the recipient, Echoworx creates a certificate for the sender (if one doesn’t already exist) and encrypts the message as an S/MIME message for outbound delivery.

• Messages flagged for encryption are routed to Echoworx.
• Echoworx checks for a public certificate locally or through external directories.
• If a certificate is available, Echoworx generates one for the sender (if needed), encrypts, and signs the message for delivery.

The process ensures secure outbound encryption based on the defined policies.

The inbound decryption process works similarly to the outbound process but in reverse. Here's an overview of the implementation:

1. Inbound Message Identification
   The SEG gateway or DLP system is configured with basic rules to identify inbound S/MIME messages. If an inbound S/MIME message has not been processed by Echoworx, it is routed to Echoworx over a secure TLS connection.
2. Message Decryption
   Echoworx decrypts the message using the appropriate private key for the sender. This ensures the message content is accessible for further processing.
3. Routing Back to SEG Gateway
   The decrypted message is sent back to the SEG gateway or inbound SMTP over TLS. From there, it can be scanned, journaled, or archived as required.
4. Delivery to Internal Users
   Once processed, the decrypted message is delivered in its clear format to the intended internal recipient.

This flow ensures secure decryption and integration into existing systems, enabling seamless message delivery.

Echoworx encrypts the message based on an applied policy. This policy determines if a public certificate for the recipient is available. The certificate can be located either:

• Locally, within the LDAP directory (if a public certificate was previously received for the recipient)
• Through external directory services to locate a public certificate

If a certificate is identified for the recipient, Echoworx creates a certificate for the sender (if one doesn’t already exist) and encrypts the message as an S/MIME message for outbound delivery.

• Messages flagged for encryption are routed to Echoworx.
• Echoworx checks for a public certificate locally or through external directories.
• If a certificate is available, Echoworx generates one for the sender (if needed), encrypts, and signs the message for delivery.

The process ensures secure outbound encryption based on the defined policies.

Within the profile configuration for outbound communication, users can define how messages are delivered. For example, signing profiles can include:

• Signing with the sender's certificate.
• Signing with an auto-generated certificate, with fallback to the profile setting.

This provides flexibility in configuring how signatures are handled during message delivery.

The Echoworx platform supports domain-level encryption. A public certificate can be associated with a specific domain, allowing encryption of messages sent to that domain. For example, if a recipient does not have their own public certificate, messages sent to "Echoworx.com" can still be encrypted using a public certificate assigned to the domain. This functionality ensures secure communications at a domain level.

• Private and public keys can be imported into the system.
• Self-management notifications are provided for external users who upload their public keys.
• Notifications ensure users are informed when their public certificates are about to expire, prompting them to upload a refreshed certificate.
• Integration with LDAP directories eliminates the need for certificate expiry tracking, as directories are kept up to date automatically.

• Echoworx enables automatic private key and certificate generation for senders.
• Integration with DigiCert and SwissSign allows for seamless auto-generated certificates for senders if one is not already available.
  • An account with either DigiCert or SwissSign is required to enable this feature.

• For external recipients who need to receive encrypted emails via S/MIME but do not have a DigiCert or SwissSign certificate, self-signed certificate generation is now available.
  • Recipients can generate their own certificates within the portal.
  • These certificates can be downloaded for use on their Windows or Mac device, enabling them to receive S/MIME messages without needing to create or purchase a key manually.

• User-generated keys, created outside of the system, can also be imported.
  • This includes keys generated with other certificate authorities (CAs) beyond DigiCert and SwissSign.
  • The integrations with DigiCert and SwissSign are optional but available for streamlined key creation.

• Users can switch between delivery channels, including S/MIME, PGP, portal, or PDF, depending on their preferences.
• This flexibility allows users to tailor how they send and receive secure communications.

The S/MIME tab provides an administrative view of certificate and key management. It allows you to see how keys are used and managed under your profile.

Key Expiry Notifications

The system sends notifications when keys are nearing expiry, whether they were uploaded administratively or by end users. This ensures users can recreate keys in time to avoid disruptions.

Auto-Generation of Keys

For keys that are auto-generated, the system will automatically create a new key when the existing key expires. This reduces manual interruptions and ensures continuity.

Built-in Automation

Automation features are integrated into the platform to simplify processes, such as key generation and expiry notifications.

Echoworx allows you to manage private keys. You can view the keys loaded under your profile, including those that are administratively loaded, end-user loaded, or auto-generated. Keys can be expired or deleted directly from the system as needed.

Here, you can review public keys that are associated with your profile. These may include keys uploaded by administrators or end users.

Manual Key Upload

• Sender A may upload a private key manually into the system.
• The private key might have been generated by an off-system Certificate Authority (CA).

Automatic Key Generation

• If Sender A doesn’t have a private key and no manual upload has been made, the API bridge can request a key from providers like DigiCert or SwissSign.
• A private key is generated automatically using certificate profiles defined in the CA provider.
• The key is then imported into the system, encryption is applied, and the email is sent.

• The system can check the recipient's LDAP directory (if available) to locate their public key.
• The public key is used to encrypt the email before sending it as an S/MIME message.

• When the external recipient responds, their reply will also be encrypted and signed using S/MIME.
• The incoming message is decrypted upon arrival, following the decryption process outlined earlier.
• A demo is available to illustrate this process in greater detail. link to brighttalk - open in new window https://www.brighttalk.com/webcast/19663/642962?utm_source=Echoworx&utm_medium=brighttalk&utm_campaign=642962

If enabled, the platform will determine how a message is sent—whether through PGP, S/MIME, or a secure portal. Even if it’s a single message, delivery will be based on established policies and the available delivery channels, ensuring recipients receive the message in the most appropriate way.

Delivery methods are guided by your policy controls. For example, as shown in above scenario, the message is encrypted and sent as S/MIME.

As part of the decryption process, we can add information to the header or footer of the message, indicating that it was securely delivered. This helps the recipient understand that the communication remains secure. For example, it could specify, "This was an S/MIME message decrypted" or "PGP message decrypted."

By including this information, we provide clarity to the recipient, ensuring they are aware the message was decrypted securely.