Keytool efi как запустить

Super UEFIinSecureBoot Disk — запуск любых ОС и .efi-файлов с флешки без отключения UEFI Secure Boot

Super UEFIinSecureBoot Disk — образ диска с загрузчиком GRUB2, предназначенным для удобного запуска неподписанных efi-программ и операционных систем в режиме UEFI Secure Boot.

Диск можно использовать в качестве основы для создания USB-накопителя с утилитами восстановления компьютера, для запуска различных Live-дистрибутивов Linux и среды WinPE, загрузки по сети, без отключения Secure Boot в настройках материнской платы, что может быть удобно при обслуживании чужих компьютеров или корпоративных ноутбуков, например, при установленном пароле на изменение настроек UEFI.

Образ состоит из трех компонентов: предзагрузчика shim из Fedora (подписан ключом Microsoft, предустановленным в подавляющее большинство материнских плат и ноутбуков), модифицированного предзагрузчика PreLoader от Linux Foundation (для отключения проверки подписи при загрузке .efi-файлов), и модифицированного загрузчика GRUB2, который загружает EFI-файлы самостоятельно, не используя функции UEFI.

Во время первой загрузки диска на компьютере с Secure Boot необходимо выбрать сертификат через меню MokManager (запускается автоматически), после чего загрузчик будет работать так, словно Secure Boot выключен: GRUB загружает любой неподписанный .efi-файл или Linux-ядро, загруженные EFI-программы могут запускать другие программы и драйверы с отсутствующей или недоверенной подписью.

Для демонстрации работоспособности, в образе присутствует Super Grub Disk (скрипты для поиска и загрузки установленных операционных систем, даже если их загрузчик поврежден), GRUB Live ISO Multiboot (скрипты для удобной загрузки Linux LiveCD прямо из ISO, без предварительной распаковки и обработки), One File Linux (ядро и initrd в одном файле, для восстановления системы), и несколько UEFI-утилит.

Диск совместим с UEFI без Secure Boot, а также со старыми компьютерами с BIOS.

Укрощаем UEFI SecureBoot

Данные обещания надо выполнять, тем более, если они сделаны сначала в заключительной части опуса о безопасности UEFI, а потом повторены со сцены ZeroNights 2015, поэтому сегодня поговорим о том, как заставить UEFI SecureBoot работать не на благо Microsoft, как это чаще всего настроено по умолчанию, а на благо нас с вами.
Если вам интересно, как сгенерировать свои собственные ключи для SecureBoot, как установить их вместо стандартных (или вместе с ними), как подписать ваш любимый EFI-загрузчик, как запретить загрузку неподписанного или подписанного чужими ключами кода, как выглядит интерфейс для настройки SecureBoot у AMI, Insyde и Phoenix и почему это, по большому счету, совершенно не важно — добро пожаловать под кат, но опасайтесь большого количества картинок и длинных консольных команд.

Введение

О том, как устроен и работает SecureBoot, я уже рассказывал в начале пятой части вышеупомянутого опуса, повторяться смысла не вижу. Если вы не в курсе, о чем весь этот UEFI SecureBoot вообще, кто такие PK , KEK , db и dbx , и почему с точки зрения SecureBoot по умолчанию хозяином вашей системы является производитель UEFI, а единственным авторизованным пользователем является Microsoft — смело проследуйте туда, мы вас тут пока подождем.

С ликбезом закончили, теперь к делу. Несмотря на то, что про создание своих ключей и настройку SecureBoot написано за три последних года с десяток отличных статей (ссылки на часть из которых приведены в разделе Литература), воз и ныне там. Основная проблема с информацией о настройке SecureBoot даже в англоязычном сегменте сети (не говоря уже о рунете) — большая часть статей, текстов и постов обрывается на «вот у нас теперь есть ключи в формате EFI Signature List, добавьте их зависимым от вашего вендора прошивки способом и готово». При этом сами вендоры не торопятся описывать меню настройки SecureBoot ни в документации на свои платформы для OEM’ов, ни в мануалах на конечные системы, в результате пользователь теряется на незнакомой местности и либо отключает SecureBoot, мешающий загружать его любимую OpenBSD (или что там у него), либо оставляет его на настройках по умолчанию (а чего, Windows грузится же). Именно этот последний шаг я и попытаюсь описать более подробно, но не в ущерб остальным необходимым шагам.

