Помогите понять, как и зачем шифруются диски?

в убунту используется ecryptfs:

1. https://help.ubuntu.com/community/EncryptedPrivateDirectory 2. http://www.fsl.cs.sunysb.edu/docs/cryptfs/cryptfs.html

Какой же смысл тогда шифровать? Я не понимаю, как это защищает.

без входа в систему ты не прочтёшь данные с зашифрованного раздела

И ещё не могу понять как защищает шифрование трафика с открытыми ключами в SSH и https. Провайдер ведь в момент передачи ключа может снять данные, а значит и расшифровать всё остальное, разве нет?

нет

И ещё не могу понять как защищает шифрование трафика с открытыми ключами в SSH и https. Провайдер ведь в момент передачи ключа может снять данные, а значит и расшифровать всё остальное, разве нет?

В ОС зашит корневой сертификат, которым подписан сертификат сайта - это позволяет проверить подлинность сайта и зашифровать отправляемые данные.

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

Учите матчасть, и всё будет понятно.

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

Коротко: шифруется не весь диск, а отдельные файлы. Можешь заглянуть в каталог .Private они там. Эти файлы зашифрованы автоматически с генерированным клюём. Этот ключ шифруется уже паролем для учётной записи пользователя. Можно добавить несколько ключей, в так называемые слоты, которые смогут расшифровать пароль, которым зашифрованы файлы. Именно поэтому можно менять пароль.

Недавно ставил девушке Ubuntu, сделал шифрование данных, но так и не понял, как же оно работает?

Насколько я знаю, сейчас в убунте используется стековая критпо-ФС eCryptFS.

Но никакого ключа не спрашивается же при работе.

Ключ в кейринге, кейринг разлочивается при аутентификации в PAM. Подробностей не знаю, всегда пользовался dm-crypt (и всем рекомендую).

Если хочешь гарантированной надёжности, то используй dm-crypt и libpam-mount для прозрачного монтирования.

А тот ключ, который запрашивали, выходит, хранится где-то, так?

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

P.S. Кстати, а это шифрование сильно на производительность влияет? сильно замедляет работу или это даже не чувствуется?.. просто я нигде не шифруюсь, может, зря? :)

А зачем ты ставил шифрование, если даже малейшего понятия не имеешь, что это и как работает?

просто я нигде не шифруюсь, может, зря?

а у тебя есть что шифровать?

Кстати, а это шифрование сильно на производительность влияет?

Если не гонять непрерывно гигабайты данных, то даже на Atom не заметишь тормозов с обычными aes-cbc-essiv или aes-xts-plain(64). В новых процессорах ещё появились ускорители AES.

Да вот я читал раньше, но с наскока так и не понял, блин... Ладно, попробую ещё раз. Всем спасибо. Я просто наивно понадеялся, что вдруг кто-то очень простой парой фраз объяснит и я всё пойму :-)

То есть ты не понял моё предыдущее сообщение?

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

Я Security FAQ сейчас вдумчиво и тщательно прочту, надеюсь, придёт понимание.

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

вернее - файлы на зашифрованной области.

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

2. Данные можно шифровать на уровне файлов, можно на уровне раздела. В убунте на уровне файлов домашней папки. У каждого подхода есть и плюсы и минусы.

На самом деле все просто.

main in the middle, строго говоря, может.

main in the middle

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

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

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

И ещё не могу понять как защищает шифрование трафика с открытыми ключами в SSH и https. Провайдер ведь в момент передачи ключа может снять данные, а значит и расшифровать всё остальное, разве нет?

нет конечно. Это не «открытые ключи», а пара - открытый-закрытый. Причём закрытый(секретный) ключ НИКОГДА НИКУДА НЕ ПЕРЕДАЁТСЯ. Открытым ключом можно только зашифровать сообщение, а расшифровать его нельзя.

У нас есть открытый ключ сервера, мы создаём случайный пароль, шифруем его открытым ключом сервера, и отправляем его на сервер. И ТОЛЬКО сервер может этот пароль расшифровать. Таким образом, только мы и сервер знаем пароль к данным, которыми и меняемся.

Если провайдер перехватит наш трафик, то он этого пароля НЕ узнает. Ибо у него нет секретного ключа сервера.

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

какой на* сертификат?! нет никаких «сертификатов» в ssh, и не было никогда. Не путай с HTTPS, где сертификат нужен по той причине, что юзер не знает публичного ключа данного сайта, а значит не может ему доверять. По этой причине, нужна подпись некой третьей стороны, которой все доверяют. Подписанный третей стороной публичный ключ сайта как раз и называется сертификатом. К ssh это не имеет отношения, там нет третьей стороны.

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

ты бредишь. Серверу известен наш публичный ключ, и следовательно, мы можем доказать серверу, что мы - это мы. А не какой-то мужик посередине. Ибо никто кроме нас не может подписывать сообщения нашей ЭЦП (если конечно мужик посередине не знает наш секретный ключ).

Прикинь, я в теме, просто написал не так.
Но если у сервера сменится ключ, то тебе об этом напишет БОЛЬШИМИ БУКВАМИ и подключиться не даст.
Т.е попросит стереть старый открытый ключ в подтверждение того, что ты понимаешь что подключаешься хз куда.

думая что имеет дело с оригиналом.

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

И если я не ошибаюсь, то на всякие paypal и прочие вообще не покажет даже такой кнопки.
Т.е в браузерах зашиты их сертификаты как «особой важности», и потому при подсовывании не верного вывалится ещё более страшная страничка, но без кнопки.

Прикинь, я в теме, просто написал не так.

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

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

Какой еще провайдер, если речь о диске идет?

А я ничего не путаю.
Я про SSL говорил, где именно сертификаты.

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

ОП пост почитай.

