Так а что мешает модифицировать код сервера для того чтобы он отдавал другой результат?

Ничего не может сломаться.

как удостовериться, что код, который реально запущен на сервере – это именно открытый код, выложенный на GitHub, а не какая-нибудь поделка от ЦРУ/ФСБ/Моссада?

Ставить свое доверенное железо сервера и использовать ключ при связи с сервером для защиты от MITM.

Intel SGX мешает, очевидно.

SGX enclaves also support a feature called remote attestation. Remote attestation provides a cryptographic guarantee of the code that is running in a remote enclave over a network.

Intel SGX мешает, очевидно.

Окей, кто мешает проксировать копию запроса с данными на сервер, в котором такой же код работает без SGX, и чинить таким образом непотребства.

Все это на Enarx очень похоже, посмотри его для вдохновения. Но там речь о доверенном запуске своих ворклоадов на железе у кого попало.

Оп писал выше в комментариях

никто не мешает проксировать запросы о проверке целостности на другой сервер, крутящий немодифицированный код.

Если у нас на сервере за прокси две ноды (одна модифицированная, вторая оригинальная), мы не сможем отдать нужный ответ клиенту?

Thx! Посмотрю.

Блин, ну почитай уже, как он работает. Твоё удалённое приложение устанавливает связь с enclave-ом. В этом процессе участвуют сервисы Intel, которые проверяют, что общение идёт с enclave-ом (видимо с помощью зашитых в процессор и подписанных ключей). То бишь тебе надо либо взломать Intel, либо разломать этот secure enclave в процессоре. Если ты NSA, наверное шансы есть. Если ты не NSA - вряд ли.

Дочитал тред, оказывается Intel SGX уже был упомянут, так что не факт, что тебя порадует Enarx. Но лучше все равно в обозримом будущем не будет.

К сожалению...

Насколько я помню, в этом Intel-специфичном решении, есть возможность реализовать хищение RSA-ключей. И, тем самым, получить как локальное, так и удалённое одобрение (аттестацию). Локальная аттестация это когда два компонента получают друг у друга одобрение на одном хоста, удалённая аттестация – через сервер.

А какая разница какой код обфусциоровать, бинарный или как-то по-другому открытый? В количестве человекодней на вскрытие? Ну эту историю можно подогреть и рассказать юзаторам js обфускаторов.

Более того, моё бедное понимание про wbc было, примерно такое:

сделать так, чтобы критичный функционал не работал, если не соответствует какому-то криптографически-стойкому секрету и переписать его эквивалентно - дорого.

Конечно - в случае открытого кода понятие «дорого» сильно усугубляется тем, что обладателей возможности посмотреть этот самый код становится сильно больше а количество инстансов которые атаковать тоже не мало. Но если перестать параноить, и принять во внимание, что 99% открытого софта ни разу не видели его исходники, не то что код, то как бы не так всё страшно, как хотят напугать.

Я совсем не в теме, спасибо что пнул в этом направлении, интересно.

Почитал немного, вопросов (скорее всего глупых) два:

1. Если мы можем изменить код сервера (при полном контроле к железу и софту), то все равно обойти sgx не можем (например сэмулировать)?

2. https://www.helpnetsecurity.com/2020/11/16/break-intel-sgx/ первая ссылка из гугла (понятно конечно, что это просто PoC). Как такое лечится, обновлением микрокода на сервере?

Блин, ну почитай уже, как он работает.

Чувак, я читал это много раз.

То бишь тебе надо либо взломать Intel, либо разломать этот secure enclave в процессоре.

Эксплоиты для SGX были. Но я понял твою идею: вера в SGX спасёт человечество. Окей, принято.

Как такое лечится, обновлением микрокода на сервере?

Некорректно вопрос задал, понятно чем лечится. Я имел ввиду, есть ли какой-то альтернативный способ убедиться в целостности?

1. Если мы можем изменить код сервера (при полном контроле к железу и софту), то все равно обойти sgx не можем (например сэмулировать)?

Если на пальцах, там идёт DH между клиентом и кодом внутри анклава, и это всё заверено ключами от Intel.

Если на пальцах, там идёт DH между клиентом и кодом внутри анклава, и это всё заверено ключами от Intel.

А если я возьму ключи от интел со старого железа до обновления микрокода и сделаю условный митм на прокси? Насколько понимаю, сработает.

1. Если мы можем изменить код сервера (при полном контроле к железу и софту), то все равно обойти sgx не можем (например сэмулировать)?

Не можем. По крайней мере без эксплоитов наподобие упомянутого тобой ниже.

2. https://www.helpnetsecurity.com/2020/11/16/break-intel-sgx/ первая ссылка из гугла (понятно конечно, что это просто PoC). Как такое лечится, обновлением микрокода на сервере?