Тестовая конфигурация

Специально для этой статьи я достал из закромов пару не самых новых ноутбуков с прошивками на платформах Phoenix SCT и Insyde H2O, а также совершенно новую плату congatec (разработкой прошивки для которой я занят в данный момент) на платформе AMI AptioV. Встречайте, наши тестовые стенды:

1. AMI, они же «треугольные«: congatec conga-TR3 @ conga-TEVAL, AMD RX-216GD (Merlin Falcon), AMI AptioV (UEFI 2.4)

2. Insyde, они же «квадратные«: Acer Aspire R14 R3-471T (Quanta ZQX), Intel Core i3-4030U (Ivy Bridge), Insyde H2O (UEFI 2.3.1C)

3. Phoenix, они же «полукруглые«: Dell Vostro 3360 (Quanta V07), Intel Core i7-3537U (Ivy Bridge), Phoenix SCT (UEFI 2.3.1C)

Об интерфейсах для настройки SecureBoot

На всех вышеперечисленных системах производитель заявляет о поддержке технологии UEFI SecureBoot, но интерфейс для ее настройки сильно отличается между системами. К счастью, это не очень большая проблема, поскольку для настройки SecureBoot на совместимых со спецификацией UEFI 2.3.1C (и более новых) прошивках никакого интерфейса в Setup, кроме возможности удаления текущего PK (т.е. перевода SecureBoot в так называемый Setup Mode) не требуется, а после этого можно использовать любое EFI-приложение, способное вызвать UEFI-сервис gRS->SetVariable с предоставленными пользователем данными, в том числе утилиту KeyTool.efi из пакета efitools, которая специально для управления ключами и предназначена, осталось только научиться ей пользоваться.
Тем не менее, если удобный интерфейс для настройки присутствует (у AMI он, на мой взгляд, даже удобнее KeyTool‘а) — можно воспользоваться им, так что рассказывать про эти самые интерфейсы все равно придется.

Пара слов про скриншоты UEFI

Благодаря универсальности GOP , ConIn/ConOut и DevicePath можно было сесть и написать за полчаса простой DXE-драйвер, который снимал бы замечательные скриншоты в формате BMP со всего, что происходит в графической консоли после его (драйвера) загрузки по нажатию горячей клавиши, после чего сохранял бы их на первом попавшемся USB-носителе с ФС FAT32… Но его нужно сначала написать, потом отладить, потом интегрировать в прошивки так, чтобы они от этого не развалились (а на ноутбуках придется микросхему с прошивкой выпаивать и под программатор класть, если вдруг что-то не так пойдет), плюс с подконтрольного мне AptioV можно снимать скриншоты просто используя терминал и console serial redirection, а у остальных там настроек буквально на два-три экрана, которые можно банально с монитора сфотографировать, поэтому прошу вас, уважаемые читатели, простить вашего покорного слугу за эти кривые фотографии и за тот факт, что он — ленивая жопа.

Готовим плацдарм

Начнем с лирического отступления о наличии нужного софта для разных ОС. Несмотря на то, что Microsoft является одним из разработчиков технологии, в открытом доступе до сих пор отсутствуют нормальные средства для работы с ней из Windows (ключи можно сгенерировать утилитой MakeCert из Windows SDK, а для всего остального предлагается использовать HSM третьих лиц за большие деньги). Я подумывал сначала взять и написать нужную утилиту на Qt, но потому решил, что ключи и подписи каждый день генерировать не нужно, а на пару раз хватит и существующих решений. Можете попробовать переубедить меня в комментариях, если хотите.
В общем, для всего нижеперечисленного вам понадобится Linux (который можно запустить с LiveUSB, если он у вас не установлен). Для него существует целых два набора утилит для работы с SecureBoot: efitools/sbsigntool и EFIKeyGen/pesign. У меня есть положительный опыт работы с первым набором, поэтому речь пойдет именно о нем.
В итоге, кроме Linux, нам понадобятся несколько вещей:
1. Пакет openssl и одноименная утилита из него для генерирования ключевых пар и преобразования сертификатов из DER в PEM.
2. Пакет efitools, а точнее утилиты cert-to-efi-sig-list, sign-efi-sig-list для преобразования сертификатов в формат ESL и подписи файлов в этом формате, и KeyTool.efi для управления ключами системы, находящейся в SetupMode.
3. Пакет sbsigntool, а точнее утилита sbsign для подписи исполняемых файлов UEFI (т.е. загрузчиков, DXE-драйверов, OptionROM’ов и приложений для UEFI Shell) вашим ключом.
Загрузите Linux, установите вышеуказанные пакеты, откройте терминал в домашней директории и переходите к следующему шагу.

