Контейнер, токен для сертификатов и ключей openssh

Или софтовые реализации наподобие контейнеров криптопро?

«Софтовая реализация» это когда ты файл ключа с passphrase сгенерил. Ничего другого от софтовых реализаций в принципе не получишь, разница только в украшательствах.

Нет, софтовая реализация, это когда у тебя есть контейнер, в котором лежит ключ и сертификат openssh. Контейнер защищен парольной фразой. Сам контейнер может располагаться в файле или на токене (тот же файл, по сути, просто в токене).

Доступ ssh к сертификату и ключу осуществляет библиотека через ssh-agent.

По сравнению с ~/.ssh/* , во первых, нет нужды отдельно таскать с собой все эти файлы, достаточно иметь один файл-контейнер, да еще в токене, вместе с другими x509 сертификатами. Во вторых, нет нужды держать файлы ключа и сертификата на компьютере. Воткнул токен - есть контейнер. Вытащил - нет.

А, ну я это всё и обобщил как украшательства - удобства/неудобства доставки файла в нужное место, но почти никакой связи с безопасностью. Никакой защиты от кражи ключа через скомпрометированный комп.

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

В большинстве случаев компьютер во время работы никто и не компрометирует во время работы. Просто если ключи все время лежат в директории ~./ssh, рано или поздно их можно скопировать или забыть где-то вместе с компьютером.

Хотелось бы иметь токен - воткнул и есть, вытащил и нет. В том же криптопро есть контейнеры, в том числе и некопируемые с токена. И в этих контейнерах внутри полная свобода - гостовые ключи, например, о которых токен даже не догадывается. Так почему бы не сделать нечто подобное для сертификатов и ключей openssh?

Юбикей банальный? Вроде всё умеет, что только можно хотеть.

Ну, да. Полтосик денежных знаков страны двух падающих небоскрёбов и дело в шляпе. Немного непонятно: а почему нужен именно токен? Не, ну когда дело на устройстве налажено, то - это хорошо. Присунул и наши в дамках. Но тут же речь немножко о другом. Тут речь о том, что «комп. может быть утрачен». Результат - снова геморрой и мучительное напряжение очень дальних уголков памяти в лейтмотиве «когда-то я это делал, но разрази меня гром не помню как». Ключи-то есть, на утраченном девайсе «враг не пройдёт», но и самому проблем и занятий поднасыпало. Да ещё если для примастыривания этого эксклюзивного токена надо использовать не менее эксклюзивные подходцы. Так и всё же, откройте тайну: чем тот же, упомянутый выше контейнер luks на обыкновенной флешке хуже? Уж тут-то и вспоминать ничего не надо даже при полной амнезии. В гугел глянул как с тем luks-ом обращаться и за пяток минут вспомнил.

В большинстве случаев компьютер во время работы никто и не компрометирует во время работы. Просто если ключи все время лежат в директории ~./ssh, рано или поздно их можно скопировать или забыть где-то вместе с компьютером.

Хорошо, это чуточку повышает защиту от разных неосторожностей, каждый сам решает насколько это ему существенно.

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

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

Ну, да. Полтосик денежных знаков страны двух падающих небоскрёбов и дело в шляпе.

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

Кстати не полтосик, а два полтосика по-хорошему. А то и три. Запасные в сейфе на случай порчи/потери используемого.

Немного непонятно: а почему нужен именно токен?

Чтобы не пришлось спешно отзывать и менять все ключи, если появилось подозрение на то, что на твоём компе побывал троян. И вообще

Да ещё если для примастыривания этого эксклюзивного токена надо использовать не менее эксклюзивные подходцы.

Да вроде никаких подходцев не надо, всё стандартными средствами настраивается.

Так и всё же, откройте тайну: чем тот же, упомянутый выше контейнер luks на обыкновенной флешке хуже? Уж тут-то и вспоминать ничего не надо даже при полной амнезии. В гугел глянул как с тем luks-ом обращаться и за пяток минут вспомнил.

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

Ну и ещё отличие так сказать управленческое. Если ты это делаешь не для себя, а для сотрудников. В юбикее ты можешь быть уверен. А в том, что сотрудник будет грамотно пользоваться всеми этими люксами, а не поставит туда пароль 123 и вообще не скопирует ключ для удобства куда-нибудь поближе, уверенным быть сложней.

Ну во первых нет сертификатов openssh, насчёт токенов всё что на openpgp умеет чисто в ключи rsa и пр и дружит с OpenSSH через gpg из коробки

Юбикей банальный? Вроде всё умеет, что только можно хотеть.

Ну во первых, не банальный, а полноценный. Есть такой, протестировал.

А во вторых, ничего он не умеет, кроме как хранить rsa ключи до 2048 бит.

Сертификаты openssh? нет known-host? нет

ключи ecdsa или ed25519? нет

Немного непонятно: а почему нужен именно токен?

Потому что:

1. защита от копирования ключа (контейнера). Токен/флешку ведь тоже можно потерять. Мне очень нравится система трижды пин-код введен неверно - прощай контейнер.

2. нет нужды в монтировании/отмонтировании девайса. Вставил и пользуйся. Вытащил токен в любой момент и доступ пропал.

Тут речь о том, что «комп. может быть утрачен».

Да, но это рабочий комп(ы).

Ключи-то есть, на утраченном девайсе «враг не пройдёт», но и самому проблем и занятий поднасыпало.

никаких проблем. pki есть, просто выписал новый сертификат и записал в новый токен.

От забывчивости спасает скриптование операций. Я просто вызываю скрипт с логином и он сам мне все делает. Забыл, ну посмотри в скрипт.

Так и всё же, откройте тайну: чем тот же, упомянутый выше контейнер luks на обыкновенной флешке хуже?

1. Плохо защищает от копирования во время работы.

2. Требует рута.

Частично я это решил, создав банальный зашифрованный зип и скриптик, который его через archivemount монтирует, добавляет в ssh-agent и сразу отмонтирует. Теперь не нужно рута и в рабочем режиме ключи недоступны. Но раздражает кривизна archivemount (не работает с p7zip зашифрованными архивами, не отрабатывает неправильный пароль).

В гугел глянул как с тем luks-ом обращаться и за пяток минут вспомнил.

лукс хорош, но именно в этой задачи он не совсем удобен.

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

Криптопро работает со своим контейнером. Ему что токен, что реестр, что файл.

Есть програмный контейнер, его всегда можно програмно скопировать, эта возможность тут принципиально не может быть ограничена.

Попробуй. Создай контейнер криптопро с битом некопируемости и скопируй. Мне вот в налоговой ЭЦП так сделали, было бы круто скопировать в файл, у меня не вышло и в интернетах что-то молчок.

Ну и ещё отличие так сказать управленческое. Если ты это делаешь не для себя, а для сотрудников. В юбикее ты можешь быть уверен. А в том, что сотрудник будет грамотно пользоваться всеми этими люксами, а не поставит туда пароль 123 и вообще не скопирует ключ для удобства куда-нибудь поближе, уверенным быть сложней.

+1

Тебе надо использовать OpenPGP интерфейс.

Ну во первых нет сертификатов openssh

В смысле нет?

man sshd_config

     HostCertificate
             Specifies a file containing a public host certificate.  The cer‐
             tificate's public key must match a private host key already spec‐
             ified by HostKey.  The default behaviour of sshd(8) is not to
             load any certificates.

man ssh-keygen

CERTIFICATES
     ssh-keygen supports signing of keys to produce certificates that may be used for user or host authentication.  Certificates consist of a public key, some identity information, zero
     or more principal (user or host) names and a set of options that are signed by a Certification Authority (CA) key.  Clients or servers may then trust only the CA key and verify its
     signature on a certificate rather than trusting many user/host keys.  Note that OpenSSH certificates are a different, and much simpler, format to the X.509 certificates used in
     ssl(8).

     ssh-keygen supports two types of certificates: user and host.  User certificates authenticate users to servers, whereas host certificates authenticate server hosts to users.  To
     generate a user certificate:

Тебе надо использовать OpenPGP интерфейс.

там тоже x509.

https://docs.yubico.com/hardware/yubikey/yk-5/tech-manual/yk5-apps.html#openpgp тут в списке алгоритмов есть всё, что ты хочешь. Про x509 не понял.

Там только rsa ключи. Да, до 4k, но, например, в федоре вообще их отключили из хостов.

А еще есть сертификаты openssh иони там свои, не X509. Их использование позволяет настроить доступ целиком в системе, без троганий ~/.ssh плю можно вдавать урезанные по правам сертификаты.

update

ed25519 таки есть. Я просто настраивал PIV и там их нет.

ed25519 (sign / auth only)

У меня совершенно нет желания ставить себе всё это и реверсить как оно работает. Но комп это не магическое устройство, поэтому апеллции к чудесным программам я отклоняю. Если контейнер представлен чем-то, записанным на обычный компьютерный диск или флешку - то воспрепятствовать его копированию программой, запущеной на том же компе и имеющей доступ к этому носителю информации - принципиально невозможно. Максимум, что они могли сделать - это запутать способ хранения контейнера (security through obscurity), но это не настоящее препятствие, а только преграда от ленивых, которым будет влом изучать как оно там устроено.

Мне вот в налоговой ЭЦП так сделали,

Возможно тебе таки выдали аппаратный токен (специальное устройство с собственным криптографическим микроконтроллером внутри), а не програмный контейнер. Где-то читал что планируется полный переход на них где-то там.

Если контейнер представлен чем-то, записанным на обычный компьютерный диск или флешку

контейнер записан в токен с установленным битом неизвлекаемости.

Возможно тебе таки выдали аппаратный токен

я его сам принес, рутокен ecp. но внутри токена теперь контейнер криптопро.

контейнер записан в токен с установленным битом неизвлекаемости

Это называется запретом на экспорт. КриптоПРО позволяет перемещать сертификаты или запрещает их перемещать. Но только средствами самой КриптоПРО - запрет на экспорт распространяется только на программное обеспечение от КриптоПРО. Это совершенно не значит, что экспорт содержимого не может быть осуществлён. Сродни связки ключей. Они есть, но при переносе на другое устройство в исходном состоянии они по идее будут непригодными. В этом случае, когда «хозяйский софтец» не может помочь, сертификаты извлекаются в рабочем процессе. Об этом вам и рассказывают. Словосочетание «бит неизвлекаемости» - это «быстрый уровень вхождения в проблему», как бубунта после виндовсы.

Ну и ещё отличие так сказать управленческое. Если ты это делаешь не для себя, а для сотрудников. В юбикее ты можешь быть уверен. А в том, что сотрудник будет грамотно пользоваться всеми этими люксами, а не поставит туда пароль 123 и вообще не скопирует ключ для удобства куда-нибудь поближе, уверенным быть сложней.

Не очень-то понятно со стороны реализатора этого всего мероприятия. Со стороны не управленца, а того, кто всё это будет делать. Вот у вас получается, что конечный пользователь и сам себе контейнеры создаёт, и пароли на них назначает. А ключики для ssh этот пользователь тоже сам себе генерирует? Или вот возьмём, например, токен. И возьмём какой-нибудь дистрибутив. Debian-а или его производных, или там что-то из RedHat и тоже его производных. Установим на подходящее железо и радостно всунем этот токен в подходящий порт. И вот с этого токена вдруг и неожиданно сертификаты взяли и обслужили некую попытку соединения. Вы какой дистрибутив порекомендуете взять, чтоб его без всякого допиляжа и присовывания всевозможных дров можно было бы использовать для всевозможных токенов? Ну, например, для rutoken lite дров добавлять не надо. Ан, всё равно при присовывании этого токена сертификаты всё равно придётся чем-то читать и как-то и кому-то всё это дело настраивать. Пользователю? Ну, если пользователь сам себе luks-овые контейнеры мастырит, то ему и с токенов инфу почитать - это как два пальца об асфальт. вы не могли бы объяснить от кого вы собственно секретутности усиливаете? Я этого момента не понял.

Не знаю, что там с rutoken lite, но вообще для токенов есть стандартные интерфейсы и протоколы и ничего там пилить не надо, обычный ssh и gpg поддерживают. Российские криптотокены вероятно нужны для русской посконной гостовской криптографии, с ней, конечно, будут проблемы, но то такое.

для токенов есть стандартные интерфейсы и протоколы и ничего там пилить не надо

А вы не могли бы в конкретных числах озвучить количество этих самых «стандартных» интерфейсов для токенов?

Я не Legioner, но подскажу.

Есть библиотека с интерфейсом pkcs11 , которую используют ssh, gpg, браузеры и т.д. В рутокен лайт она тоже есть, но рутокен лайт не поддерживает rsa, а только госты, так что в большинстве случаев мимо. Рутокен эцп держит и Rsa и гост, что выглядит предпочтительней.

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

Не очень-то понятно со стороны реализатора этого всего мероприятия. Со стороны не управленца, а того, кто всё это будет делать.

Да как обычно реализуется pki. Есть сотрудник, который выписывает сертификаты и ключи. Иногда ключ на токене создает пользователь. В случае с ssh это плохая идея. В ssh весь процесс создания ключа и сертификата должен по идее проходить в отделе безопасности. Пользователю просто выдают токен.

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

Не создает, а копирует, если может. Мне вот в тендерной площадке создали контейнер криптопро на токене, а я взял и скопировал его в реестр и вертел ваш токен…

А ключики для ssh этот пользователь тоже сам себе генерирует?

Нет. Пользователь получает или приносит токен, на котором генерируется ключ и сертификат.

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

А пинкод на токен они тоже сами ввели?

Вы какой дистрибутив порекомендуете взять, чтоб его без всякого допиляжа и присовывания всевозможных дров можно было бы использовать для всевозможных токенов? Ну, например, для rutoken lite дров добавлять не надо. Ан, всё равно при присовывании этого токена сертификаты всё равно придётся чем-то читать и как-то и кому-то всё это дело настраивать. Пользователю? Настраивает служба техподдержки, как обычно. Драйверы на большинство токенов уже есть в дистре. Библиотека pks11 на рутокен или другие токены, это просто один файл, который бросают в /usr/lib64

Все остальное есть в дистрибутиве.

Ну, если пользователь сам себе luks-овые контейнеры мастырит, то ему и с токенов инфу почитать - это как два пальца об асфальт. вы не могли бы объяснить от кого вы собственно секретутности усиливаете? Я этого момента не понял.

Секурность заключается в том, что нет средств извлечь/скопировать ключ с токена. Поэтому если я пришел и ушел с токеном, то значит и ключ со мной ушел. Уволился, сдал токен - ну значит и подпись отдал.

А с луксом это просто файлы, которые во время работы никак не защищены.

Это называется запретом на экспорт. КриптоПРО позволяет перемещать сертификаты или запрещает их перемещать. Но только средствами самой КриптоПРО - запрет на экспорт распространяется только на программное обеспечение от КриптоПРО. Это совершенно не значит, что экспорт содержимого не может быть осуществлён. Сродни связки ключей. Они есть, но при переносе на другое устройство в исходном состоянии они по идее будут непригодными. В этом случае, когда «хозяйский софтец» не может помочь, сертификаты извлекаются в рабочем процессе. Об этом вам и рассказывают. Словосочетание «бит неизвлекаемости» - это «быстрый уровень вхождения в проблему», как бубунта после виндовсы.

Это все замечательно, но это лучше, чем ничего. В принципе и токен, это тоже по сути эфемерный «бит неизвлекаемости». Кто мешает попилить чип и прочитать его послойно? А можно взломать прошивку. Хрен знает, сколько там дыр. Да и сами алгоритмы взламывают со временем. Но в настоящий момент нет (широко)известных способов скопировать контейнер криптопро, как нет (широко)известных способов вытащить ключи из токена. Поэтому, это лучше, чем лукс-контейнер, который можно скопировать командой dd. Вот что я хотел сказать.

действительно, прикольно, я всегда в контексте certificate подставлял x509. openpgp работает через gpg, там нет x509 оно эмулируется через opensc

В общем, в итоге пришел вот к такому костылю.

Ключи упаковываются в запароленный 7zip архив. 7zip, потому что он умеет шифровать файловую структуру, имена файлов.

Архивируем 7z a -p -mhe container.dat ~/.ssh/*

Затем настраиваем переменные в скрипте и используем с любой флешки/шары.

Плюсы - не нужны рут, поддержка luks и fuse. Все от пользователя и все есть везде.

Минусы - ssh-add не умеет грузить сертификат из stdin. Соответственно, приходится распаковывать, грузить и удалять. Понятно, что флешка своя и уносится с собой, но криво, конечно.

По идее, было бы здорово или пропатчить ssh-agent или использовать биндинг в питон https://docs.paramiko.org/en/stable/api/agent.html

Вроде там есть нужные функции. Но пока так.

#!/bin/sh

SOURCE="./container.dat"
TMPDIR="./tmp"
SSHADD="/bin/ssh-add"
SHRED="/bin/shred"
XARGS="/bin/xargs"
FIND="/bin/find"
RM="/bin/rm"
P7Z="/bin/7z"

EXTRAFILES="ssh/config ssh/known_hosts"
KEY1="ssh/id_ed25519"
CERT1="ssh/id_ed25519-cert.pub"

KEY2="ssh/id_rsa"

#comment next line if clear ssh-agent unwanted
${SSHADD} -D

for i in 1 2 3 4
do
    KEY=KEY$i
    CERT=CERT$i

    if [ -n "${!KEY}" ] && [ -n "${!CERT}" ]
    then
	echo "Load key/cert"
	echo Password:
	${P7Z} x -o${TMPDIR} -aoa ${SOURCE} "${!KEY}" "${!CERT}" > /dev/null
	${SSHADD}  "${TMPDIR}/${!KEY}"
	${SHRED} -fuz -n 1 "${TMPDIR}/${!KEY}" "${TMPDIR}/${!CERT}"
    fi

    if [ -n "${!KEY}" ] && [ -z "${!CERT}" ]
    then
	echo "Load key only"
	echo Password:
	${P7Z} e -so ${SOURCE} "${!KEY}"  | ${SSHADD} -
    fi
done

    if [ -n "${EXTRAFILES}" ] 
    then
	echo "Extract ${EXTRAFILES}"
	echo Password:
	${P7Z} x -o${TMPDIR} -aoa "${SOURCE}" ${EXTRAFILES} > /dev/null
    fi

т.е. обычный gpg тебе не зашел?

В принципе и токен, это тоже по сути эфемерный «бит неизвлекаемости». Кто мешает попилить чип и прочитать его послойно?

Никто не мешает, о защите от человека, которому этот токен дали в руки, речи и не шло (ну, почти, да это «лучше чем ничего»). Речь шла о защите от злонамеренного софта на компе, куда ты этот токен вставишь. Злонамеренный софт распилить чип очевидно не может, у него есть только usb интерфейс. А так я даже не уверен, что нельзя просто подключиться к каким-нить отладочным контактам внутри корпуса токена и безо всяких распиливаний всё прочитать - потому что это не тот вектор атаки, для защиты от которого токены делают.

А можно взломать прошивку. Хрен знает, сколько там дыр.

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

т.е. обычный gpg тебе не зашел?

Я с ним пока не разобрался. Но одно полнял, что сертификат openssh в него не положить. И вообще сертификат в ssh-agent не загрузить, если не положить ключ и сертифкат в одну директорию с именами key и key-cert.pub. Это, конечно, скорбно, учитывая, что ключ можно подгружать тыщей способов, начиная с stdin и заканчивая токенами.

Никто не мешает, о защите от человека, которому этот токен дали в руки, речи и не шло.

Ну так для меня данная задача является комплексной. И проблемы у меня вовсе не исчерпываются защитой от софта.

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

Есть проблемы с людьми, с забытыми и сданными в утиль винчестерами, с собственными кривыми ручками, когда отформатировал флешку или сломал токен. И на каждую из этих проблем должен быть ответ.