Шифрование памяти

[leo_sosnine]

Руссинович постит что вот-вот и будет шифрование памяти в Ажуре на базе интел SGX технологии:

In Azure, your data is your data. Not only is it protected at rest and in transit, but Microsoft Azure extends that protection while in use with confidential computing.
...
Today, we are announcing that Azure will be an early adopter of the 3rd generation Intel® Xeon® Platform, code named Ice Lake, which includes full memory encryption

https://azure.microsoft.com/blog/azure-and-intel-commit-to-delivering-next-generation-confidential-computing/

Здесь нужно отметить ряд следующих соображений:

- все многостраничные рассусоливания про шифрование данных в облаках на различных "траст энд прайваси" страничках всех облачных провайдеров и различных стастраничных документов по стратегиям входа в облака являются буллшитом, т.к. вне зависимости от того, как обрабатываются данные и как они шифруются, облачный провайдер имеет доступ к ключам шифрования;
- облачные провайдеры испытывают негласный прессинг от клиентов по этому поводу, иначе интел бы и не почесался с SGX;
- SGX это не более, чем схематоз уровня "шарик есть, шарика нет" для успокоения части указанных выше клиентов, т.к. облачный провайдер не сможет избавиться от доступа к ключам;
- облачные провайдеры, в частности АВС, имеют историю кидалова своих клиентов и имеются анти-траст судопроизводства в европе против них.

В любом случае, нужно помнить простую максиму: In the cloud, your data, if processed in any way, is not your data.

Comments

[ymarkov]

Я в этом деле профан, так что извините за глупые вопросы:

1. "облачный провайдер не сможет избавиться от доступа к ключам" — почему?

2. А можно качать/скачивать с того облака информацию, шифрованную клиентом?

[leo_sosnine]

1. А как? Вот, допустим, вы хотите в облаках процессировать данные. Допустим, в некотором массиве текста заменить слово "Соломон" на слово "Шломо". Процессор для этого подгружает файл с файловой системы в память. Если на файловой системе файл был зашифрован (а он был, т.к. иначе проблемы с комплайенсом против PCI DSS, HIPAA и проч.), то его нужно расшифровать. Для этого проц где-то берёт ключ (из key vault или юзер вводит на лету) и расшифровывает. Ключ в этот момент в памяти компа или регистрах.

Далее, для того, чтобы понять, что в загруженной из памяти строке написано "Соломон", а не крокозябры, процессор должен иметь доступ к строке в расшифрованном виде, иначе это будут крокозябры и проц никогда не сможет их идентифицировать и правильно заменить на "Шломо".

2. Это да, это безопасно. In the cloud, your data, if processed in any way, is not your data. Если данные просто хранятся и никак не обрабатываются, притом что зашифрованы они client-side и ключ никогда провайдеру не сообщается, то облачный провайдер, включая rogue employee, government surveillance и hacked provider сценарии, никогда данные прочитать не сможет.

[perdakot]

Далее, для того, чтобы понять, что в загруженной из памяти строке написано "Соломон", а не крокозябры, процессор должен иметь доступ к строке в расшифрованном виде, иначе это будут крокозябры и проц никогда не сможет их идентифицировать и правильно заменить на "Шломо".

Homomorphic encryption, но это в 100500 раз дороже чем обычно.

[ymarkov]

А, если там же и обрабатывать. Понял. У нас такого нет, только файлопомойка в облаке.

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

[rotbar]

Потому что любой(ое) что расшифровывает информацию- получает к ней доступ. Эрго: если операции выполняются не на вашем устройстве- всё зависит только от доброй воли хозяина.

Re: "облачный провайдер не сможет избавиться от доступа

[leo_sosnine]

Краткость сестра таланта!

[straktor]

Не совсем понял детали. Допустим, основная атака -- вытащить холодные планки памяти в азоте и снять дамп; решение -- проц на запуске генерит 1-разовый ключ, кладёт себе во внутренний регистр и все записи в шину идут через шифр. Тут не придерёшься, разве что криптоанализ относительно легко восстановит ключ по нолям и прочим известным данным (ключ не бесконечный -- значит циклический).

Второй вектор -- загружаемая ОС паленая, ранается сервис дампа памяти в сеть, прямо из ядра. Решается трастед загрузчиком... но это клиент должен каким-то боком обучить уефи своим публичным ключам и подписать им же ОС. И потом, кто гарантирует, что агенты не выпаяли микруху ME и не впаяли свою, которая грузит неподписанную.

"protected at rest and in transit" скорее означает "если хацкеры скрадут дампы с дисков, то без ключей не прочтут", нежели "полиция никак не сможет изъять и расшифровать екоммерс наркоторговли".

[leo_sosnine]

Основная атака это гипервизор без к-л следов или методов детекции снимает дамп памяти всей виртуалки или конкретного процесса в ней. Сейчас это всё плэйн текстом, со всей конфиденциальной информацией включая ключи. Про это никто нигде не заикается, т.к. конфуз.

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