Генерируем собственные ключи для SecureBoot

Как обычно, есть несколько способов сделать что-либо, и чем мощнее используемый инструмент, тем таких способов больше. OpenSSL же как инструмент развит настолько, что кажется, что он умеет делать вообще всё, а если почитать к нему man — то и абсолютно всё остальное. Поэтому в этой статье я ограничусь непосредственной генерацией ключевых файлов, а танцы вокруг создания собственного CA оставлю на самостоятельное изучение.

Генерируем ключевые пары

Ключей понадобится сгенерировать три штуки: PK, KEK и ISK .
Начнем с PK, для генерации которого нужно выполнить следующее

openssl req -new -x509 -newkey rsa:2048 -sha256 -days 365 -subj "/CN=Platform Key" -keyout PK.key -out PK.pem

после чего ввести и подтвердить пароль, который потом спросят при попытке подписи чего-либо получившимся закрытым ключом.
Командой выше мы просим OpenSSL сгенерировать нам ключевую пару RSA2048/SHA256 со сроком действия на один год, под названием Platform Key, с выводом закрытого ключа в файл PK.key, а открытого — в файл PK.pem. Если добавить -nodes, то для подписи этой ключевой парой не нужен будет пароль, но здесь мы этого делать не станем — с паролем хоть ненамного, но безопаснее.
Таким же образом генерируем ключевые пары для KEK и ISK, пароли при этом советую вводить разные:

openssl req -new -x509 -newkey rsa:2048 -sha256 -days 365 -subj "/CN=Key Exchange Key" -keyout KEK.key -out KEK.pem

openssl req -new -x509 -newkey rsa:2048 -sha256 -days 365 -subj "/CN=Image Signing Key" -keyout ISK.key -out ISK.pem

Конвертируем открытые ключи в формат ESL

Теперь нужно сконвертировать открытые ключи из формата PEM в понятный UEFI SecureBoot формат ESL. Этот бинарный формат описан в спецификации UEFI (раздел 30.4.1 в текущей версии 2.5) и интересен тем, что файлы в нем можно соединять друг с другом конкатенацией, и этот факт нам еще пригодится.

cert-to-efi-sig-list -g "$(uuidgen)" PK.pem PK.esl

cert-to-efi-sig-list -g "$(uuidgen)" KEK.pem KEK.esl

cert-to-efi-sig-list -g "$(uuidgen)" ISK.pem ISK.esl

Ключ -g добавляет к сгенерированному ESL-файлу GUID, в нашем случае — случайный, полученый запуском утилиты uuidgen и использованием ее вывода. Если этой утилиты у вас нет — придумывайте GUIDы сами или оставьте значение по умолчанию.

Подписываем ESL-файлы

Для правильно работы SecureBoot необходимо, чтобы PK был подписан сам собой, KEK подписан PK, а хранилища db и dbx — сответственно KEK. При этом PK не может быть несколько, а вот ситуация с несколькими KEK хоть и встречается в дикой природе, но я все же настоятельно рекомендую удалить предустановленный ключ Microsoft из KEK по простой причине — db и dbx могут быть подписаны любым ключом из хранилища KEK, т.е. если ключ MS оттуда не удалить, то у MS будет возможность управлять содержимым db и dbx, т.е. добавлять любые новые ключи или хеши в список доверенной загрузки и удалять из него существующие. На мой взгляд, это немного слишком, и если мы берем управление ключами в свои руки, то нужно делать это до конца.

Если вы думаете иначе

Ну тогда вам прямая дорога вот сюда, там в самом конце раздела 1.3.4.3 есть ссылка на сертификат Microsoft Corporation KEK CA 2011 в формате DER, из которого нужно сначала получить PEM командой

