Например, для формирования ключа используем протокол Диффи-Хеллмана:
делаем все, как обычно, но открытые части ключей подписываем, используя ECC160, который прошит в
аппаратном ключа защиты - чтобы второй корреспондент был уверен, что связь устанавливается с доверенной стороной.
Естественно, корреспонденты должны находиться в контролируемой зоне, чтобы исключить возможность попадания в руки злоумышленника кодов доступа к алгоритмам аппаратного ключа защиты. Лучше, конечно, чтобы у корреспондентов для подписи были локальные ключи, чтобы избежать возможности перехвата кодов доступа к ключам по сети.

Если я правильно понял, то приложение через API будет обращаться к сетевому ключу при шифровке/дешифровке каждого сообщения?

Да.

Причем если обмен такими шифрованными сообщениями будет слишком интенсивным, то использование именно одного сетевого ключа может быть затруднено, но использовать можно и локальные ключи, которые устанавливать придется и на клиентских компьютерах.

Если я правильно понял, то приложение через API будет обращаться к сетевому ключу при шифровке/дешифровке каждого сообщения?

Передача зашифрованных сообщений по открытому каналу?

Точнее будет так: обмен зашифрованными сообщениями между двумя приложениями по открытому каналу.
Защищенный канал будет организован позднее. 

Сообщения представляют собой запросы на сервис и ответы с него: т.е. вызов методов сервиса, получение ответов - сообщений от сервиса, данных и т.п.
Отловить в приложении- клиенте исходящее приложение не сложно, как и прочитать входящее на сервисе (и в обратном порядке)

Да, лицентзировать ПО нужно, как и ограничивать количество копий( ограничение по группам возможно?), но с этим вопросы пока не поднимаются

С перехватом сообщений проблем нет.

Как то путано получается.
Все же чего изначально нужно добиться:

• Передача зашифрованных сообщений по открытому каналу?

• Или организация защищенного канала для безопасного обмена сообщениями?

• Иная задача?

• Что из себя представляют сообщения в контексте данной задачи, для чего используются?

• Нужно ли лицензировать ПО? Т.е. нужна ли привязка к электронному ключу? Требуется ограничивать количество запускаемых копий приложения?

Фактически ключи Guardant умеют зашифровать блок байт, например.

Тут речь идет о шифровании трафика протокола обмена между ключом и защищенным приложением

Да, теперь понял, каждый видит то что хочет видеть ))

К сожалению я не силен в  сетевой терминологии. Мне нужно зашифровать исходящее  сообщение в приложении и расшифровать входящее. С перехватом сообщений проблем нет.

Просто мне описали такую возможность - на клиенте получить сетевой ключ, зашифровать исходящее сообщение и отправить на сервис, сервис, получив сообщение, получает отправленный клиенту ключ( физический доступ к ключу и серверу ключей есть, так как сервис располагается на одной машине с ними) и соответственно расшифровывает данное сообщение, и тоже самое в обратную сторону. Получается что описанное неверно, и такой возможности нет, так?
Или возможности по заранее определенному на клиенте и сервере слову зашифровать и расшифровать сообщение?
А уже потом предполагалось сверху навесить VPN, чтобы наверняка).

включая шифрование трафика

Это не имеет отношения к организации защищенного канала связи и передачи данных в сети (например, через интернет). Тут речь идет о шифровании трафика протокола обмена между ключом и защищенным приложением. Т.е. только данные которыми ключ обменивается с защищенным приложением чтобы "подтвердить" свою подлинность и выделить лицензию для копии приложения.

Тут кажется речь идет именно о защищенном канале передачи данных между сервисом и удаленными приложениями-клиентами, верно?

отчего и возникла задача:

Большего пока не требуется, поэтому и рассматривается этот вариант.
Небольшое уточнение : сервис будет располагаться на одном компьютере с ключом.

Электронные ключи Guardant предназначены для защиты (от нелегального тиражирования) и лицензирования программных продуктов.

Организовать защищенный канал обмена данными позволяют средства построения виртуальных частных сетей (VPN), а усилить безопасность помогают аппаратные решения для двухфакторной аутентификации.

Для построения VPN обычно требуется развернуть "сервер" в целевой сети, который будет производит аутентификацию пользователей, а на компьютерах пользователей установить специальную программу VPN-клиент. Для получения доступа к защищенной сети пользователям могут выдаваться персональные логин\пароль (менее безопасно) или персональный аппаратный токен\смарт-карта (более безопасно).

Из нашей продукции тут подойдут:

1. Рутокен VPN - комплексное решение состоящее из аппаратного VPN-сервера и электронных идентификаторов линейки моделей Рутокен ЭЦП;

2. Также можно самостоятельно развернуть VPN-сервер в сети и использовать для безопасной двухфакторной аутентификации Рутокен ЭЦП (например как описано в инструкции по ссылке).