LINUX.ORG.RU

SATA шифрование

 , ,


0

1

А есть кто-нибудь, кто использует встроенное шифрование SSD? Мой Intel 530, как пишут в спецификации, поддерживает шифрование, но никакой документации по этому поводу нет. Я предполагаю это должно работать так:

1. Устанавливаю пароль через hdparm --security-set-pass

2. Пишу initrd-hook, который будет запрашивать пароль при загрузке и разблокирует ssd вызовом hdparm --security-unlock

3. Дальше линукс работает как обычно до следующей перезагрузки.

Вроде все просто, какие могут быть подводные камни (типа неполной поддержки SATA Security в linux)?

Почему не LUKS: потому, что если использовать LUKS, встроенная функция сжатия данных того же SSD идет лесом (а SSD у меня ради скорости работы и жертвовать её я не хочу).


Ответ на: комментарий от Gotf

Пусть даже без шифрования. Кто сможет считать данные, если интерфейс заблокирован? Правильно — только тот, у кого есть инструменты для прямого чтения из массива флеш-памяти.

Вероятность возникновения необходимости защититься от такого «противника» предлагаю оценить самостоятельно.

intelfx ★★★★★
()

1. Нет оснований доверять этому шифрованию, у всяких органов может остаться доступ.

2. Повышается вероятность превратить диск в тыкву и самому оттуда ничего не достать.

anonymous
()
Ответ на: комментарий от intelfx

Вероятность возникновения необходимости защититься от такого «противника» предлагаю оценить самостоятельно.

В гугле пишут, что пароль извлечь не проблема.

Gotf ★★★
()

а SSD у меня ради скорости работы и жертвовать её я не хочу

если у тебя процессор Intel современненький (то бишь с аппаратным AES) — то LUKS прям сам(!) просится поставиться к тебе на компьютер :-) ..

встроенная функция сжатия данных того же SSD идет лесом

ды брось, неужели этим маркетинговым приёмом можно хоть кого-то заманить?

это же просто накопитель, а не волшебная коробочка :-)

user_id_68054 ★★★★★
()
Ответ на: комментарий от user_id_68054

если у тебя процессор Intel современненький

Еще бы, 2.5 GB/s выдает. Файлопомойка на HDD зашифрована.

ды брось, неужели этим маркетинговым приёмом можно хоть кого-то заманить?

Очень легко проверяется:

$ dd if=/dev/zero of=test bs=1M count=1000
$ dd if=/dev/urandom of=test2 bs=1M count=1000
$ dd if=test2 of=~/tmp/test2 oflag=direct bs=1M 
1000+0 записей получено
1000+0 записей отправлено
 скопировано 1048576000 байт (1,0 GB), 7,88968 c, 133 MB/c
$ dd if=test of=~/tmp/test oflag=direct bs=1M 
1000+0 записей получено
1000+0 записей отправлено
 скопировано 1048576000 байт (1,0 GB), 2,46541 c, 425 MB/c
$ dd if=4 of=~/tmp/test3 oflag=direct bs=1M 
1024+0 записей получено
1024+0 записей отправлено
 скопировано 1073741824 байта (1,1 GB), 4,64915 c, 231 MB/c

test3 — это pdf'ка клонированная 100500 раз.

crowbar
() автор топика
Ответ на: комментарий от intelfx

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

И? Я знаю только один контроллер, который читит со сжиманием, и он печально известен и другими дефектами.

unanimous ★★★★★
()
Ответ на: комментарий от crowbar

эээээээ... как сказать, то есть реальная скорость: 133 MB/c ..

а 231 и 425 — ну это же хак :) .. мне лично было бы стрёмно ощущать присутствие этого хака :-).

а это — включено по умолчанию или вручную через какой-нибудь hdparm ? (а отключить — можно? :))

user_id_68054 ★★★★★
()
Ответ на: комментарий от unanimous

ТС имеет в виду именно такие контроллеры. Считать это фичей или дефектом — дело каждого, наверное.

intelfx ★★★★★
()
Ответ на: комментарий от user_id_68054

На чтении результаты ближе — 390 и 420.

а это — включено по умолчанию или вручную через какой-нибудь hdparm ? (а отключить — можно? :))

По умолчанию.

crowbar
() автор топика
Ответ на: комментарий от unanimous

Сжатие у Intel 530 — заявленная фича.

// offtop: Посмотрел цены — в два раза дороже сейчас по сравнению с осенью

crowbar
() автор топика
Ответ на: комментарий от crowbar

> ды брось, неужели этим маркетинговым приёмом можно хоть кого-то заманить?

Очень легко проверяется:
[...]

самое главное-то я и забыл сказать! :)

да! разумеется это маркетинговый приём. конечно! и разумеется на это мало кто ведётся :-) ..