openssl x509 -in MicCorKEKCA2011_2011-06-24.crt -inform DER -out MsKEK.pem -outform PEM

затем сконвертировать полученный PEM в ESL командой

cert-to-efi-sig-list -g "$(uuidgen)" MsKEK.pem MsKEK.esl

после чего добавить получившийся файл к нашему файлу KEK.esl командой

cat KEK.esl MsKEK.esl > NewKEK.esl

mv -f NewKEK.esl KEK.esl

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

С другой стороны, если вы не хотите терять возможность загрузки Windows и подписанных ключом Microsoft исполняемых компонентов (к примеру, GOP-драйверов внешних видеокарт и PXE-драйверов внешних сетевых карточек), то к нашему ISK.esl надо будет добавить еще пару ключей — ключ Microsoft Windows Production CA 2011, которым MS подписывает собственные загрузчики и ключ Microsoft UEFI driver signing CA, которым подписываются компоненты третьих сторон (именно им, кстати, подписан загрузчик Shim, с помощью которого теперь стартуют разные дистрибутивы Linux, поддерживающие SecureBoot из коробки).
Последовательность та же, что и под спойлером выше. Конвертируем из DER в PEM, затем из PEM в ESL, затем добавляем к db.esl, который в конце концов надо будет подписать любым ключом из KEK:

openssl x509 -in MicWinProPCA2011_2011-10-19.crt -inform DER -out MsWin.pem -outform PEM

openssl x509 -in MicCorUEFCA2011_2011-06-27.crt -inform DER -out UEFI.pem -outform PEM

cert-to-efi-sig-list -g "$(uuidgen)" MsWin.pem MsWin.esl

cert-to-efi-sig-list -g "$(uuidgen)" UEFI.pem UEFI.esl

cat ISK.esl MsWin.esl UEFI.esl > db.esl

Теперь подписываем PK самим собой:

sign-efi-sig-list -k PK.key -c PK.pem PK PK.esl PK.auth

Подписываем KEK.esl ключом PK:

sign-efi-sig-list -k PK.key -c PK.pem KEK KEK.esl KEK.auth

Подписываем db.esl ключом KEK:

sign-efi-sig-list -k KEK.key -c KEK.pem db db.esl db.auth

Если еще не надоело, можно добавить чего-нибудь еще в db или создать хранилище dbx, нужные команды вы теперь знаете, все дальнейшее — на ваше усмотрение.

Подписываем загрузчик

Осталось подписать какой-нибудь исполняемый файл ключом ISK, чтобы проверить работу SecureBoot после добавления ваших ключей. Для тестов я советую подписать утилиту RU.efi, она графическая и яркая, и даже издалека видно, запустилась она или нет. На самом деле, утилита эта чрезвычайно мощная и ей можно натворить немало добрых и не очень дел, поэтому после тестов лучше всего будет её удалить, и в дальнейшем подписывать только загрузчики.
В любом случае, подписываются исполняемые файлы вот такой командой:

sbsign --key ISK.key --cert ISK.pem --output bootx64.efi RU.efi

Здесь я заодно переименовал исполняемый файл в bootx64.efi, который нужно положить в директорию /EFI/BOOT тестового USB-носителя с ФС FAT32. Для 32-битных UEFI (избавь вас рандом от работы с ними) используйте bootia32.efi и RU32.efi.

В результате вот этого всего у вас получились три файла .auth, которые нужно будет записать «как есть» в NVRAM-переменные db, KEK и PK, причем именно в таком порядке. Скопируйте все три файла в корень другого USB-носителя с ФС FAT32, на котором в качестве /EFI/BOOT/bootx64.efi выступит /usr/share/efitools/efi/KeyTool.efi (скопируйте его еще и в корень, на всякий случай) и ваш «набор укротителя SecureBoot» готов.

Укрощение строптивого

Начинается все одинаково: вставляем нашу флешку с ключами и KeyTool‘ом в свободный USB-порт, включаем машину, заходим в BIOS Setup. Здесь, прежде чем заниматься настройкой SecureBoot, нужно отключить CSM , а с ним — и легаси-загрузку, с которыми наша технология не совместима. Также обязательно поставьте на вход в BIOS Setup пароль подлиннее, иначе можно будет обойти SecureBoot просто отключив его, для чего на некоторых системах с IPMI и/или AMT даже физическое присутсвие не потребуется.