По идее да.

Не, SGX, это, конечно, не что-то невзламываемое принципиально. Но это, насколько я знаю, единственное хоть какое-то решение, которое есть сегодня на рынке, призванное решать описываемую топикстартером проблему. Можно ничего не делать, а можно заюзать SGX и улучшить безопасность системы.

Хранить тысячу биткоинов в SGX-энклаве у удалённого провайдера, который хочет их стырить, я бы не стал. А что-то вроде того, что делает Signal - прошерстить контактную книгу на предмет юзеров Signal-а, при этом не сохраняя этих самых юзеров себе в базу, и декларируя эту фичу, как криптографически защищённую - милое дело.

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

Ну так неинтересно. Мне кажется, топикстартер хотел абстрактно порассуждать, возможно ли такое решение без вендорлока и прочего. Я тоже пока читаю про Enarx, но есть много вопросов.

А другой схемы кроме SGX-подобной нет и быть не может. В любом случае должен быть secure enclave с ключами, подписанными производителем. В любом случае на этот enclave будут всякие side-channel атаки, которые до устранения уязвимости можно эксплуатировать. Остаётся надеяться только на то, что у атакующего не хватает денег купить 0-day и что нашедшие уязвимость сообщат в Intel и подождут с публикацией достаточно времени для того, чтобы было выпущено обновление. Это то, как оно работает сейчас и для определённых целей этого достаточно.

Можешь посмотреть на гомо-морфное шифрование. Оно не совсем для этого, но, возможно, ты сможешь переформулировать свою задачу в этих терминах. Для простых алгоритмов, насколько я знаю, оно даже применимо.

Ну Enarx, судя по описанию, это просто слой абстракции над Intel SGX/AMD SEV. Тут ничего интересного нет.

Ага, ты прав. Скучно :)

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

Никак. Более того, если представить себе абстрактный http-сервер, например, то можно на запросы подписи работать подписанным бинарем, а на все остальные другим.

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

Потому что достаточно просто при определённых навыках просто и тупо откусить всю проверку, вернув из функции check_validity() что-нибудь типа return TRUE;

На клиенте, что ли? Сервер должен вернуть подпись клиенту. В противном случае недоверенный удаленный сервер уже наименьшая из твоих проблем :)

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

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

вычисления корректного хедера на основании валидной подписи и сервера

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

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

Можно загрузить на сервер обфусцированный бинарник с приватным ключом. У клиента есть открытый ключ которым верифицируется и расшифровывается соединение с бинарником на сервере. ПО сервера просто не сможет узнать о чём общаются клиент и бинарник.

Взломать такое можно, но сложно: это должна быть таргетинговая атака выполняемая высококлассным специалистом.

В дискуссиях о различных системах обмена сообщениями

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

Можно загрузить на сервер обфусцированный бинарник с приватным ключом

Ну то есть без «понятых» нельзя.

Я понимаю, что ответ на этот вопрос в общем случае звучит: «никак!»

Почему это? Source-based gentoo + подписи.

Можно раздоверивать разные TEE по мере их разламывания вероятным противником.

Но да, все это сомнительно и лично мне всегда кажется не революцией, а попыткой заюзать, что есть.

Как это выглядеть-то должно в рамках протокола между клиентом и сервером?

Как ты хочешь, чтобы это выглядело? Ты можешь доверять только тому, что сам собрал (если доверяешь изначальной версии гцц). А левый узел тебе может насвистеть всё, что угодно. Да, мерзкие читеры юзают свои читы, а продаваны кнопкодрочилок ничего не могут с ними сделать. Всё так плохо, что в Китае уже сроки за это дают.

Вопрос в том, как проверить, что код на сервере собран именно из вот этих вот исходников

Есть подвижки для того, чтобы из одних и тех же сорцов получался один и тот же бинарник. По крайней мере в жабке это работало.

если доступа к серверу нет.

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

Вот зря. Вообще зря.

На клиенте, что ли? Сервер должен вернуть подпись клиенту. В противном случае недоверенный удаленный сервер уже наименьшая из твоих проблем :)

Теперь я объясню почему я плохо реагирую на деление «клиент-сервер». Проблема проста.

Предположим, у Вас есть некое решение, где есть клиент и сервер. Сервер (или серверы) живут в своём ДЦ. И возвращают подписи клиентам, которых ни один и ни два. Всё хорошо, всё как-то, но работает.

Дальше некие уроды-злоумышленники кладут канал на этот ДЦ или на этот сервер (сервера). Банально длительным DDoS. Всё. Звиздец, приехали. Сервера отъехали, канал прилёг. И что, работа всё, встала?

