Как защитить связь по именованным каналам .NET от внедрения DLL на стороне клиента? ⇐ C#

[Гость]

Наше приложение .NET Framework C# состоит из двух частей: клиента (с повышенными правами) и службы (с повышенными правами). Связь между клиентом и службой осуществляется через именованный канал. Клиент (клиент именованного канала) всегда взаимодействует со службой (сервером именованного канала) всякий раз, когда необходимо выполнить задачу с повышенными правами. Сообщение осуществляется в форме строки JSON. Этот обмен данными должен быть защищен, чтобы службу нельзя было обмануть и заставить выполнить задачу с повышенными правами от имени злоумышленника.

На стороне сервера уже приняты некоторые меры безопасности:
[*]Объект Pipe Security имеет некоторые меры безопасности:
PipeSecurity PipeSecurity = новый PipeSecurity(); var id = новый SecurityIdentifier (WellKnownSidType.AuthenticatedUserSid, null); // Разрешаем доступ для чтения и записи к каналу из разных пользовательских сессий PipeSecurity.SetAccessRule (новый PipeAccessRule (id, PipeAccessRights.ReadWrite, AccessControlType.Allow)); // Предоставляем экземпляру пользователя службы полный доступ. PipeSecurity.AddAccessRule(new PipeAccessRule(System.Security.Principal.WindowsIdentity.GetCurrent().User, PipeAccessRights.FullControl, AccessControlType.Allow)); [*]Служба проверяет путь к exe-процессу, который пытается подключиться к службе с именем Pipe. Служба принимает соединение только в том случае, если клиентский процесс находится на пути из белого списка. Проблема Однако существует риск использования другого эксплойта — внедрения DLL. Если DLL внедряется в наш клиентский процесс, то когда DLL пытается подключиться к нашему сервису с именем канала, путь к DLL выглядит таким же, как и у клиентского приложения. Это обманывает службу, и некоторые произвольные команды могут быть переданы из внедренной DLL (вредоносной) в службу. Возможно, это позволит повысить привилегии. Как мы можем быть уверены, что только наше клиентское приложение может взаимодействовать со службой?
Связанное
Может быть это связано, я не уверен: Получить токен пользователя клиента из именованного канала

Следует ли нам попытаться защитить именованный канал, чтобы избежать внедрения DLL для связи с нашей службой, или нам следует вообще попробовать использовать другой IPC, например Контракт на обслуживание?
Идеи
Для решения этой проблемы попробовал усовершенствовать следующие идеи:
[*]
Права безопасности и доступа Microsoft (https://learn.microsoft.com/en-us/windo ... ess-rights) Кажется, это немного сложно понять. Кроме того, я не уверен, что это действительно решит мою проблему.
[*]
Рассмотрено использование асимметричного шифрования при обмене данными между клиентом и службой. Но проблема этого подхода заключается в том, что безопасное распределение открытых и закрытых ключей между клиентом и сервисом выглядит невозможным. Учитывая, что клиент работает без повышенных прав, он определенно не сможет хранить открытый ключ в безопасном месте. Следовательно, злоумышленник легко сможет изменить открытый ключ и предоставить свой собственный открытый ключ, чтобы обмануть службу.