AMI AptioV

У большинства прошивок, основанных на коде AMI, управление технологией SecureBoot находится на вкладке Security, у меня это управление выглядит так:

Заходим в меню Key Management (раньше оно было на той же вкладке, сейчас его выделили в отдельное) и видим там следующее:

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

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

Далее нужно устройство и файл на нем, а затем выбрать формат этого файла, в нашем случае это Authenticated Variable:

Затем нужно подтвердить обновление файла, и если все до этого шло хорошо, в результате получим лаконичное сообщение:

Повторяем то же самое для KEK и PK, и получам на выходе вот такое состояние:

Все верно, у нас есть единственный PK, всего один ключ в KEK и три ключа в db, возвращаемся в предыдущее меню кнопкой Esc и включаем SecureBoot:

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

Отлично, неподписанные загрузчики идут лесом, осталось проверить подписанный. Вставляем другую флешку, перезагружаемся и видим что-то такое:

Вот теперь можно сказать, что SecureBoot работает как надо.
Если у вашего AMI UEFI такого интерфейса для добавления ключей нет, то вам подойдет другой способ, о котором далее.

Insyde H2O

Здесь все несколько хуже, чем в предыдущем случае. Никакого интерфейса для добавления собственных ключей нет, и возможностей настройки SecureBoot предлагается всего три: либо удалить все переменные разом, переведя SecureBoot в Setup Mode, либо выбрать исполняемый файл, хеш которого будет добавлен в db, и его можно будет запускать даже в том случае, если он не подписан вообще, либо вернуться к стандартным ключам, в качестве которых на этой машине выступают PK от Acer, по ключу от Acer и MS в KEK и куча всякого от Acer и MS в db.
Впрочем, нет интерфейса — ну и черт с ним, у нас для этого KeyTool есть, главное, что в Setup Mode перейти можно. Интересно, что BIOS Setup не дает включить SecureBoot, если пароль Supervisor Password не установлен, поэтому устанавливаем сначала его, затем выполняем стирание ключей:

После чего на соседней вкладке Boot выбираем режим загрузки UEFI и включаем SecureBoot:

Т.к. фотографии у меня посреди ночи получаются невыносимо отвратительными, то скриншоты KeyTool‘а я сделаю на предыдущей системе, и придется вам поверить в то, что на этой все выглядит точно также (мамой клянусь!).
Загружаемся с нашего носителя в KeyTool, и видим примерно следующее:

Выбираем Edit Keys, попадаем в меню выбора хранилища:

Там сначала выбираем db, затем Replace Keys, затем наше USB-устройство, а затем и файл:

Нажимаем Enter и без всяких сообщений об успехе нам снова показывают меню выбора хранилища. Повторяем то же самое сначала для KEK, а затем и для PK, после выходим в главное меню двойным нажатием на Esc. Выключаем машину, включаем заново, пытаемся загрузить KeyTool снова и видим такую картину (которую я утащил из дампа прошивки, ее фото на глянцевом экране еще кошмарнее, чем предыдущие):

Ну вот, одна часть SecureBoot’а работает, другая проверяется запуском подписанной нами RU.efi и тоже работает. У меня на этой системе Windows 8 установлена в UEFI-режиме, так вот — работает и она, Microsoft с сертификатом не подвели.

Phoenix SCT

Здесь возможностей еще меньше, и во всем меню Secure Boot Configuration на вкладке Security всего два пункта: возврат к стандартным ключам и удаление всех ключей с переводом системы в SetupMode, нам нужно как раз второе:

Затем на вкладке Boot нужно выбрать тип загрузки UEFI, включить SecureBoot, и создать загрузочную запись для KeyTool‘а, иначе на этой платформе его запустить не получится:

Нажимаем Yes, выходим с сохранением изменений, перезагружаемся, нажимаем при загрузке F12, чтобы попасть в загрузочное меню, оттуда выбираем KeyTool, работа с которым описана выше. После добавления ключей и перезагрузки попытка повторного запуска KeyTool‘а заканчивается вот так:

При этом установленный на той же машине Linux продолжает исправно загружаться, как и подписанная нами RU.efi, так что SecureBoot можно признать работоспособным.