[chaource]

Можно ли какъ-то противостоять такому методу взлома (дампу памяти, полученному черезъ гипервизоръ)? Скажемъ, кодъ можетъ быстро затирать ключъ изъ регистровъ процессора, или все время выполнять XOR со случайной маской, чтобы не давать ключу находиться долго въ памяти? Немедленно удалять изъ памяти расшифрованные куски, какъ только они обработаны и зашифрованы обратно? Производить шифрованiе разныхъ фрагментовъ данныхъ разными ключами, чтобы даже получивъ одинъ ключъ, можно было извлечь только небольшой расшифрованный фрагментъ данныхъ?

[leo_sosnine]

Это делать можно, но всё это будет проходить по категории obfuscation. Т.е., допустим, игрок предполагает что такой-то провайдер дампит память. Резонно предположить что провайдер делает это так-то и так-то. Что несложно, т.к. принцип экономии усилий работает везде и навряд ли провайдер пытается решать проблемы которые ещё не возникли в значимом количестве. Ну, например, дампы весят много, поэтому скорее всего делают дампы конкретных процессов из заранее согласованного списка. А что если мы переименуем процесс? Делают также скорее всего раз в эн тиков. Поэтому что если мы не будем хранить строчку в памяти, а сразу её затирать после использования? Ну и т.д. Поэтому можно играть в игру шарик есть, шарика нет.

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

Сравните со сценарием шифрования. Шифрование современными алгоритмами это практически гарант. Броня. Но он недоступен, если данные в облаках обрабатываются.

Это всё будет иметь и далеко идущие политические последствия. На сегодня Майкрософт (не говоря уже про Гугл и Амазон) это политический игрок и имеет историю подкладывания свиньи политическим противникам, например, история с gab.com, которые одно время там хостили картинки.

ЗЫ Ещё один вариант сильно осложнить жизнь шпиёнам это не использовать паравиртуализацию. Например, гонять в Ажуре неподдерживаемые операционки без драйвера паравиртуализации, в этом случае гипервизор не знает как сделать дамп памяти конкретного процесса и может делать только всю память целиком, а это дорого (правда, учитывая, насколько богат тот же Безос, а также насколько он разбогател за последний год, ему это может быть похуй). Цена -- всё будет дико тормозить и постоянные проблемы с поддержкой. Один хрен на своём железе выйдет дешевле.

[scif_yar]

>>в этом случае гипервизор не знает как сделать дамп памяти конкретного процесса и может делать только всю память целиком, а это дорого
-
чо?
вопрос объемов. разово то собрать 768 гигов - изи

[valerisha]

>На сегодня Майкрософт (не говоря уже про Гугл и Амазон) это политический игрок<

Ага, повторяется история с тамплиерами. Интересно, кто кого сборет в этот раз

[scif_yar]

>>Можно ли какъ-то противостоять такому методу взлома (дампу памяти, полученному черезъ гипервизоръ)? Скажемъ, кодъ можетъ быстро затирать ключъ изъ регистровъ процессора, или все время выполнять XOR со случайной маской, чтобы не давать ключу находиться долго въ памяти?
-
это все затратные операции, дающие не очевидные результаты.
так что хотите надежно - свой цод.

[chaource]

А что насчетъ собственнаго шифрованiя? Если я вообще въ облако кладу только изначально зашифрованные файлы, ключи даю только въ терминальной сессiи руками? Это безопасно?

[leo_sosnine]

Это безопасно. Использовать чисто как сторадж а шифровать на своей стороне своими ключами. Ключевая вещь здесь если данные not processed. Если они processed то так или иначе чужой процессор будет иметь доступ к незашифрованным данным.

[ircicq]

Бывает еще Homomorphic encryption
специально для процессинга без расшифровки

[leo_sosnine]

Там полным-полно ограничений на операции, щитай, с практической точки зрения оно не работает.

[euthanasepam]

Но поскольку не менее 95 процентов людей идиоты, облачное «хранение данных» будет процветать и впредь, хе-хе.

[rampitec]

Это вообще security through obscurity. Немного сложнее станет воровать данные, но не принципиально невозможно. Если данные появляются в памяти в расшифрованном виде хотя бы по частям, то это вектор атаки. И даже не только сам провайдер сможет их получить, но и как сейчас соседняя виртуалка через какой-нибудь Спектр.

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

[metaller]

+1

[metaller]

>> full memory encryption
Речь идёт о шифровании данных в RAM ? Если да, это LOL.

[metaller]

>> В любом случае, нужно помнить простую максиму: In the cloud, your data, if processed in any way, is not your data.

Очень правильно.

[metaller]

Годный пост. +1 !

[qvb]

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

Марк любит SGX, но скорее по маркетинговым причинам.
То что сейчас запустили гугли (используя железо от AMD) - в некоторых отношениях даже слабей SGX.

Реально если тебе дорога жизнь если важна безопасность, то надо ставить свои серверы причем в собственном датацентре.