Так же исходя вот из этого:

FileVault 2 offers full-disk encryption (FDE). When enabled, the entire contents of the startup drive are encrypted. When your computer is powered off, the drive’s data is fully unrecoverable without a password. It also lets you use Find My Mac to wipe your drive in a matter of seconds remotely if you’re concerned about into whose hands your computer has fallen

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

Всё может быть гораздо проще. У Эппл просто есть удаленно-активируемый код, стирающий заголовок криптоконтейнера (раздела). После такой затирки расшифровать уже ничего не удастся — скорее всего в заголовке находится «соль» — случайный вектор инициализации.

Apple может получить доступ к этим данным, раз есть возможность удалённого стирания диска.

Это я знаю, поэтому хочу слезть с макос

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

AFAIK, можно просто взять pam_exec и скормить ему любую команду. Но отдельный модуль для ext4 вроде тоже есть.

В /bin, /usr/bin - те же самые файлы, что у тебя, у Блиц и Линус Торвальдса.

Какой смысл их шифровать, ответь сам себе?
/home - нужно шифровать с dm-crypto.

Тогда вводи пароль от учётки. В этом случае шифрование будет только /home. Все твои данные хранятся только в хомяке. Если параноишь по кэшам и вот этому вот всему, тогда только полнодисковое шифрование.

В-третьих, партицию /home, вынеси на отдельный девайс - и шифруй с LUKS. Это твоё личное.

Все остальные партиции - не стоят шифрования.

Если нужно обеспечить конфиденциальность личных данных, то разве /var/log /var/tmp и /tmp не стоят шифрования? Даже в /etc могут быть какие-то интересные вещи.

Все ключи хранятся в процессоре потому что AES. Veracrypt позволяет шифровать тремя разными шифрами одновременно.

Что за бред?!

то разве /var/log /var/tmp и /tmp не стоят шифрования? Даже в /etc могут быть какие-то интересные вещи.

Таки да, на серверах отыщутся весьма интересные вещи.
На обычных компах - совсем ничего нет интересного за подсмотреть.

Где конкретно бред?

Какие это ключи AES хранятся в процессоре?

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

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

AES - это алгоритм, процессоры, поддерживающие этот набор инструкций, частично его реализуют аппаратно

И могут хранить AES ключи в своей памяти.

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

И могут хранить AES ключи в своей памяти.

А внутри процессора вообще есть nvram для таких дел? Хотелось бы пруфцов на это, потому что вообще первый раз слышу об этом.

Ты процессор с TPM не перепутал?

Ты процессор с TPM не перепутал?

Нет, если аппаратное ускорение AES включено, то пароли хранятся внутри процессора. Пруфы в интернете.

Анонимус неодобряет

Нет, если аппаратное ускорение AES включено, то пароли хранятся внутри процессора.

Они там «хранятся», даже если аппаратное ускорение AES выключено. Потому что, блджад, процессору для шифрования нужны ключи и аппаратное ускорение тут абсолютно побоку.

Нет, если аппаратное ускорение AES включено, то пароли хранятся внутри процессора.

Вот прям таки и хранятся, даже после выключения питания? И сколько паролей?

Пруфы в интернете.

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

Вот прям таки и хранятся, даже после выключения питания? И сколько паролей?

Да, и познакомь себе с BIOS компьютеров business class.
Ключи хранятся (вероятно в nvram) и есть опции - anti-tampering.

Мы собственно о чем говорим, об обычном софте для Linux, использующем aes (dm-crypt, vrаcrypt) или уже о чем-то еще?

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

Был в свое время срач с участием самого Линуса Торвальдса по поводу использования ГСЧ, он в итоге оставил его использование в ядре, сказав примерно что как дополнительный источник энтропии в плюс имеющимся, даже если там, что-то нечисто с ним, он не ухудшит свойства. А уж если бы ключи принудительно сохранялись это был бы куда более жесткий срач на выпиливание использования aes-ni, но ничего такого.

Неужели трудно дать url?

и есть опции - anti-tampering

Опции для чего? Для процессора и чипсета, так и так они делаются немодифицируемыми пользователем. У другого софта, что-то не находятся.

Опции для чего? Для процессора и чипсета, так и так они делаются немодифицируемыми пользователем. У другого софта, что-то не находятся.

Когда в следующий раз загляну в BIOS, сделаю фото-скрин с двух страниц - админ и безопасности.

Не по памяти же всё рассказывать ))

Когда в следующий раз загляну в BIOS, сделаю фото-скрин с двух страниц - админ и безопасности.

Не по памяти же всё рассказывать ))

Снова вопрос, о чем собственно идет речь? У некоторых компьютеров (материнок, bios) есть поддержка полнодискового шифрования с AES с использованием модуля TPM. Соответственно, где-то в защищеннной области хранятся ключи в nvram. Что такая возможность есть я и не спорю. Для этого есть и настройки в bios, ничего нового.

Но анонимус, как я понял, заговорил о недокументированном, злоумышленном хранении посредством самого CPU ключей AES (вероятно перехваченных при использовании инструкции aes-ni), в возможности чего я сильно сомневаюсь и очень-очень сомневаюсь, что если оно таки есть, в штатных настройках компов в bios будут опции на этот счет.

