Практическое использование 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")

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