Практическое использование ecryptfs, зашифрованных ключей и TPM: как преобразовать существующий пользовательский ключ в зашифрованный ключ?

Краткая версия этого вопроса: Как мне преобразовать пользовательский ключ на связке ключей ядра, хранящей токен аутентификации ecryptfs / FEFEK, в зашифрованный ключ на связке ключей? (То есть, как добавить зашифрованный ключ с заданными пользователем данными открытого текста вместо случайно сгенерированного ключа - например, ранее существовавшей парольной фразы монтирования для существующей файловой системы ecryptfs.) Читайте, почему...

Я пытаюсь выяснить, как практически использовать ecryptfs с доверенным платформенным модулем, и информация, которую я нахожу, как правило, устарела / устарела. Все, что я нашел, - это статьи в блогах или публикации IBM за несколько лет назад, в которых, как представляется, используются функции, которых больше нет / не поддерживаются (удаленный модуль TSPI, и библиотека OpenSSL TPM, которая, кажется, не поддерживается и больше не присутствует в моем приложении). менеджер пакетов). Я понял, что правильный способ сделать это теперь включает в себя доверенные и зашифрованные ключи ядра, согласно:

• https://www.kernel.org/doc/Documentation/security/keys-ecryptfs.txt
• https://www.kernel.org/doc/Documentation/security/keys-trusted-encrypted.txt

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

Проблема в том, что если TPM умирает, мне нужно восстановить мои данные (например, компьютер умирает, и нужно восстановить из зашифрованных резервных копий). Я хочу использовать парольную фразу для расшифровки данных, если TPM недоступен, чтобы использовать его только в особых обстоятельствах. В качестве альтернативы, у пользователей может быть уже существующая файловая система ecryptfs с уже выбранной парольной фразой / FEFEK - т.е. вы не хотите повторно шифровать все ваши файлы только для использования TPM. Это кажется очевидной необходимостью, но у меня есть проблемы с выяснением "как".

Из приведенной выше документации:

The data structure defined by eCryptfs to contain information required for the
FEK decryption is called authentication token and, currently, can be stored in a
kernel key of the 'user' type, inserted in the user's session specific keyring
by the userspace utility 'mount.ecryptfs' shipped with the package
'ecryptfs-utils'.

Encrypted keys of the newly introduced [ecryptfs encrypted] format store an
authentication token in its payload with a FEFEK randomly generated by the
kernel and protected by the parent master key.  [What if I want to use an
existing FEFEK?]

Хорошо, мне кажется, что ядро ​​хранит зашифрованный ключ в том же формате, что и обычный пользовательский ключ, который будет добавлен в набор ключей инструментами пользовательского пространства ecryptfs (например, ecryptfs-add-passphrase или помощник по креплению). Таким образом, полезная нагрузка пользовательского ключа и зашифрованного ключа в основном одна и та же, за исключением того, что ядро ​​не позволяет пользовательскому пространству читать зашифрованный ключ в незашифрованном формате. Правильно?

Поэтому я думаю, что я хочу сделать, это - я на правильном пути здесь?

1. использование ecryptfs-add-passphraseдобавить монтажную ключевую фразу в связку ключей. (Это может быть пароль для монтирования существующей файловой системы ecryptfs). Теперь у меня есть ключ пользователя на связке ключей, хранящий токен аутентификации ecryptfs. Крепежная фраза-пароль может быть сложной и храниться в автономном безопасном месте, возможно, защищенная ecryptfs-wrap-passphrase и используется только в сценарии восстановления данных (например, если TPM поднимается в дыму).
2. Создайте новый доверенный ключ в связке ключей, как указано в документации к ядру.
3. Преобразовать существующий ключ пользователя, хранящий токен аутентификации из ecrypt-add-passphrase на шаге 1 в зашифрованный ключ на связке ключей, используя доверенный ключ в качестве главного ключа. (Вот где я застрял.)
4. Удалите ключ пользователя из набора ключей, так как он нам больше не нужен.
5. использование keyctl pipe сохранить зашифрованный ключ в файл на диске для последующего подключения.

Обычный ежедневный монтаж будет работать так:

1. Загрузите и распечатайте доверенный ключ в связку ключей.
2. Загрузите зашифрованный ключевой блок с шага № 5 выше в зашифрованный ключ в связке ключей, используя доверенный ключ в качестве главного ключа.
3. Смонтируйте, используя зашифрованный ключ из предыдущего шага.

Если TPM уничтожен или потерян:

1. использование ecryptfs-add-passphrase добавить пароль для монтирования из резервной копии в токен аутентификации, сохраненный в ключе пользователя.
2. Смонтировать, используя этот ключ пользователя.

Итак, мой ключевой вопрос заключается в следующем: как преобразовать токен аутентификации, хранящий ключ пользователя, в зашифрованный ключ, как на шаге 3 процедуры настройки выше? Например, документы ядра говорят об этом, чтобы расшифровать существующий зашифрованный ключ, ранее экспортированный с помощью keyctl pipe:

keyctl add encrypted name "load hex_blob" ring

Но я хочу сделать что-то вроде этого, чтобы создать новый зашифрованный ключ из некоторого ранее существующего открытого текста:

keyctl add encrypted name "load ecryptfs trusted:masterkey `keyctl print <id of user key holding plaintext authentication token / FEFEK / mounting passphrase>`" @u

(Это в отличие от случайного нового ключа, сгенерированного с add encrypted name "new ecryptfs")

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