как это помешает делать проверку подписанного бинаря, а в реале исполнять совершенно другой код?

Без построения доверенной среды загрузки - никак.

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

Чисто техническими средствами подобная задача ИМХО не решается в принципе, потому что даже просто наличие такого сервера не гарантирует его неперемещение на свалку и заменой на менее доверенный.

Там выше Intel SGX посоветовали, что в принципе похоже на хоть какое-то решение.

Ты удивишься, но именно такой фантастически огороженный tamper-resistant замена-resistant девайс у тебя под крышечкой проца уже может лет пять как. Гуглить Intel SGX и прочие TEE.

Расскажи, ЛОР, есть ли у тебя какие-нибудь мысли по этому поводу?

Выстроить архитектуру так, чтобы корректность пакетов данных от удаленной машины («сервера») могла быть быстро удостоверена [1] на локальной машине («клиенте»). Тогда на имплементацию сервера будет вообще побоку, пусть хоть обзакладываются.

[1] Возможно, с вероятностью < 100%, однако сколь угодно близкой к этому значению

Смотрите, сервер компилит два билда серверного ПО, хеш первого отдает клиенту, второй билд (модифицированный вредоносным кодом) запускает, ну и как клиент проверит что его сообщения идут не через первый билд, а через второй? Я вижу тут только какое-то решение блокчена, рассчитываемого от выполненного кода+переданного сообщения, то есть код как данные, вот это вот всё, но опять же ничто не мешает серверу иметь два одновременно работающих экземпляра ПО.

Тоже, возможно, глупая идея, но не может ли клиент передавать на сервер виртуальную машину, которая может запускать только определённый подписанный байткод? Передвавать перед каждым соединением, таким образом, чтобы возвращаемый ответ зависел от конкретного переданного инстанса этой машины?

Хм, век живи - век учись. Даже под Linux кто-то напилил драйвера

В код не смотрел, если там решается вопрос сборки приложения так, что оно не запустится нигде кроме как в подобном «анклаве» на конкретной железке, то попахивает win-ом.

ИМХО вином там пока что именно попахивает, но может в будущем и получшеет.

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

Думал тред будет интереснее.

Ты не про сервер и клиент говоришь, а о том, как аутентифицировать другую сторону соединения по какому-то протоколу из TCP/IP стека в Zero Trust Network.

Готовых решений без арбитража пока нет. А смысла в арбитраже нет, потому, что всё сейчас завязано на TLS и сертификаты можно украсть.

И любые работы в сторону подписи бинарника тоже будут оправданы в том случае, если сертификат которым подписывали нельзя украсть/сгенерировать. А это невозможно гарантировать.

Возможно, если бы я знал хоть что-то про блокчейн, кроме того как приносить свои диски в жертву фармингу chia, я бы стал рассуждать о распоеделённой сети дистрибуции и исполнения неизменяемых данных, в том числе кода сервера нужной тебе для соединения версии.

Блокчейн может подтвердить время билда, а если временная метка окажется одинаковой, то всё равно укажет линейный порядок. Если издатель одновременно опубликует два взаимно конфликтующих билда, то выберет один из них, хотя эта возможность скорее более теоритическая. Сам по себе блокчейн никак не гарантирует выполнение немодифицированного кода на немодифицированной машине, даже если код записан в блокчейн. Например, в Биткоине предполагается изменение поведения NOP опкодов для обновления машины. Кажется, такое никак не вычислить на машине Тьюринга, но в тему можно попробовать добавить квантовые вычисления.

сертификаты можно украсть.

В смысле ключи? Так ты ничего не построишь. Почитай про аппаратные токены, может поотпустит.

Привет, искусственный интеллект, мы тебя заждались.

Какие ещё аппаратные токены? Из докера, например? hasp тот же на сертификатах. Аппаратные токены тут вообще причём?

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

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

Могут, че бы им не мочь. Втыкаешь, указываешь сервису pkcs#11 uri токена и в бой.

Ок, расскажи мне пожалуйста как это решает проблему поднятую тредом?

Я отвечал на

И любые работы в сторону подписи бинарника тоже будут оправданы в том случае, если сертификат которым подписывали нельзя украсть/сгенерировать. А это невозможно гарантировать.

s/сертификат/ключ/

Для подключения к токену нужно указать сертификат, не?

Какой-то сложный диалог. Для работы с токеном бывает нужно указать пин/слот. Указать их можно как часть uri. Токены оперируют ключами и операциями над ними. Не уверен, что токенам есть дело до такого понятия «сертификат».

Как тогда софт запущенный злоумышленником можно отличить от легитимного, когда к токену можно подключится всем кому не лень?

Никак, все проблемы разом ты этим не решишь. Но так ты хотя бы знаешь, что он запущен злоумышленников вон на том твоём конкретном хосте, а не у него дома на ноуте, что сильно упрощает оборону.

Просили невозможность спереть, а не невозможность попользоваться =)

Просили невозможность спереть

Хз кто такое просил, не видел подобного. Спереть сертификаты? Так ещё раз говорю - взаимодействие по сети аутентифицируется сертификатами. По сети железные какие-то токены не раздать, а если раздать (проверка как в hasp, например) то с использованием сертификатов. Это замкнутый круг.

