Хочется совсем не странного: защитить приватный ключ шифрования паролем. Но не простым, а таким, чтобы он был поделен на две части, и каждой из частей владел только один человек. Нужно для того, чтобы для подписи сертификатов своё одобрение выдавали два человека (таковы местные правила).
Самый простой вариант — вводить пароль двоим сразу, с одного логического терминала (скажем, screen в linux). Но это не шибко безопасно и жуть как неудобно. Есть ли классические решения лучше?
Второй вариант — хранить ключ в зашифрованном дважды хранилище, первый раз с первым паролем, второй раз с другим. Проблемы аналогично предыдущему.
Здравствуйте, SkyDance, Вы писали:
SD>Хочется совсем не странного: защитить приватный ключ шифрования паролем. Но не простым, а таким, чтобы он был поделен на две части, и каждой из частей владел только один человек.
Попробую пояснить на примере аналогий.
Есть сейф (банковская ячейка). Чтобы ее открыть, нужно, чтобы два человека одновременно (или с небольшой разницей по времени) совершили два неких аутентификационных действия. Суть каждый человек повернул свой ключ в замке этой банковской ячейки.
Именно эту процедуру хочется реализовать для "открывания" приватного ключа сертификационного центра. Чтобы поодиночке (без активного действия второго человека) люди не могли подписывать сертификаты.
Раньше было сделано так: ключ лежит в контейнере, который зашифрован ключом одного из этих людей. Но ключ также зашифрован паролем (второго человека). Проблема этого подхода в том, что после того, как первый расшифровал контейнер, второй получает доступ к расшифрованному контейнеру — суть к ключу (и может его использовать неограниченное количество раз).
Сейчас сделано так: каждый из двух ответственных знает только половину пароля. Они вводят эти половины по очереди на secure terminal. Неудобство в том, что этот secure terminal — физический, а значит, требуется личное присутствие обоих людей в одном месте (возле корпоративного сейфа).
Я знаю, что есть хардверные решения (два или более синхронизированных хардверных ключа, на которых нужно вводить свой пароль каждому "хранителю"), но нам надо без этих железяк и на опен сорс.
Здравствуйте, SkyDance, Вы писали:
SD>Я знаю, что есть хардверные решения (два или более синхронизированных хардверных ключа, на которых нужно вводить свой пароль каждому "хранителю"), но нам надо без этих железяк и на опен сорс.
Самое правильное решение — требовать ДВУХ сертификатов в клиентском софте.
Но можно сделать и по-другому:
1) Генерируется CSR (Certificate Signing Request).
2) CSR подписывается приватным ключом первого ключника.
3) CSR подписывается приватным ключом второго ключника.
Теперь имеем CSR и его две подписанные копии. Теперь на сервере просто проверяем обе подписи и генерируем сертификат, подписанный уже ключом сервера.
Вдобавок, в CSR можно включить информацию (хэши) двух промежуточных CSR.
C>Самое правильное решение — требовать ДВУХ сертификатов в клиентском софте.
Все, что нам нужно, это просто убедиться, что оба ключника лично разрешили подписать сертификат. Конкретный юз-кейс — личные сертификаты для VPN соединения. Их должны подписать два офицера по безопасности (как, кстати, правильно перевести security officer?)
Два сертификата тот же openVPN не понимает.
C>Теперь имеем CSR и его две подписанные копии. Теперь на сервере просто проверяем обе подписи и генерируем сертификат, подписанный уже ключом сервера.
В таком варианте ключ сервера лежит в открытом виде и может быть доступен кому-то одному. Нам как раз нужно защитить "ключ сервера" в твоей терминологии. Чтобы им можно было воспользоваться только когда оба ключника это разрешили.
Здравствуйте, SkyDance, Вы писали:
SD>Попробую пояснить на примере аналогий.
аналогии вещь конечно замечательная
SD>Я знаю, что есть хардверные решения (два или более синхронизированных хардверных ключа, на которых нужно вводить свой пароль каждому "хранителю"), но нам надо без этих железяк и на опен сорс.
тебе нужно готовое решение, которое запросит половинки пароля на разных компах и затем расшифрует данные? или просто такая идея не пришла в голову?
Здравствуйте, SkyDance, Вы писали:
SD>Хочется совсем не странного: защитить приватный ключ шифрования паролем. Но не простым, а таким, чтобы он был поделен на две части, и каждой из частей владел только один человек. Нужно для того, чтобы для подписи сертификатов своё одобрение выдавали два человека (таковы местные правила).
С наскоку вспомнить не могу, но по-моему именно такая задача была в курсе критпто 1 на курсере у Бонеха.
И вроде бы она решается классическим способом для двух персон, но если больше — то с решением проблемы.
В принципе, наколенное решение
1. Сертификат шифруется ключем К
2. Генерится К1 длиной ||K||
3. К2 вычисляется как K2 = K ^ K1
Без ввода обоих ключей К не получить. Информация отдельно о К1, либо о К2 не дает никакой информации о К.
Здравствуйте, pva, Вы писали:
pva> 1. Сертификат шифруется ключем К pva> 2. Генерится К1 длиной ||K|| pva> 3. К2 вычисляется как K2 = K ^ K1
pva> Без ввода обоих ключей К не получить. Информация отдельно о К1, либо о К2 не дает никакой информации о К.
Тут есть еще организационная часть. ТС хочет, как я понял, некую "магию", с помощью которой никто не имел бы доступа к К или расшифрованному сертификату. А это по-моему невозможно. Тут можно продложить только схему с доверенной third party, которая будет проверять запрос, подписанный обоими ответственными лицами, и выдавать сертификат.
Здравствуйте, wildwind, Вы писали:
W>Тут есть еще организационная часть. ТС хочет, как я понял, некую "магию", с помощью которой никто не имел бы доступа к К или расшифрованному сертификату. А это по-моему невозможно. W>Тут можно продложить только схему с доверенной third party, которая будет проверять запрос, подписанный обоими ответственными лицами, и выдавать сертификат.
Third party может быть смарткартой/криптотокеном, например. Тогда, условно конечно, требования будут выполнены.
При этом политику управления ключами можно реализовать любую, начиная от списка паролей. Причем сам сертификат не покинет "доверенную зону".
На первый взгляд он по функциям такой же, как и карманный токен, только большой и обвешанный сертификациями. То есть может асимметрично зашифровать/подписать произвольный блок данных. Или он действительно может взять на себя поддержку PKI и генерировать X.509?
Здравствуйте, wildwind, Вы писали:
W>На первый взгляд он по функциям такой же, как и карманный токен, только большой и обвешанный сертификациями. То есть может асимметрично зашифровать/подписать произвольный блок данных. Или он действительно может взять на себя поддержку PKI и генерировать X.509?
Там реально PKI — его как раз чаще всего и используют именно для этого. Т.е. он подключен к управляющему компу и генерирует сертификаты и списки отзыва.
Здравствуйте, wildwind, Вы писали:
W>Существуют такие токены, которые умеют подписывать сертификаты? Я не встречал.
Существуют такие смарткарты, которые позволяют свои модули писать. А там уже можно реализовать нужную логику.