Очевидно, что для данного случая в клиентах должен быть предусмотрена смена ролей, когда какой-то из клиентов берёт на себя функции генерации/возврата подписей и он в этом случае должен сам стать доверенным сервером. Ближайший аналог здесь – перевыборы контроллера домена в виндах. Лёг основной, всё равно найдётся какой-то хост, который будет обеспечивать работу домена.

Можем мы заранее сказать как мы будем резервировать и реализовывать эту возможность? Кто и на основании каких критериев станет доверенным сервером для всей этой сети в случае отказа основных серверов? Нет конечно. Мы эту возможность не рассматриваем изначально. У нас просто и тупо – сервера прилегли, всё, работа кончилась, все по домам. Это называется уязвимость by design. Вот почему я крайне косо смотрю на принятую среди коллег идеологию «клиент-сервер» без оглядки на реалии. Ибо внезапно вечер может перестать быть томным и всё станет грустно и печально.

Тут же ещё до кучи возникает проблема с тем, что в отношении ряда клиентов может быть проведена атака типа DNS cache poison. Т.е., ряд клиентов, которые используют какой-либо общий для них DNS server, вообще могут оказаться в ситуации, когда им навязали вообще левый сервак с обновами и они могут в принципе начать качать обновление не с доверенного сервера, а с фейкового. И что там за обновление они в таком случае скачают, можно только догадываться. Но скажу сразу – ничего хорошего.

Это чисто навскидку и крупными мазками. Сейчас нет плоских, однонаправленных атак. Сейчас есть атаки по разным направлениям и сразу. Я, собственно, вот что пытаюсь объяснить.

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

Здесь, как всегда, два вопроса:

• От чего и от кого мы защищаемся? Если от Василия-the-хаккИра, с gdb наперевес или radare2 с IDA Pro, то хватит в принципе проверки хэша на уровне локального хоста, где функционирует данное приложение. Даже по сети таскать ничего ненадо, изобретая аналоги гуглёвых сервисов для платных андроидных приблуд. У гугля это тоже не получилось, да они и в курсе почему не получится (как только мы перестаём контролировать корень доверия, при чём похрен на сервере или на клиенте, мы приплыли).

Если от ребятишек, которые в курсах поверхностей атаки для того же TEE/TrustZone/Intel SGX, то я Вас просто умоляю – не тратьте время. =))) «Защита» всегда будет отставать от «атаки» и служить только временной мерой. И её постоянно нужно будет менять и апгрейдить. Т.е., программисты начнут заниматься не наращиванием функционального наполнения приложения, а реализацией всё более хитро вые… реализованных алгоритмов защиты.

• Какова реальная стоимость защищаемой информации? В ряде случаев просто создают два информационных контура. Один для использования публичных сетей, с ним всё ясно. И другой, ни как не пересекающийся с первым даже на уровне инфраструктурного оборудования и каналов передачи данных, до немогусеньки герметичный, короче. И нет, там даже usb-флешку без «контроля» не вставишь. Чужие там не ходят в принципе.

Тогда проблема, которую пытается решить ТС решается сама собой. И так сеть доверенная, пользователи тоже, так что остальные примочки это просто от делать нефиг. Даже если софт кто-то зачем-то и ломанёт внутри герметичного контура, то толку-то с того?

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

Повторю ещё раз. Любая защита, это как замок. Она от честных людей. Хотите защиты? Реализуйте её на базе комплекса мероприятий. И организационных в том числе.

Ну или не майтесь фигнёй. Тоже вариант. ;)

Почему это? Source-based gentoo + подписи.

Ну кто о чём, а гентушники о генте :D

Вообще не разу не гентушник (ну так, один раз только рядом стоял, когда она собиралась).

Реализуйте её на базе комплекса мероприятий. И организационных в том числе.

Вот, Либерман дело говорит. Читерство можно победить только lan-туриниром на железе организатора.

Для протокола замечу...

Ну кто о чём, а гентушники о генте :D

Я по данному поводу промолчал, т.к. в курсе что в своё время некий товарисч поднимал свой оверлей с сознательно уязвимыми версиями. И этим оверлеем даже кто-то пользоваться умудрялся.

Второй товарисч делал небольшие патчи с той же целью. И тоже народ на счёт раз влетал. Дело давнее, сейчас уже ссылок не найду за давностью лет.

Не панацея это ни разу. Корень доверия, все дела… =)))

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

Ну дык... =)))

Вот, Либерман дело говорит. Читерство можно победить только lan-туриниром на железе организатора.

За столько-то лет эти грабли столько раз уже посетили, что даже прямо и неловко становится.