Заключение

В итоге, благодаря утилитам с открытым кодом, удалось завести SecureBoot на системах с UEFI трех различных вендоров, сгенерировать свои собственные ключи и подписать ими нужные нам исполняемые файлы. Теперь загрузка платформы целиком в наших руках, но только в случае, если пароль на BIOS стойкий и не хранится открытым текстом, как у некоторых, а в реализации SecureBoot нет каких-либо известных (или еще неизвестных) дыр. Сам по себе SecureBoot — не панацея от буткитов, но с ним ситуация с безопасной загрузкой все равно намного лучше, чем без него.
Надеюсь, что материал вам поможет, и спасибо за то, что прочитали эту портянку.

Предзагрузчик для загрузки дистрибутивов Linux с безопасной загрузкой готов.

Коллега Диазепан взял на себя труд перевести сообщение в блоге Джеймса Боттомли, в котором подробно объясняется это объявление:

Как и было обещано, вот система безопасной загрузки Linux Foundation. На самом деле он был предоставлен нам Microsoft 6 февраля, но с поездками, конференциями и встречами у меня не было времени все проверить до сегодняшнего дня. Это файлы:

PreLoader.efi (md5sum 4f7a4f566781869d252a09dc84923a82)
HashTool.efi (md5sum 45639d23aa5f2a394b03a65fc732acf2)
Я также создал загрузочный образ mini-USB; (Вы должны установить его на USB с помощью dd; образ имеет разделы GPT, поэтому он использует весь диск). Он имеет оболочку EFI, где должно быть ядро, и использует gummiboot для его загрузки. май найди здесь (md5sum 7971231d133e41dd667a184c255b599f).

Чтобы использовать образ mini-USB, вам необходимо зарегистрировать хеши для loader.efi (в папке EFIBOOT) и shell.efi (в корневой папке). Он также включает копию KeyTool.efi, вы должны ввести хеш для запуска.

Что случилось с KeyTool.efi? Изначально он должен был быть частью нашего подписанного набора. Однако во время тестирования Microsoft обнаружила, что из-за ошибки в одной из платформ UEFI ее можно использовать для программного удаления ключа платформы, что приведет к разрушению системы безопасности UEFI. Пока мы не сможем решить эту проблему (у нас есть частный поставщик в цикле), они отказались подписать KeyTool.efi, хотя вы можете авторизовать его, добавив переменные MOK, если хотите его запустить.

Сообщите мне, как это происходит, потому что я заинтересован в сборе отзывов о том, что работает, а что нет. В частности, я обеспокоен тем, что переопределение протокола безопасности не будет работать на некоторых платформах, поэтому я особенно хочу знать, не работает ли оно для них.

Что вы думаете? Это хорошие новости? Соответствует ли это интересам Microsoft? Споры открыты.

Содержание статьи соответствует нашим принципам редакционная этика. Чтобы сообщить об ошибке, нажмите здесь.

Полный путь к статье: Из Linux » ФайлДавайте использовать Linux » Предзагрузчик для загрузки дистрибутивов Linux с безопасной загрузкой готов.

5 комментариев, оставьте свой

Keytool и примеры использования с параметрами

Добрый день! Уважаемые читатели и гости IT Блога Pyatilistnik.org. В прошлый раз мы с вами разобрали полезную утилиту для системного администратора Remote Desktop Connection Manager, многие открыли для себя простоту и функциональность ее использования. Сегодня я хочу вас познакомить с еще одним, полезным инструментом, который поможет вам удобно управлять ключами и сертификатами в вашей системе. Речь пойдет про утилиту keytool, мы рассмотрим примеры ее использования на реальных ситуациях.

Что такое Keytool ?

Keytool — это утилита командной строки, для управления ключами или сертификатами, а так же хранилищами ключей. Она позволяет пользователям управлять своими собственными парами открытых и закрытых ключей и связанными сертификатами для использования при аутентификации, где от пользователя, это требует конечный сервис или службах целостности данных и аутентификации с использованием цифровых подписей. Keytool также позволяет пользователям администрировать секретные ключи, используемые при симметричном шифровании/дешифровании (например, DES). Пользователь имеет возможность самостоятельно генерировать эти пары ключей, после чего он их сохраняет в хранилище ключей (keystore).