те кому нужно сжатие — просто делают сжатие в файловой системе. (и могут выбирать его разные режимы: «дешёвое» сжатие или более «дорогое»).

да, апаратная встроенная функция «сжатия» в SSD позволяла бы сделать «сжатие» — вообще «бесплатным»! но ведь и выбора ни какого она не предоставляет. и экономии пространства тоже ни какого нет — «сжатие» без сжатия (без экономии пространства) — нонсенс!

а при этом стоит отметить что даже на Windows есть функция сжатия в NTFS. а пользователи Linux уж темболее не обделены. и про Zswap тоже вспомним.

однако! хочу сказать что — что касается мелких файлов — не так важна скорость их чтения, как скорость реакции на операцию чтения. SSD делает это быстро (не зависимо от наличия или отсутствия сжатия).

(если у тебя операционная ситсема уже грузится за 2~3 секунды.. то как ещё ты хотел бы оптимизировать работу с мелкими файлами? сделать загрузку за 1.0~1.5 секунды? :-))

а что касается больших файлов — то как правило это УЖЕ либо архивы, либо медиафайлы. и сжатие на уровне накопителя-или-файловой-системы тут только лишняя абуза.

user_id_68054 ★★★★★
()
Последнее исправление: user_id_68054 (всего исправлений: 1)
Ответ на: комментарий от user_id_68054

с аппаратным AES

анб же

LUKS прям сам(!) просится поставиться к тебе на компьютер

конечно, тк см выше

anonymous
()
Ответ на: комментарий от anonymous

> с аппаратным AES

анб же

а что АНБ ? если предположить что все ключи AES-шифрования куда-то сохраняются — то где же такое пространство найти куда это будет записываться? :-)

допустим, на каждый сектор SSD — по два AES-ключа. (или как-то так.. точно не помню алгоритм XTS). довольно много ключей нужно было бы сохранить :-)

user_id_68054 ★★★★★
()
Ответ на: комментарий от unanimous

А другие SSD дают по 500 Мб/с независимо от типа данных?

на том самом говно-SandForce

SandForce SF-2281 А чего за «другие дефекты»? У меня никаких проблем не было, хотя комп я использую по-жесткому, с кернел-паниками и хард-ресетами.

crowbar
() автор топика
Последнее исправление: crowbar (всего исправлений: 1)

С шифрованием дисков всё далеко не так просто! И слив TrueCrypt, как бы об этом прямо говорит.

Коротко: а) негде хранить IV; б) негде хранить MAC.

В первом случае приходится очень стильно выёживаться чтобы не заполучить атаку на внедрение водяных знаков. Т.е. при наивном методе шифрования можно спокойно доказать наличие ЦП на разделе, не прибегая к паяльнику; даже расшифровывать не нужно.

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

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

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

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

И уж точно не стоит использовать потребительские шифровальные системы о которых вообще ничего не известно!

Macil ★★★★★
()
Ответ на: комментарий от crowbar

500 Мб/с независимо от типа данных

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

xdimquax ★★★★
()
Ответ на: комментарий от xdimquax

Как на любых?

В том вопросе акцент на второй части предложения, а не на слове «дают». Мне интересно, бывают ли SSD, которые дают честные 500 мб/c.

Я сейчас просмотрел описания нескольких SSD, у всех заявленные скорости 400-500 мб/с с дополнениями типа «for quick bootup» или «Передача сжимаемых данных».

crowbar
() автор топика
Последнее исправление: crowbar (всего исправлений: 1)
Ответ на: комментарий от crowbar

Мне интересно, бывают ли SSD, которые дают честные 500 мб/c.

Странно, что ты о них не знаешь. Вот хотя бы Samsung 840/850 Pro.

unanimous ★★★★★
()
Ответ на: комментарий от crowbar

Я сейчас просмотрел описания нескольких SSD, у всех заявленные скорости 400-500 мб/с с дополнениями типа

Как-там оно в 2009-то? Будешь возвращаться, долларов прикупи!

unanimous ★★★★★
()

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

у меня на asus 1215n появилась установка пароля в bios, после того как воткнул ssd ocz vertex 4 (и это не пароль на загрузку).

Black_Roland ★★★★
()
Последнее исправление: Black_Roland (всего исправлений: 1)

кто использует встроенное шифрование SSD?

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

потому, что если использовать LUKS, встроенная функция сжатия данных того же SSD идет лесом (а SSD у меня ради скорости работы и жертвовать её я не хочу).

т.е. ты хочешь и рыбку съесть и на*й сесть? У меня для тебя плохие новости: конечно производитель пойдёт тебе навстречу, и сделает кнопку «сделать пиз^Wхорошо», но вот только я сомневаюсь, что это «хорошо» будет _действительно_ работать.

emulek
()
Ответ на: комментарий от intelfx