Ну, тогда, всё проще...

Просили невозможность спереть, а не невозможность попользоваться =)

Тогда закупить Yubikey 5 те же и сорганизовать аутентификацию через PAM для именно этого приложения. Тогда, если есть на usb этот самый yubikey, то есть возможность работать – работаем. Если нет – лесом.

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

Правда, от проблем со сменой ролей это не гарантирует и надо будет ещё вести список отозванных (утерянных) ключей. И ещё вопрос – будет ли применим gpg в такого рода «сети», не накладывается ли ограничений? А то gpg/pgp это нельзя для ряда случаев.

Как-то так?

Надо на сервер отправить специальный запрос с содержимым: «а ты точно тот, за кого себя выдаешь?» Если ответ будет что-либо кроме «мамой клянус!», такому серверу ни в коем случае доверять нельзя.

Хз кто такое просил, не видел подобного.

Аутентификация удалённого кода (комментарий), второй раз уже

Так ещё раз говорю - взаимодействие по сети аутентифицируется сертификатами. По сети железные какие-то токены не раздать, а если раздать (проверка как в hasp, например) то с использованием сертификатов. Это замкнутый круг.

Почитай как вообще public key cryptography работает. Приватные ключи не передаются и не раздаются; генерируется и применяются по месту. Сертификаты подписываются путем передачи на подписание CSR. Форму круга имеет только наша с тобой дискуссия.

Примерно. Забудь про pam, представь в первом приближении yubikey как нерасковыриваемое хранилище PGP-ключа, которое он никогда не покинет. А дальше на операциях PGP строй что хочешь. Достроишь — можно вспомнить и про остальные фичи yubikey и перевыразить через них, если выйдет проще.

Про проблемы со сменой ролей и применимостью не понял, отзыв стандартный.

Напомнило RFC про maliciousness bit и ещё мою любимую дырку в libssh.

Ну так-то да.

Примерно.

Примерно. Забудь про pam, представь в первом приближении yubikey как нерасковыриваемое хранилище PGP-ключа, которое он никогда не покинет. А дальше на операциях PGP строй что хочешь. Достроишь — можно вспомнить и про остальные фичи yubikey и перевыразить через них, если выйдет проще.

Да, это понятно. Просто, я про PAM вспомнил, т.к. в своё время делал аутентификацию через PAM с применением pgp на уровне приложения.

А так-то, в принципе, сам по себе yubikey это аппаратный вариант gpg. Т.е., всё, что мы можем сделать через gpg, мы можем сделать на этом ключе. И генерация ключей (приватная и публичная части) и хранение.

Вот некий раб Божий писал по теме. Ну и вот, сами они чего пишут.

Про проблемы со сменой ролей и применимостью не понял, отзыв стандартный.

С отзывом понятно как раз всё.

Проблема с применимостью заключается в том, что мы не знаем априорно будет ли автор реализовывать что-то под требования российского законодательства. Вспоминая то приснопамятное постановление, не могу не заметить что для «гостайны» нужно чтобы крипта была разработана и серитфицирована на территории Российской Федерации. Pgp/gpg тут сразу мимо, но можно попробовать вымутить что-либо с etoken/alldin, которые сертифицированы. По сути, это такие же смарт-карты, как и yubikey, но они считаются более доверенными. А так-то по сути, технология почти та же с точки зрения программирования. «Почти» здесь довольно условно, сразу оговорюсь.

Проблема с переменой ролей здесь, как я и писал выше, это проблема как в виндовом домене. Отъехал Primary Domain Controller, либо впряжётся назначенный BDC, либо надо будет устроить перевыборы контроллера домена и продолжить с той же точки, где остановились, дальше.

В случае ТС эту возможность предусматривать имеет смысл, т.к. сервера аутентификации в принципе положить (при желании) вполне возможно (банальный DDoS пойдёт, в принципе) и надо иметь возможность продолжать работу без первоначальных серверов аутентификации. Но конечно это не сразу надо бросаться и прописывать в коде, т.к. всё и сразу не реализуешь. Это я просто включил своего внутреннего «безопасника», да. =)))

Внутреннего нацпольщика ты включил =)

Добавь слово leak к запросу, который ты предлагаешь почитать. Ну или сразу про соларвинд почитай.

И? Противоречий с моей картиной мира не вижу, твой лопот лучше не стал. Что сказать-то хотел?

Ненене... =)))

Внутреннего нацпольщика ты включил =)

Это я просто напомнил об отдельных таких… «моментах». А то бывает что люди проявляют просто чудеса в мастерстве владения кунг-фу, а потом внезапно кто-то замечает что это вот… ихнее кунг-фу, оно ни фига не по фен-шую. И получается что лучше бы было на старте вспомнить про энтот самый фен-шуй. =) Я же об этом самом фен-шуе и не забываю. Как правило. =)))

А так-то я тут и не танцполю. Если кому хочется танцпола, то милости прошу в мой бложик в ЖиЖе (ник тот же), но я бы не рекомендовал, если честно. Это здесь я почти изысканно вежлив, а там я изъясняюсь на том языке, которому в гражданских ВУЗах и не учат даже. Если кого занесёт, то рекомендую читать с комментами. Гари там тоже более чем достаточно. =)))

В общем, я предупредил.