речь про шифрование трафика по ssh/https

Какой еще провайдер, если речь о диске идет?

а ты посмотри, что я там процитировал. Могу повторить специально для тебя (:

И ещё не могу понять как защищает шифрование трафика с открытыми ключами в SSH и https. Провайдер ведь в момент передачи ключа может снять данные, а значит и расшифровать всё остальное, разве нет?

Гораздо пичальней читать просьбы расшифровать EFS после тог, как отформатировали DC & CA
Там у честных узеров продуктивные данные пропадают (да-да, бакапов разумеется нет!), а тут чё, ну ярлык к вконтакту пропадёт и пара роликов home video, не жалко.

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

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

И ещё не могу понять как защищает шифрование трафика с открытыми ключами в SSH и https. Провайдер ведь в момент передачи ключа может снять данные, а значит и расшифровать всё остальное, разве нет?

Для начала - man асимметричная криптология. Когда дойдешь до атаки man-at-the-middle, погугли что такое сертификаты.

ОМГ! Чтоб не путать неокрепшие умы - разъясню:

Если попроще, сертификат - это структура данных, содержащая идентификационную информацию, открытый ключ и некоторые другие поля, не относящиеся к криптографии (кому интересно - пусть погуглит наиболее распространенный формат X.509).

В https, как и других протоколах поверх ssl ключ сервера передается именно в сертификате, и на это есть весомые причины: 1) Доверенная сторона подписывает не просто ключ сервера, а совокупность его и индентификаторов сервера. Т.е. если изменить хотя бы одно поле сертификата, подпись не сойдется. 2) Так просто удобнее, не нужно городить велосипедов, в результате, один раз полученный сертификат должен попасть в общее хранилище ключей ОС и позволять создавать зашифрованные соединения с сервером разными приложениями по разным протоколам. К тому же, сервер может им подписать сертификаты дочерних сервисов, и они могут быть проверены клиентом на подлинность автоматически.

Реализация SSH смотрится как велосипед, если б не одно «но» - она старше действующих стандартов на этот счет. Принципы те же, хоть и упрощенные.

segfault

В https, как и других протоколах поверх ssl ключ сервера передается именно в сертификате, и на это есть весомые причины: 1) Доверенная сторона подписывает не просто ключ сервера, а совокупность его и индентификаторов сервера. Т.е. если изменить хотя бы одно поле сертификата, подпись не сойдется. 2) Так просто удобнее, не нужно городить велосипедов, в результате, один раз полученный сертификат должен попасть в общее хранилище ключей ОС и позволять создавать зашифрованные соединения с сервером разными приложениями по разным протоколам.

это всё не так уж и важно - основное отличие сертификата SSL от ключа SSH как раз и заключается в наличие третьей стороны, которой доверяют и сервер и клиент.

segfault

Реализация SSH смотрится как велосипед

нормально оно смотрится в тех случаях, когда мы не хотим/не можем найти доверенную третью сторону. К примеру в случае, когда мне нужно получить доступ к компьютеру жены. Зачем мне тут третья сторона? С другой стороны, если мы создаём публичный сервер, то мы будем _вынуждены_ приобрести сертификат, который заверен третьей стороной. Ибо иначе, новые клиенты будут получать грозные сообщения от браузера, о том, что сертификат не подписан. Хомячки будут в панике.

Если так угодно, то в SSH третья «доверенная» сторона - это пользователь. А вместо подписи - просто ввод «yes», вместо криптографии - права на файлик с ключами, ибо ничего более секьюрного в этом случае не нужно.

Подписанный сертификат у сервера решает эту проблему.

не просто йес, а проверка отпечатков сервера. А если прав мало - шифруем ключ парофразой

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

а значит и расшифровать всё остальное

нет, читайте основы криптографии, в частности public и private key

троян может добавить свой серт, и отправить юзера на свой сервер

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

segfault

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

в Linux это будет затруднительно сделать - прав не хватит, что-бы браузер заменить. Вроде в венде с этим теперь тоже строго. А вот добавить сертификат таки можно. Да и юзер считает, что если он со «своим банком» установил «безопасное соединение», то это действительно его банк, и соединение безопасное. Хотя конечно в принципе к криптографии это относится действительно косвенно.

в Linux это будет затруднительно сделать

Заменяем ярлык на фокс/оперу/хром на левое приложение из домашней директории - и в большинстве случаев прокатит. Разве что пользователь будет его из консоли запускать...

Разве что пользователь будет его из консоли запускать...

Это не проблема, просто чуть больше движений.

segfault

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

нет. Если вы получили удалённый доступ к компьютеру друга с правами друга - прокатит безусловно. Вы же знаете, что у друга KDE 4.8.1, вы знает, где у него ~/Desktop (а не ~/Рабочий стол), вы знаете, что у него opera.desktop ярлычок, и вы знаете, что вполне можно набросать простейший скрипт в ~/tmp (ибо в Slackware есть такой каталог, а значит есть и у друга), обёртку над оперой, которая известно где лежит (у друга). Проблема в том, что у трояна нет друзей. Доступ есть, а друзей - нет. И куда он попал - хрен его знает. Причём вариантов Over9000. Разобраться в этом очень затруднительно, а на практике - практически невозможно. Т.е. проблема вирусмейкера в том, что друга-то он своего затроянит, но вот дальше... Однако, в проприентарных ОС такой проблемы нет в принципе, практически все системы ничем не отличаются. Даже если вы поставите KDE в венду, это будет всего-лишь надстройка над Explorer.exe, и это никак не помешает работе вирусов/троянов, которые заточены под Explorer.exe, в отличие от Linux, в котором KDE это именно DE, и есть оно далеко не у всех. И даже у тех, у кого оно есть, оно очень сильно разнится по своему составу.

UnSavant