Железо тоже не панацея. Говорю же – если я как-то сподоблюсь перешить BIOS, то boot guard прикажет долго жить (я вот про что – https://habr.com/ru/company/dsec/blog/326556/). Следом я могу уже влезать в UEFI, где по сути крутится своя ОС и там даже возможно параллельное исполнение. Для того же UEFI, например, есть модули, предоставляющие возможность… удалённой активации виндов. Дальше продолжать или и так хватит?

Впрочем, ладно. Не буду дальше стращать. А то, если я скажу сколько в реале килобаксов стоит портирование на новую мамку загрузки (да, всё того же BIOS + UEFI), то боюсь что Россию ещё и в применении ядерного оружия обвинят. Просто потому, что у нашего недалёкого коллеги пердак так сдетонирует от цифирей, что пару близлежащих деревень просто на хрен снесёт. Под чистую. =)))

Ещё и в этом быть обвинённым, это вообще лишнее.

Варианты:

• Обойтись без сервера. Блокчейн и запуск одинакового кода на уйме нод технически решает всё это, но это сильно оверхэд.

• Забить на это, тупо клиентом проверять, насколько ответы сервера соответствуют ожидаемым. В зависимости от юзкейса может быть достаточно (ты не проверишь что сервер, например, не логирует что-то лишнее и не сливает эти логи куда-то, но ты можешь в какой-то степени проверять ответы сервера).

• Trusted Computing и вообще полный контроль железа сервера

• Никак

античит системы для онлайн игр представляют из себя именно то, что нужно

Античит — костыль, который нужен только потому, что ресурсы сервера не бесконечны и пинг между клиентом и сервером ненулевой. Не факт что твой юзкейс вытекает из таких же ограничений.

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

Подождать, пока сервер закончится в чёрную дыру.

Железо тоже не панацея.

Да, просто порог вхождения для проведения атаки (впрочем, как и для отражения/восстановления).

Не панацея это ни разу

Ну так надо свой оверлей, где точно будет всё с гитхаба, как в тз. По крайней мере ТС не будет очковать по поводу того, что дистростроители накатили сверху патчей от всех служб разведки разом.

Античит — костыль

Он вообще где-то работает? Как в этих их фпс ныли из-за читаков, так и ноют.

У меня почему-то появилось ощущение, что ты безопасник.

Да.

Да, просто порог вхождения для проведения атаки (впрочем, как и для отражения/восстановления).

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

Не поможет.

Скажу сразу, как гентарь.

Ну так надо свой оверлей, где точно будет всё с гитхаба, как в тз. По крайней мере ТС не будет очковать по поводу того, что дистростроители накатили сверху патчей от всех служб разведки разом.

В общем, когда SysRescCD спрыгнул с Gentoo на арчик, я таки запилил себе LiveUSB, взяв catalyst и разработки Gentoo Release Engineers. Понапихал туда кучку скриптов, сразу русифицировал, выставил vim вместо nano по дефолту, выставил более толковые опции для ssh, ntp (в т.ч. и выставив российские сервера времени в Пулковской обсерватории), … ещё кое чего. Достойненько получилось в общем.

Кроме того, свой оверлей уже есть и давно. Даже запилил несколько своих профилей, чтоб по eselect profile list можно было выбрать профиль с минимальным количеством ненужного кала и хлама.

Но не помогает и не поможет. Даже тотальный анализ исходников тоже не поможет. Во-первых, нет столько людей, во-вторых, нет столько денег. В третьих, ну разок пропатчил всё говно, дальше тоооолько отвернулся, херак, и ещё кода кривого, а то и с закладками нахерачат. И опять всё снова и заново. И не факт что нахерачат меньше, чем было. Я такое не осилю. Это просто 146%.

Тут один только выход – hardening системы. Как это сделано в той же hardened gentoo, чтоб было активированно SELinux и система собиралась бы с тулчейном, который с ASLR. Тогда система либо сама пришибёт корявое приложение, либо эксплоит сложнее приложить. Хотя бы какая-то гарантия есть. Ну и да, добавлю что сборку надо контролировать. И в т.ч. сборку ядра тоже, так что в «сонсоли попердолиться» придётся.

AstraLinux тоже не зря эту работу проделали для Special Edition. По-другому тут ни как.

Не совсем так.

У меня почему-то появилось ощущение, что ты безопасник.

«Безопасники», они тоже есть очень разные. Кто-то сидит, в танчеги шпилит, по временам рожая всякие докУменты.

А кто-то занимается проектированием/реализацией систем, на основе (в том числе) и требований к безопасности. И не факт что именно и только российских. Или софты всякие для всяких интересных дел пилит.

Но изначально я из русской армейской разведки. Технарь. Только это было крайне давно, настолько, что уже и неправда. =))) Теперь вот денег себе на свой достаточно высокий уровень жизни зарабатываю.