Вы можете создать один секрет для каждого сервера, используя только MD5.Я не уверен, что это правильно, поэтому не поверьте мне на слово.
Каждый сервер имеет уникальный идентификатор, который может быть открытым, а также локальный секрет, равный MD5(trusted secret + unique ID) или подобный.Вам нужно будет передать локальный секрет на сервер по какому-либо внешнему безопасному каналу, но, например, если он загружен с сайта одной компании по протоколу HTTPS вместе с кодом сервера, и если вы убедитесь, что никогда не отправляете локальный секрет длязаданный уникальный идентификатор более одного раза, тогда я думаю, что все в порядке.
Сервер может затем отправить свой идентификатор клиенту вместе с идентификатором сервера.Доверенный клиент может сгенерировать MD5(trusted secret + unique ID) для себя, но ненадежный клиент не может сгенерировать его.Это дает серверу и доверенному клиенту общий секрет, который можно использовать для аутентификации с использованием (например) HMAC-MD5.
Если утечка локального секрета, то только ненадежным клиентам предоставляется возможность обмануть это.негерметичный сервер, а не другие серверы.
Очевидно, что у этого есть недостатки - например, MITM между сервером и доверенным клиентом может обеспечить правильный ответ на любой вызов, который делает сервер, не зная никаких секретов.Но он не раскрывает секрет клиента серверу и не раскрывает секрет сервера клиенту, поэтому он несколько лучше, чем ничего.
У него также есть криптографические недостатки - MD5 несколько сломан.Если я сервер и могу найти x такой, что MD5(x + my_id) == my_secret, то скорее всего x является секретным ключом.Я не знаю, насколько вычислительно возможно найти x с учетом одного или нескольких локальных секретов: это зависит от текущей степени поломки MD5.
Я думаю, что MITM абсолютно неизбежен, учитывая ваши ограниченияхотя я могу ошибатьсяДоверенный клиент не имеет возможности отличить один сервер от другого, в частности, использует ли сервер свой уникальный уникальный идентификатор, и поэтому всегда будет давать правильные ответы на любые вызовы, которые проходит MITM.Однако, при условии, что в сообщениях есть какое-то значение, которое злоумышленник не может контролировать, например, сгенерированный сервером одноразовый номер или дата, простое прослушивание не приводит к атакам воспроизведения.Я не знаю, как предотвратить MITM без использования асимметричного шифрования и PKI, то есть различных базовых крипто-строительных блоков, которые у вас нет времени / возможностей для реализации на вашем языке.
Можно сделать так, чтобы система обеспечивала отзыв ключа.Если вы настроите полномочия своей компании на выдачу пар (random server ID, local secret) по требованию, то серверы могут время от времени обновлять свой локальный секрет (и одновременно менять свой идентификатор).Затем вы можете изменить доверенный секрет, и серверы прекратят аутентификацию клиентов, использующих старый, и начнут аутентификацию клиентов, использующих новый, как только они получат следующий идентификатор.Как уже говорилось, это довольно болезненная передача, вы, вероятно, захотите немного смягчить ее, если строите такую схему.