РегистрацияШифрование данных в облаке
Думаю, многим нужно облачное хранилище для документов и прочих подобных вещей, которые должны быть криптографически защищены от посторонних глаз (админов сервиса, государственных агентств и прочих доброжелателей). При этом важно удобство использования. Понятно, что канонический способ с заливкой каждый раз нового криптоконтейнера наиболее надёжен, но в повседневном использовании это крайне непрактично — хотелось бы чего-то прозрачного и фонового а-ля дропбокс. Также хорошо бы иметь возможность доступа как с компьютера, так и с мобильного устройства (для меня актуальны Windows и Android).
Хочу поделиться результатами гугления, а также попросить комментариев и советов присутствующих — может, кто-то предложит ещё какие-то варианты.
Насколько я понимаю, способов достичь желаемого два:
1. использовать сервис со встроенной криптографией;
2. пользоваться любым сервисом в связке с EncFS либо аналогом.
Сервисы с криптографией
Есть несколько сервисов, которые, как они сами утверждают, шифруют данные так, что сами не могут получить к ним доступ. Все их объединяет одно: закрытый код клиентов, что не позволяет проверить правдивость утверждений. По-хорошему, на этом можно бы и закончить разговор, но для справедливости всё-таки разберём, что нам (на словах) предлагается.
Является сервисом бэкапов, поэтому не очень понятно, насколько удобно использовать как полноценное облачное хранилище, хотя клиенты под мобильные устройства имеются. Используется (почему-то) Blowfish с длиной ключа до 448 бит. Есть режим, при котором используется пользовательский ключ шифрования. В документации прямо утверждается, что он никуда не передаётся и нигде не хранится, что, вероятно, означает шифрование на стороне клиента.
Позиционирует себя как криптографический аналог DropBox, постоянно подчёркивает, что все данные надёжнейше защищены даже от админов. Используется AES-256 В документации утверждается, что шифрование происходит на клиентской стороне, хотя ключ шифрования хранится в зашифрованном виде на сервере. Исключение — доступ с мобильных устройств, тогда шифрование происходит на серверной стороне, что является серьёзным недостатком. Утверждается, что шифртекст представляет собой нумерованные блоки (что лучше, чем пофайловое шифрование в других сервисах).
Утверждает на главной странице, что все данные шифруются на стороне клиента. Использует AES-128 и RSA-2048. Криптография основана на собственной научной работе Cryptree. Каждый файл шифруется своим ключом, и список ключей хранится в зашифрованном виде на сервере.
EncFS или аналог
На мой взгляд, лучший способ: при правильном использовании довольно гибок и удобен в использовании почти так же, как облачные сервисы без защиты. Плюс: есть варианты с открытым кодом. Минусы: шифрование происходит либо пофайлово (тогда видна структура и размеры файлов и папок), либо поблочно (открывается простор для криптоанализа). Однако, похоже, от такого трейд-оффа между удобством и надёжностью никуда не деться.
Некоторые кладут в синхронизируемую с облаком папку TrueCrypt-овый контейнер. Облачные клиенты обычно достаточно умны, чтобы заливать только изменившиеся его части, но для этого контейнер придётся отмонтировывать: моментального сохранения изменений не происходит.
Оптимальным мне видится использование EncFS, который имеет порты как под Windows (свободный encfs4win и закрытый BoxCryptor), так и под Android (свободный cryptonite, который умеет и TrueCrypt и опять же закрытый BoxCryptor).
комментариев: 9796 документов: 488 редакций: 5664
Можно согласиться насчёт EncFS как оптимального решения из того, что есть.
Если параноить на теоретическом уровне, то нужна разработка специальных режимов шифрования, предназначенных для облачных сервисов. Возможно, потребуются более продвинутые аналоги вариантов режимов дискового шифрования, возможно потребуются специальные протоколы.
Конкретных сведений про уязвимости обычных режимов шифрования в такой ситуации пока нет, но будет неудивительно, если завтра опубликуют гипотетическую атаку вида "доказательство существования специально сформированного и подброшенного пользователю открытого текста без знания ключа на основе тайминг-анализа при перешифровке данных в процессе перемещения между двумя злонамеренно сотрудничающими облачными сервисами" или ещё какое-нибудь подобное бла-бла-бла.
комментариев: 11558 документов: 1036 редакций: 4118
Что характерно, сам Dropbox когда-то утверждал то же самое.
За год ничего для Windows не поменялось, я полагаю?
У свободного encfs4win есть одна проблема – он использует некую Dokan library, которая не обновляется с 2011. Она имеет известные и не очень конфликты
со всем, а т.к. Dokan – это ядерный драйвер, то большая часть ошибок приводит к bsod (часть из них репродуцируются). При этом, как выяснилось, иногда портятся данные.BoxCryptor закрыт, что уже плохо, но если целью ставить защиту данных от недобросовестных сотрудников dropbox, то вполне себе.
Если создать большой контейнер TrueCrypt, то он, действительно, синхронизуется частями по 4mb и весь контейнер не перекачивается, но при изменении timestamp требуется переиндексировать весь контейнер – у меня на i5 2.4ghz 18гб переиндексируются примерно за 20 мин (здесь еще HDD может лимитировать, да и читать 18гб каждый раз при изменении 1 бита моветон). И да, контейнер надо отмонтировать, поэтому сразу данные в облако не прогрузятся (например, если хочется сразу бэкапить, как было по задумке dropbox).
Других портов криптоFS я не встречал.
Кстати, с encfs4win у меня обнаружился забавный баг – проводник windows не правильно определяет размер папки с encfs: считает, что данные занимают на диске меньше, чем в реальности. Фиг бы с ним, но dropbox считает точно также (не клиент, а именно сам сервис, то есть можно загрузить больше, чем доступно места).
"Your crypto passphrase is used to encrypt your data before it is sent to our servers."
Шифрование на стороне пользователя (?) только паролем? Не углядел про алгоритм шифрования. Не универсальное решение.
комментариев: 11558 документов: 1036 редакций: 4118
Анону не угодишь. Анон может аргументировать, что
Дальше не читал.
P.S. Исходники клиента как всегда закрытые?
Дегенераты не читают. Умные люди читают, и видят что там предлагают две схемы, в одной из которых ключ находится на стороне клиента.
И да, как всегда закрытые, и там есть закладки для АНБ. Потому что АНБ интересуют именно данные дегенератов, которые читать не умеют. А данные крупных компаний, которые пользуются услугами одного из крупнейших игроков на рынке облачных услуг – им не интересны.
комментариев: 1060 документов: 16 редакций: 32
А где это вы там узрели хранение ключа у клиента? Я почему-то вижу только дополнительный пароль, который нужно послать серверу, чтобы тот смог расшифровать секретный ключ.
Ищите глубже.
комментариев: 1060 документов: 16 редакций: 32
Хм. Я как-то надеялся на конструктивное указание конкретного места, а не на завуалированный посыл на три буквы. Оставим это на Вашей совести, а пока продолжаем считать, что хранения недепонированного ключа на стороне клиента там нет – вплоть до конструктивного доказательства обратного. :)
Сервис как хранилище, впрочем, вроде вполне неплох. Если поверх этого прикрутить шифрование на стороне клиента(ecryptfs, encfs), я думаю, можно пользоваться (как и любым другим).
комментариев: 301 документов: 8 редакций: 4
Пишут, что он остановил свой выбор на SpiderOak.