Защита контента от хостера


В некоторых случаях возникает необходимость защиты контента сайта от нечистплотного хостера, например, не брезгующего плагиатом.
Особенно когда его моральные качества заранее неизвестны.
Конечно, можно хранить контент на отдельном зашифрованном диске, например, с файловой системой EncFS, CryptoFS и т.п.,
но разумеется, это еще не защита, поскольку хостеру не составит труда вставить LiveCD, загрузиться с него с получить доступ к контенту.

И вот простая идея, препятствующая его алчным намерениям – монтировать крипто-ФС не автоматически, в процессе загрузки ОС, а вручную, вводом пароля владельцем контента.
Разумеется, это несколько хлопотно, но учитывая высокий uptime серверов, не настолько уж.

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

Комментарии
— SATtva (31/08/2013 07:22)   
Не существует никакой физической возможности помешать противнику, имеющему физический доступ к компьютеру (а хостер по определению его имеет), извлечь шифровальный ключ непосредственно из ОЗУ. Ваша задача не имеет решения. Можно городить всякий security through obscurity, но это полумеры, только отсрочивающие взлом.
— unknown (31/08/2013 10:59)   
Остаётся только защитить хостера от наличия контента — самому стать хостером.
Гость (31/08/2013 21:25)   
/comment69681[link1] в этом топике тоже уместен, делаю кросслистинг.


Лучшая и простая идея — чтобы сервер хранил только зашифрованный контент, а его расшифрование проходило на компьютерах клиентов с помощью ключа, который они не передают на сервер. Хотя так и не рекомендуют[link2] делать, это (удалённые шифрованные файловые системы) всё равно лучше чем то, что вы предлагаете.

Бывают случаи, когда какой-то софт или ключи надо хранить на самом сервере, поэтому удалённые файловые системы не решают задачу. В этом случае могут применяться ряд уловок вида безопасность через неясность, которые хотя и неидеальны, но все вместе, в совокупности, очень сильно поднимают планку на взлом атакующим.
Гость (31/08/2013 22:32)   

И как же это делается – при помощи вспомогательных аппаратных устройств? Если да, то вряд ли хостер будет этим заморачиваться, если контент не столь ценен (скажем, оценивается в $5000 – $10000).


Если бы массовые клиенты имели массовый же софт для расшифрования – тогда да. А так, при условии, что в наличии у пользователей только голые браузеры – проблематично.
Вот если бы кто большой и важный написал кросс-браузерный плагин с такой функцией для всех браузеров – тогда да. Но увы, такого пока нет.
— SATtva (31/08/2013 22:49)   
И как же это делается – при помощи вспомогательных аппаратных устройств?

Программно.

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

http://openpgpjs.org/
Гость (31/08/2013 23:16)   

Гм. Как же это можно сделать программно, если после перезагрузки доступа к крипто-ФС без пароля не будет, а пароль к ней хранится на сервере в хешированном виде?


Можете прокомментировать проект, в том числе и степень доверия к нему, своими словами? А то мало что понятно..
Гость (31/08/2013 23:41)   

Будет. Кто сотрёт пароль из ОЗУ? Читаем внимательно[link3]. Хинты: live forensics, forenscope. Есть и масса аппаратных средств: «О методах получения доступа к шифрованным данным при наличии физического доступа к атакуемой системе»[link4].


Напомнило[link5].
Гость (31/08/2013 23:57)   
Вам нужен колокейшен. Покупаете свой физический сервер, снабжаете датчиком на вскрытие, опечатываете и ставите в датацентр. Сервер должен быть снабжен встроенным KVM для администрирования на случай недоступности ОС. Это единственный надежный способ.
— unknown (01/09/2013 00:37)   
Смотря что и от кого прятать. При самом параноидальном варианте можно допустить, что на колокейшене могут обвешать сервер кучей датчиков съёма данных (потребление энергии, электромагнитное излучение и пр.) по всем побочным каналам и сопоставлять их показания с трафиком (возможно адаптивно-модулированным). Так можно реконструировать ключи сертификатов и внутреннего шифрования диска сервера, после чего делать расшифрование дампов трафика, не вскрывая чёрный ящик.
Гость (01/09/2013 00:42)   
Любой датчик на вскрытие можно обойти, вопрос в стоимости.
Гость (01/09/2013 09:16)   
В любом современном ДЦ есть отдельные комнатки из решеток для самых требовательных клиентов. Клиент туда вешает замок, ставить своё видеонаблюдение и сигнализацию, сотрудники ДЦ не могут туда заходить. Внутрь заводится интернет и питание, а дальше клиент сам устанавливает все что ему надо, любое нестандартное оборудование. Правда там соответствующая цена и долгосрочные договоры.
— SATtva (01/09/2013 10:57)   
Короче, как всегда, безопасность — вопрос экономического компромисса.
Гость (01/09/2013 11:32)   

Kлиенту, которому хостинг нужно купить и обслуживать анонимно при том, что него спецслужбы охотятся, эта схема не подойдёт. Это крайний случай, как Сноуден или wikileaks, но он показателен.
Гость (01/09/2013 23:49)   
Не существует никакой физической возможности помешать противнику, имеющему физический доступ к компьютеру (а хостер по определению его имеет), извлечь шифровальный ключ непосредственно из ОЗУ. Ваша задача не имеет решения. Можно городить всякий security through obscurity, но это полумеры, только отсрочивающие взлом.


Есть лишь 1 способ, хранить и распрастронять контент зашифрованным, таким образом что клиенты сайта, зная пароль, получают информацию уже локально, скачав зашифрованный контейнер себе на машину.
Гость (18/10/2013 17:59)   
М-да, как все плёхо :( Да и колокейшн с амбарным замком не всегда подходит, дедики обычно берутся не поблизовсти, в дальних странах.
Гость (26/10/2013 00:54)   
Мдя... Особенно, если хостер такой нехорощий как WDF[link6]:

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

Ссылки
[link1] https://www.pgpru.com/comment69681

[link2] https://www.pgpru.com/faq/zaschitadiska#h42-14

[link3] https://www.pgpru.com/novosti/2011/amnesiaprogramnajazaschitaotatakholodnojjperezagruzki

[link4] https://www.pgpru.com/biblioteka/osnovy/fondpoleznyhpostov/raznoe#fppD2I

[link5] https://www.pgpru.com/forum/prakticheskajabezopasnostj/realizacijapgpalgoritmanajavascript

[link6] http://lenta.ru/news/2013/10/25/uploadertalk/