Кто сможет считать данные, если интерфейс заблокирован?

http://lmgtfy.com/?q=AWARD_SW

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

это если мастер-пароля не существует. Уж поверь, ZOG этого не допустит.

emulek
()
Ответ на: комментарий от anonymous

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

ты идиот? Куда он его _передаст_??

emulek
()
Ответ на: комментарий от emulek

lmgtfy

Я прекрасно знаю, что такое мастер-пароль, утихомирь уже своё ЧСВ. Только вот вероятность, что adversary таковым располагает, весьма низка (см. третье предложение моего сообщения).

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Я прекрасно знаю, что такое мастер-пароль, утихомирь уже своё ЧСВ.

да? Странно. А из твоего поста следует, что, цитирую:

Кто сможет считать данные, если интерфейс заблокирован? Правильно — только тот, у кого есть инструменты для прямого чтения из массива флеш-памяти.

(выделение моё, но тебя за язык никто не тянул). Очевидно, про мастер пароли, если ты и знал, то забыл.

Только вот вероятность, что adversary таковым располагает, весьма низка (см. третье предложение моего сообщения).

наивно верить в то, что эти мастер-пароли не утекут в интернет, на всякие «хакерские» сайты. Даже если вот прямо сейчас про конкретно твой девайс ничего и нет, то это ни о чём не говорит, ну кроме того, что по понятным причинам adversary этого не афиширует. Если ты не знал, то всякие маргинальные «хакерские» ресурсы не любят гугло-ботов, и эта нелюбовь взаимна. Потому такие вещи плохо гугляться, но кому надо, тот найдёт. Лично я прекрасно помню время, когда AWARD_SW не гуглился(гугла-то не было), и тем не менее, я об этом прекрасно знал. Да и не я один, а почти любой эникейщик, не считая совсем уж тупоголовых.

И да, я ещё раз выражаю сомнение, что всякие АНБ, ЦРУ, ФСК, и т.д. и т.п. буду рады отсутствию простого и быстрого доступа к данным преступников. А данные преступников ВНЕЗАПНО хранятся на точно таких же SSD, как и у тебя и у меня. Was wissen zwei, wisst Schwein, такие дела…

emulek
()
Ответ на: комментарий от user_id_68054

довольно много

не очень, сотня мегабайт на тебабайты

anonymous
()
Ответ на: комментарий от crowbar

Лучше смотреть не описания, а обзоры конкретных моделей с контролёрами, отличными от SandForce. Ну, там Marvell, Phison, JMicron, Silicon Motion и т.д. К сожалению, я не в курсе как у них обстоят дела с этим. Возможно, любой SSD лучше не шифровать (полностью, во всяком случае), если ещё есть HDD и все важные данные хранятся на нём.

xdimquax ★★★★
()

Не надо использовать FDE.

«Однако, рекомендовать подобные решения нельзя. К сожалению, практически все производители умалчивают о конкретной реализации режимов шифрования внутри их накопителей, а в реализациях, про которые хоть что-то известно, используется простой CBC режим с публичным вектором инициализации. Данная схема подвержена множеству атак.»

Deleted
()
Ответ на: комментарий от user_id_68054

если предположить что все ключи AES-шифрования куда-то сохраняются — то где же такое пространство найти куда это будет записываться?

штеуд планирует сделать wifi прямо на кристалле, и он же продвигает так называемый «интернет вещей»

anonymous
()
Ответ на: комментарий от Macil

приходится очень стильно выёживаться чтобы не заполучить
атаку на внедрение водяных знаков. Т.е. при наивном методе
шифрования можно спокойно доказать наличие ЦП на разделе,
не прибегая к паяльнику; даже расшифровывать не нужно.

да, поэтому и придумали XTS

Можно проводить replay-атаки, т.е. сбросить содержимое
сектора в предыдущее состояние, и атаки на рандомизацию
содержимого произвольного сектора.

[...]

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

... ...или пока файловая система не научится создавать\использовать контрольные суммы на записываемые экстенты с данными.. (спасёт от Рандомизации.. а от Релея думаю ни чего не спасёт :))

ой, погодите, тыг ведь уже!

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

user_id_68054 ★★★★★
()
Последнее исправление: user_id_68054 (всего исправлений: 2)
Ответ на: комментарий от Macil

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

Выёживаться нужно для того, чтобы дать возможность провести такую атаку. Уже хрен знает сколько лет по умолчанию почти везде используются CBC-essiv или XTS, которые не подвержены watermarking. Сможете внедрить водяной знак — пишите статью в научный журнал, а не на форум. CBC-essiv подвержен немного похожей атаке: зная открытый текст, можно подменить часть блоков на то, что нужно атакующему. Но, во-первых, каждый второй блок будет состоять из мусора, во-вторых, сейчас везде уже XTS используют, а он этой атаке не подвержен. У XTS есть небольшие проблемы, если одним ключом шифровать терабайты, но для не слишком больших объемов он вполне надежен.