Keystore — это защищенный файл или правильнее сказать база данных, которая выступает в роли специального, защищенного хранилища открытых ключей, сертификатов, секретных ключей.

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

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

Все это многообразие используется приложениями Java для:

• Работы HTTPS соединений
• Аутентификации
• Шифрования

Keystore умеет работать в ситуации, когда в процессе работы необходима аутентификация сервера и клиента, где все реализовано с помощью SSL соединения, подразумевающее использование приватных ключей и сертификатов и так же keystore применяется при односторонней аутентификации, но только на стороне сервера. Java KeyStore представлен классом java.security.KeyStore. Поскольку KeyStore общедоступен, пользователи JDK могут создавать дополнительные приложения безопасности, которые его используют.

Типы поддерживаемых форматов в keystore

• pkcs12 — это один из типов хранилища, заточенный чисто под хранение и перенос закрытых ключей пользователя, сертификатов.
• jceks — сторонняя разработка хранилища, отличная более стойким шифрованием на основе triple DES. Позволяет обновлять существующие jks-хранилища до jceks
• jks — это самый обычный, стандартный тип хранилища, в виде простого файла имеющего расширение jks («java key storage»), устанавливается по умолчанию и, поэтому, применяется наиболее часто.

Реализации Keystore основаны на провайдере. Более конкретно, интерфейсы приложений, предоставляемые KeyStore, реализованы в терминах «Интерфейс поставщика услуг» (Service Provider Interface — SPI). То есть существует соответствующий абстрактный класс KeystoreSpi, также в пакете java.security, который определяет методы интерфейса поставщика услуг, которые должны реализовывать » провайдеры-поставщики». (Термин «поставщик» относится к пакету или набору пакетов, которые предоставляют конкретную реализацию подмножества служб, к которым может обращаться API безопасности Java.)

Приложения могут выбирать различные типы реализаций хранилища ключей от разных поставщиков, используя фабричный метод getInstance, предоставленный в классе KeyStore . Тип хранилища ключей определяет хранилище и формат данных информации хранилища ключей, а также алгоритмы, используемые для защиты личных ключей в хранилище ключей и целостности самого хранилища ключей. Реализации Keystore разных типов несовместимы. keytool работает с любой файловой реализацией хранилища ключей. (Он обрабатывает расположение хранилища ключей, которое ему передается в командной строке, как имя файла и преобразует его в FileInputStream, из которого он загружает информацию о хранилище ключей.) Инструменты jarsigner и policytool, с другой стороны, могут читать хранилище ключей из любого места, которое можно указать с помощью URL.

Если вы не укажете явно тип хранилища ключей, инструменты выберут реализацию хранилища ключей просто на основании значения свойства keystore.type, указанного в файле свойств безопасности. Файл свойств безопасности называется java.security и находится в каталоге свойств безопасности JDK, java.home/lib/security. Каждый инструмент получает значение keystore.type, а затем проверяет все установленные на данный момент провайдеры, пока не найдет того, который реализует хранилища ключей этого типа. Затем он использует реализацию хранилища ключей от этого провайдера.

Где хранится Keystore и что такое алиас

Любая созданная запись в хранилище ключей Keystore может иметь уникальный псевдоним (алиас — alias). В документации, настоятельно рекомендуется называть алиасы записей Keystore другими именами, отличными от основных. Простой пример, допустим, у вас запись называется root.pyatilistnik.org, вы можете задать алиас 5org. В стандартной реализации каждый ключ в хранилище защищается паролем; кроме того, всё хранилище целиком может быть защищено отдельным паролем. Если вы ничего не меняли, то стандартное расположение хранилища сертификатов находится по пути jre/lib/security/cacerts (пароль по умолчанию- changeit).

Где скачать утилиту keytool

Утилита Keytool входит в состав Java SDK (или JRE), в большинстве компьютеров в основном установлена JRE версия. В Windows данную утилиту можно найти по пути:

C:\Program Files (x86)\Java\jre1.8.0_201\bin\

Тут все зависит от разрядности Java. На скриншоте отмечен файл Keytool.exe.

Как запустить утилиту Keytool в Windows