Поэтому таки хотел бы увидеть хоть какие-то пруфы на это дело. Хотя бы примерно, типа там-то и там-то читал об этих вещах.

Инструкции аппаратного шифрования AES, появились на CPU Intel начиная с моделей последних годов, с этим же Intel ME внутренним шпионом-процесорром.

Но анонимус, как я понял, заговорил о недокументированном, злоумышленном хранении посредством самого CPU ключей AES (вероятно перехваченных при использовании инструкции aes-ni)

Сопоставляя два факта - появление Intel ME и аппаратного AES, возникает вопрос - где станут храниться ключи шифрования?

Инструкции аппаратного шифрования AES, появились на CPU Intel начиная с моделей последних годов, с этим же Intel ME внутренним шпионом-процесорром.

С 2008-го года, да.

Сопоставляя два факта - появление Intel ME и аппаратного AES, возникает вопрос - где станут храниться ключи шифрования?

aes-ni - это просто набор инструкций, вроде sse2 и подобных. То есть, имеется догадка, предположение, что ключи в процессе работы тырятся и куда-то ховаются в Intel me? Интересно, но кажется я здесь впервые увидел такое предположение. Наверное, количество ключей все-равно ограничено.

Интересно, но кажется я здесь впервые увидел такое предположение.

Потому что ты выбрал не то место, где общаются технически грамотные люди :(

Так в который раз интересуюсь, может есть url на на какие-то обсуждения документы на эту тему, а то последний поиск в гугле нашел только как раз этот топик на лоре =)))

146%, что эти выдающиеся открытия были сделаны теми двумя икспердами, лол.

С 2008-го года, да.

Имел в виду, аппаратное AES и набор инструкций aes-ni.
Так вот, этих инструкций нет и на компах 2013 года, business class.

Интереса ради, опробовал на нём комманду Linux, что делает дохлой UEFI мамаплаты.
Сработала комманда, вытерла данные UEFI и комп перестал загружаться. Совсем.
Заказал новую плату и поинтересовался, как вставляется Intel CPU.

По-хорошему, должна быть защита от выполнения таких комманд.
Её нет. Получается, что можно вывести из строя комп, стерев данные UEFI, но сохраняются ли данные в Intel ME?
То есть, можно ли вытащив такое CPU с одной платы, поставить на другую, с диагностикой в лаборатории специалистов железа и считать данные с Intel ME?

1. плату с нормальным UEFI и возможно Secure Boot

Если так извращаться то не проще ли подлить в UEFI свои ключи вместо микрософтовских и собирать ядро с initrd в один файл и подписать своим ключем? Тогда не будет таких лишних сущностей как флешка и grub. Мы же всё равно, что так, что этак доверяем нашей мат-плате?

Наверно речь идет о реализациях AES, которые после получения ключа шифрования хранят его только на регистрах процессора, а в памяти сразу затирают. Также еще есть такая штука, как TPM. Там есть варианты вообще весь RAM шифровать. Хотя согласен, тот первый аноним как-то бредовенько написал - без примеров и конкретики.

Как считаешь, какой ключ для блочного шифра надежнее: тот, который из парольной фразы алгоритмом (например, PBKDF2) получен или тот, который сгенерирован с использованием настоящего random-а из подключенного HSM-а? Вопрос относится именно к атаке на блочный шифр полнодискового шифрования, а не на систему управления ключевой информацией. Доп. информация: даже если ключ шифрования для блочного шифра получен из парольной фразы, то он всё-равно отдельно формируется по парольной фразе и храниться где нибудь (RAM,регистры проца, TPM, etc) на протяжении всего использования шифрованного раздела.

Имел в виду, аппаратное AES и набор инструкций aes-ni.
Так вот, этих инструкций нет и на компах 2013 года, business class.

Что это за бизнес-класс? Эти инструкции есть уже на Core i5,i7 и Xeon первого поколения на сокетах LGA1156 и LGA1366, а это 2010-2011-й год. Но на некоторых компьютерах, особенно локализированных, эти инструкции специально были выключены в BIOS, люди даже старались патчили прошивки для разблокировки. https://habrahabr.ru/post/185754/

По-хорошему, должна быть защита от выполнения таких комманд.

Насколько я понимаю, это от кривости реализации uefi конкретными производителями, то есть, штатно команда не повредит.

То есть, можно ли вытащив такое CPU с одной платы, поставить на другую, с диагностикой в лаборатории специалистов железа и считать данные с Intel ME?

Вот хз, во всяком случае, если пароли и тырятся, то хранятся почти наверняка точно не в самом процессоре, а где-то в nvram вокруг Intel Me. Причем там места не так, чтобы очень много, можно в таком случае его легко переполнить, если специально погонять инструкции в цикле с разными ключами. И я все же сомневаюсь в этом, потому что такое поведение требовало бы прерываний процессора на каждый новый ключ, а это на гигабитных скоростях, обеспечиваемых этим инструкциями было бы заметно.

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

