SATA шифрование

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

Это на самом деле часть стандарта ATA. Но такое впечатление, что часть всеми забытая.

Блокировка? Да. Шифрование? Сомневаюсь.

А встроенная функция совсем не добавляет накладных расходов?

http://vxlabs.com/2012/12/22/ssds-with-usable-built-in-hardware-based-full-di...

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

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

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

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

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

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

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

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

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

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

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

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

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

если у тебя процессор 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 раз.

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

Что за бред?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

анб же

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

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

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

анб же

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

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

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

Неудивительно, ведь оно именно на том самом говно-SandForce.

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

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

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

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

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

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

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

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

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

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

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

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

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

Как на любых?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

lmgtfy

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[...]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Your boat is ready, cap'n!

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

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

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

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

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

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

хм, ну может быть, да

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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