И решения как такового нет.

Как вам там в 2007 году живётся? А у нас вот XTS придумали...

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

И чем это «ещё хуже»? В каких случаях это критично?

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

Какой толк в большом размере блока, как это поможет решить указанные вами проблемы? В 512-битном блоке смысл есть, но отнюдь не по тем причинам, что вы указали, здесь он бессилен. Очень хочется — у нас в 2015 и Threefish имеется с килобитным блоком.

Метаданные отдельно на каждый сектор — откровенно бредовая идея, ничего не мешает хранить их там же, где и сами данные, было бы желание.

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

Your boat is ready, cap'n!

anonymous
()
Ответ на: комментарий от crowbar

Мне интересно, бывают ли SSD, которые дают честные 500 мб/c.

очень надеюсь что журналисты технических журналов\блогов, когда занимаются тестированием скорости — делают это с несжимаемыми данными.

несжимаемых данных большого размера — пруд пруди: фильмы, музыка, /dev/urandom, архивы-исходников (tar.gz), GIT-репозитории (уже сжаты), и т д.

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

user_id_68054 ★★★★★
()
Последнее исправление: user_id_68054 (всего исправлений: 1)
Ответ на: комментарий от user_id_68054

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

На винде есть такая вещь, как современные игры…

Gotf ★★★
()
Ответ на: комментарий от anonymous

Как вам там в 2007 году живётся?

Я в курсе, не волнуйся. И про ESSIV, и про LRW/XEX/XTS, и про EME.

Проблема в том, что шифрование дисков — достаточно маргинальное направление криптографии. А это *всегда* плохо. Более того, попираются две священные коровы: IV и MAC, что фактически — ересь.

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

В каких случаях это критично?

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

Я не утверждаю, что TC или LUKS чему-то там подвержены. Я лишь утверждаю, что всё не так просто. Очень непросто! И призывают подумать прежде чем бездумно врубать дисковое шифрование.

Macil ★★★★★
()
Ответ на: комментарий от Macil

Проблема в том, что шифрование дисков — достаточно маргинальное направление криптографии. А это *всегда* плохо. Более того, попираются две священные коровы: IV и MAC, что фактически — ересь.

Простите, это бред от начала до конца. Маргинальным направлением можно шифрование на уровне ФС назвать, которое так вам симпатично, вот это да. Шифрование дисков же — ни разу не маргинальное направление, а одно из основных, если не основное, приложение симметричного шифрования. Дисковое шифрование активно изучается учеными всего мира, ему посвящена значительная доля научных работ по криптографии. Да, их большинство сосредоточено на «голых» шифрах, а не их применении, но это никак не бросает тень на практические криптографические средства. Зачем иначе вообще нужна криптография?

IV — не священная корова. Это всего лишь костыль, позволяющий шифровать много блоков одним ключом. Если уж боритесь за чистоту крипто, боритесь до конца: только шифр Вернама является единственным безупречным средством, всё остальное без исключения — «разумный набор компромиссов», как вы сами выразились. И в этом нет ничего плохого.

Все исходят из того что IV непредсказуем, в дисковом шифровании — предсказуем.

Он вполне непредсказуем, если мы об essiv говорим. В XTS IV не используется.

MAC — лишь средство, а не самоцель. Он используется там, где необходим, и его отсутствие ни в коем случае не превращает систему шифрования во что-то второсортное. Есть тысяча способов контроля целостности и в каждом конкретном случае можно подобрать что-то подходящее, не занимаясь такими несусветными глупостями, как выделение дополнительных спец. объемов на носителях для хранения метаданных.

Решает либо хранение IV и MAC, либо двойное шифрование

Вместо того, чтобы хранить IV, лучше тогда хранить отдельный ключ на каждый блок, вот это решение. Только тогда лучше уж по Вернаму шифровать, быстрее. Хранение IV, лол.

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

Да вот именно тем что хрен знает в каких именно случаях это критично! Откат на уязвимые версии программ, откат на скомпрометированные ключи, атаки на отказ от обслуживания.

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

Я лишь утверждаю, что всё не так просто. Очень непросто! И призывают подумать прежде чем бездумно врубать дисковое шифрование.

Знай свои инструменты, их сильные и слабые стороны, и умей с ними работать, да. Но это касается абсолютно всего, не только крипто. Вы же предлагете в сто раз более уязвимую по сравнению с дисковым XTS альтернативу в виде сырых и не слишком обкатанных средств шифрования на уровне ФС, хотя сама идея такого шифрования имеет очевидные и очень весомые минусы.

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

anonymous
()
12 июля 2016 г.

А в России такое шифрование разрешено?

Deathstalker ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.