Лажа. Для шифрования хомяков luks-ом достаточно сделать его на отдельном разделе и в нем криптоконтейнер. Я такое раньше на относительно слабом лаптопе использовал (pentium-m). Сейчас — LVM поверх криптораздела.

Наверно речь идет о реализациях AES, которые после получения ключа шифрования хранят его только на регистрах процессора, а в памяти сразу затирают.

Интересно, а что эти реализации делают с тем фактом, что операционные системы сохраняют в стеке (то есть в RAM) регистры процессора при переключениях задач?

Как считаешь, какой ключ для блочного шифра надежнее:

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

Я понимаю, что ты имел ввиду. Вот только альтернатива шифрованию ключа паролем - pbkdf2 и иже с ними. В обоих случаях ключ блочного шифрования бывает в системе в открытом виде, т.е. с точки зрения надежности криптосистемы в целом эти 2 метода одинаковы. С учетом того, что перебор при востановлении шифрованного ключа блочного шифра из файла/заголовка/etc равносилен или сложнее чем перебор сразу самого ключа шифрования блочного шифра, какие претензии к шифрованию существующего ключа паролем?

А что они могут сделать? )))

XMM регистры (см. https://github.com/kmcallister/aesni-examples ) можно и GDB сдампить. Пруф: https://stackoverflow.com/questions/9949595/how-to-dump-all-the-xmm-registers... и там дальше по ссылкам.

Лажа.

Ага. Все Убунты, Андроиды и Хромоосы побежали наперегонки делать разделы под каждую новую учётку.

Никому нет дела до твоих личных извращений.

Ага. Все Убунты, Андроиды и Хромоосы побежали наперегонки делать разделы под каждую новую учётку.

Ты идиот? Достаточно сделать шифрованным /home

Никому нет дела до твоих личных извращений.

Вопрос снят. Таки идиот.

Достаточно сделать шифрованным /home

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

Как ты собрался расшифровывать хомяк юзера, который залогинился?

Давно у нас на Андроидах и Хромосах работают по два пользователя одновременно? На убунте такое штатно решается через encryptfs, там же и в других линуксах — encfs, которую я лично тоже использую.

Давно у нас на Андроидах и Хромосах работают по два пользователя одновременно?

С разморозкой. Работают ли они одновременно, это не важно. Главное что их может быть больше одного.

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

О чём я и говорил: шифрование раздела с помощью LUKS не подходит для защиты домашних директорий юзеров.


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

О чём я и говорил: шифрование раздела с помощью LUKS не подходит для защиты домашних директорий юзеров.

Ты всё также упорствуешь в своем незнании:

https://wiki.archlinux.org/index.php/Dm-crypt/Mounting_at_login

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

И это не говоря уж о том, что криптоконтейнер с ФС можно сделать в обычно файле и бэкапить его хоть по сети.

То, что luks не умеет (или я не знаю как) — это шифрование *файлов и каталогов* в рамках одной ФС. Но для этого, как я и говорил, есть encfs, которую я лично и использую для хранения на лаптопе всяких сканов документов.

https://wiki.archlinux.org/index.php/Dm-crypt/Mounting_at_login

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

в линуксе самые разнообразные способы шифрования — на любые запросы

Факт. И многие из этих возможностей являются извращениями и нормальным людям не интересны.
Их для юзкейса «шифрование хомяка» не интересует LUKS, здесь нужно шифрование на уровне ФС.

Но тебе же главное доказать, что «сопливые линупсы» ничего не умеют, а апплесофт божественен.

Ты продолжаешь слепо вешать ярлыки.


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

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

Ну да, конечно, а

здесь нужно шифрование на уровне ФС.

Это то, что нужно.

Я тоже не вижу смысла продолжать разговор. Если принять аксиому «нужно шифрование ФС просто чтобы было», а не решать проблему шифрования пользовательских данных, то да, решения, кроме «шифрования ФС» нет. В логике такое зовётся «тавтология», спорить о ней действительно бессмысленно. Adieu.

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

В macbook используется TMP криптопроцессор, в котором хранятся криптографические ключи для защиты информации.

Для взлома использовался электронный микроскоп (стоимостью около $70 000). Оболочка чипа была растворена кислотой, для перехвата команд были использованы мельчайшие иголки. В Infineon утверждают, что они знали о возможности физического взлома чипа. Борчерт (Borchert), вице-президент компании, заверил, что дорогое оборудование и техническая сложность взлома не представляет опасности для подавляющего большинства пользователей чипов.

Все как бы надежно.

Как такое можно реализовать

Выплюнуть на экран фотографию «нормального» логина перед вводом пароля. Заодно можно будет хвастаться, что ОС стартует милисекунду.

Я делал лет 5 назад с автологином через груб

Но этот вариант меня не устраивает тоже. Сейчас ищу как бы вынести на флэшку все. Для тех кто считает что это не нужно типо зачем. Поясняю. Комп стоит и доступен для всех. Без ключа на диск никто не влезет. Теперь представим что диск или комп украли... ???? Теперь представим что диск продали.... ??? Нафига мне тратить время на полное форматирование когда я просто вытащил флешку и никто не получит данные с моего диска.

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