cd C:\Program Files (x86)\Java\jre1.8.0_201\bin\ или cd C:\Program Files\Java\jre1.8.0_201\bin\ (Хочу отметить, что у вас будет своя версия отличная моей jre1.8.0_201)

Далее вы просто пишите keytool.exe и нажимаете Enter, в результате чего вы увидите справку по утилите.

Так же утилиту keytool.exe вы можете запускать и в оболочке PowerShell. Откройте ее от имени администратора или другого пользователя с аналогичными правами. Для этого в оболочке введите:

cd «C:\Program Files (x86)\Java\jre1.8.0_201\bin»

После чего введите .\keytool.exe

Команды и примеры использования утилиты Keytool

• Получение справки по утилите Keytool. Первое, что я хочу, чтобы вы научились, это использование справки, чтобы представлять, как строится конструкция команд и их возможности. Вводим просто Keytool, у вас появятся основные ключи, которые покажут, что вы можете делать через утилиту

C:\Program Files (x86)\Java\jre1.8.0_201\bin>keytool.exe
Key and Certificate Management Tool

-certreq — генерация CSR запроса
-changealias — изменить запись алиаса
-delete — удалить запись
-exportcert — экспортировать сертификат
-genkeypair — генерация пары ключей
-genseckey — генерация секретного ключа
-gencert — генерация сертификата из csr запроса
-importcert — импорт сертификата или цепочки
-importpass — импорт паролей
-importkeystore — импорт одной или нескольких записей из другого Keystore
-keypasswd — изменить пароль у записи
-list — список всех записей в хранилище сертификатов
-printcert — вывод содержимого сертификата
-printcertreq — вывод содержимого CSR запроса
-printcrl — вывод содержимого CRL запроса
-storepasswd — изменить пароль на Keystore

Далее, чтобы получить дополнительные ключи по командам из первого списка, вам необходимо добавить ключ -help. Например, я хочу понять как строится команда по генерации пары ключей, для этого я пишу:

keytool.exe -genkeypair -help и получаю вывод дополнительных ключей:

-alias alias name of the entry to process
-keyalg key algorithm name
-keysize key bit size
-sigalg signature algorithm name
-destalias destination alias
-dname distinguished name
-startdate certificate validity start date/time
-ext X.509 extension
-validity validity number of days
-keypass key password
-keystore keystore name
-storepass keystore password
-storetype keystore type
-providername provider name
-providerclass provider class name
-providerarg provider argument
-providerpath provider classpath
-v verbose output
-protected password through protected mechanism

• Создание самоподписного сертификата и файла хранилища сертификатов. Наверняка, это самый популярный сценарий, для чего используется утилита Keytool. Чтобы сгенерировать пару ключей в новом Keystore или уже существующем, вам необходимо выполнить:

keytool -genkey -alias pyatilistnik.org -keypass 12345678 -keyalg RSA -validity 730 -keystore keystore.jks -keysize 2048

В результате выполнения данной команды, у вас будет создан самоподписный сертификат, сроком на два года (730 дней), ключи будут RSA в виде 2048 бит, с псевдонимом pyatilistnik.org. Располагаться они будут в хранилище ключей с именем keystore.jks, если файла нет ,то он будет создан автоматически. Закрытый ключ будет защищен паролем установленным в ключе -keypass, в данном примере 12345678. Открытый ключ, это и будет самоподписанный сертификат. Советую вам самим устанавливать все параметры, в противном случае при генерации вы будите отвечать на дополнительные вопросы, и если вы все оставите по умолчанию, то например параметры по умолчанию для алиаса будут mykey, или алгоритм шифрования SHA1withDSA.

Во время генерации вам необходимо заполнить следующую информацию:

• What is your first and last name — Сюда можно записать адрес сайта
• What is the name of your organizational unit? — Как называется ваша организационная единица, можно указать название организации
• What is the name of your organization? — имя вашей организации
• What is the name of your City or Locality? — Географическое расположение
• What is the name of your State or Province? — штат или область
• What is the two-letter country code for this unit? — Страна, заполняется в виде двух букв в международном стандарте
• Distinguished Name — тут просто пишем Yes

В результате чего у вас будет сгенерирован ваш сертификат, и если файла keystore.jks не было, то он будет создан.

• Создание стандартного хранилища сертификатов отдельной командой:

KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());

• Создание хранилища формата PKCS12