Тут несколько сложнее. Или проще — как поглядеть.
Сама по себе работа с железным USB толку не даст, поскольку протокол низкоуровневый и через него всего лишь гоняются какие-то данные. Ну то есть докопаться до каких-то данных, которые хранятся в токене шибко осмысленным способом не получится. Разве что при помощи фаззинга найти какие-то команды, на которые операционная система карты или токена (это одно и то же по сути) будет откликаться.
Эти самые команды как раз описаны в стандарте ISO-7816, называются APDU-команды.
Так что вопрос не столько в том, что фильтруется на уровне USB протокола, а существуют ли в карточной операционной системе команды, способные выдавать наружу неизвлекаемые ключи. Или нет ли какого бага, который позволяет это делать.
На сегодняшний день и КриптоПро, и ViPNet отлично умеют работать с неизвлекаемыми ключами на токенах и картах. Только надо правильным образом создавать ключи (контейнеры).
По правде говоря, в той статейке я не увидел, что скопированы какие-либо ключи. Человек скопировал файлы, хранящиеся в файловой системе токена. Да, это он сделал.
Можно, кстати, было сделать все гораздо проще — для работы с файловой системой и других действий вовсе не нужно реверсить библиотеки. Всего лишь нужно изучить стандарт ISO-7816. Но что сделано, то сделано. В каком-то смысле автор упростил себе жизнь, получив более высокоуровневые функции.
Только вот в теме хранения ключей на токене он так и не разобрался. И не разбирался.
Объекты в файловой системе имеют разные атрибуты безопасности. Некоторые можно читать (и копировать) без PIN-кода. Другие — можно читать и копировать по предъявлении PIN-кода.
Но вот сгенерированные на токене неизвлекаемые ключи хранятся в таких объектах, атрибуты безопасности которых не дают возможности их прочитать даже зная PIN-код.
Такая возможность есть и сейчас. Нужно использовать ключевые носители с собственной криптографией "на борту". Тогда ключи генерируются вообще не на компьютере
В основном да. Но есть интернет-магазины, которые доставят любую модель. Если у них нет в прайсе, привезут под заказ. Если какие-то проблемы конкретные будут, пишите на info@rutoken.ru
1. Мы все же про шифрование или про подпись?
2. GPG не может использоваться для УКЭП по нескольким причинам:
Причина первая. Для УКЭП необходимо средство электронной подписи (ЭП), прошедшее оценку соответствия, то есть сертифицированное ФСБ. По очевидным причинам (как минимум, отсутствие реализации ГОСТ подписи и хеширования в GPG) сертификация такая невозможна.
Причина вторая (скорее даже первая). УКЭП основана на инфраструктуре открытых ключей (PKI то есть). GPG — это альтернативная инфраструктура. Тут нет удостоверяющих центров, квалифицированных сертификатов и т.п. вещей. Есть подписанные участниками публичные ключи других участников — то есть совершенно иная модель доверия.
Этих двух основных причин в принципе достаточно, хотя можно припомнить и еще.
3. Для обеспечения юридической значимости переписки не обязательно применять УКЭП. Об этом написано в 63-ФЗ «Об электронной подписи». Таким образом, можно заключить соглашение, на основании которого переписка, подписанная через GPG, будет признаваться юридически значимой даже на зарубежных алгоритмах подписи.
ЭП дает уверенность в аутентичности письма, то есть в том, что автор является тем, за кого себя выдает. Кроме того, ЭП обеспечивает целостность и неизменность сообщения.
Cуществует масса атак, связанных с подделкой адреса отправителя (spoofing, forging). Например, таким образом могут доставляться ссылки на фишинговые сайты и загрузку вредоносов.
Поэтому, если среди доверенных лиц использовать подпись почты, такие письма будут сразу видны. Это что касается подписи.
Но есть же еще и шифрование писем, которое тоже может использоваться. Как минимум, при получении доступа к почтовому ящику злоумышленник не сможет читать переписку. Хорошая защита и на случай утери ноутбука, например.
Кроме почты можно защищать сообщения в мессенджерах, шифровать файлы, создавать зашифрованные контейнеры и т.д.
Отдельно стоит упомянуть, что GPG используется и для подписи DEB пакетов. Это чуть ли не единственный, если не ошибаюсь, способ их подписывать.
Так что почта — это самый очевидный способ применения GPG и разобрана в качестве примера.
Возможно Вы удивитесь, но «основано на реальных событиях». Правда дело происходило под виндой. Некий регулятор потребовал у некого заказчика, чтобы доменная аутентификация была реализована на ГОСТ-алгоритмах. Под виндой вопрос решается при помощи ГОСТового CSP, а вот под Линуксами требуются такие танцы.
Мне самому такие требования от регулятора показались странными, но проще было сделать, чем объяснить, почему не.
Про многофакторную аутентификацию ведется масса холиваров, нередко замешанных на маркетинговом буллшите. Часто путают 2-факторную аутентификацию, 2-этапную верификацию, многоканальную аутентификацию и т.д.
С моей точки зрения в такой ситуации следует полагаться на авторитетные официальные источники. Например вот: csrc.nist.gov/glossary/term/Multi_Factor-Authentication
C Astra Linux дела обстоят хорошо. Прошли очередной раунд тестирования на совместимость с Astra Linux Common Edition (версии 1.10,1.11,2.12) и Special Edition (версии 1.4,1.5).
Сертификат ФСТЭК на ПАК Рутокен есть и действует. Так что гос.заказчиков можно успокоить. Если есть какие-то сомнения, задавайте вопросы. Если надо будет потестировать какую-то конкретную конфигурацию — обращайтесь, рассмотрим.
Сама по себе работа с железным USB толку не даст, поскольку протокол низкоуровневый и через него всего лишь гоняются какие-то данные. Ну то есть докопаться до каких-то данных, которые хранятся в токене шибко осмысленным способом не получится. Разве что при помощи фаззинга найти какие-то команды, на которые операционная система карты или токена (это одно и то же по сути) будет откликаться.
Эти самые команды как раз описаны в стандарте ISO-7816, называются APDU-команды.
Так что вопрос не столько в том, что фильтруется на уровне USB протокола, а существуют ли в карточной операционной системе команды, способные выдавать наружу неизвлекаемые ключи. Или нет ли какого бага, который позволяет это делать.
Можно, кстати, было сделать все гораздо проще — для работы с файловой системой и других действий вовсе не нужно реверсить библиотеки. Всего лишь нужно изучить стандарт ISO-7816. Но что сделано, то сделано. В каком-то смысле автор упростил себе жизнь, получив более высокоуровневые функции.
Только вот в теме хранения ключей на токене он так и не разобрался. И не разбирался.
Объекты в файловой системе имеют разные атрибуты безопасности. Некоторые можно читать (и копировать) без PIN-кода. Другие — можно читать и копировать по предъявлении PIN-кода.
Но вот сгенерированные на токене неизвлекаемые ключи хранятся в таких объектах, атрибуты безопасности которых не дают возможности их прочитать даже зная PIN-код.
Она может быть записана в сертификат, но не является бесплатной. Другое дело, что цена ее спрятана, но существенно ниже, чем полная лицензия
Такая возможность есть и сейчас. Нужно использовать ключевые носители с собственной криптографией "на борту". Тогда ключи генерируются вообще не на компьютере
2. GPG не может использоваться для УКЭП по нескольким причинам:
Причина первая. Для УКЭП необходимо средство электронной подписи (ЭП), прошедшее оценку соответствия, то есть сертифицированное ФСБ. По очевидным причинам (как минимум, отсутствие реализации ГОСТ подписи и хеширования в GPG) сертификация такая невозможна.
Причина вторая (скорее даже первая). УКЭП основана на инфраструктуре открытых ключей (PKI то есть). GPG — это альтернативная инфраструктура. Тут нет удостоверяющих центров, квалифицированных сертификатов и т.п. вещей. Есть подписанные участниками публичные ключи других участников — то есть совершенно иная модель доверия.
Этих двух основных причин в принципе достаточно, хотя можно припомнить и еще.
3. Для обеспечения юридической значимости переписки не обязательно применять УКЭП. Об этом написано в 63-ФЗ «Об электронной подписи». Таким образом, можно заключить соглашение, на основании которого переписка, подписанная через GPG, будет признаваться юридически значимой даже на зарубежных алгоритмах подписи.
Cуществует масса атак, связанных с подделкой адреса отправителя (spoofing, forging). Например, таким образом могут доставляться ссылки на фишинговые сайты и загрузку вредоносов.
Поэтому, если среди доверенных лиц использовать подпись почты, такие письма будут сразу видны. Это что касается подписи.
Но есть же еще и шифрование писем, которое тоже может использоваться. Как минимум, при получении доступа к почтовому ящику злоумышленник не сможет читать переписку. Хорошая защита и на случай утери ноутбука, например.
Кроме почты можно защищать сообщения в мессенджерах, шифровать файлы, создавать зашифрованные контейнеры и т.д.
Отдельно стоит упомянуть, что GPG используется и для подписи DEB пакетов. Это чуть ли не единственный, если не ошибаюсь, способ их подписывать.
Так что почта — это самый очевидный способ применения GPG и разобрана в качестве примера.
Мне самому такие требования от регулятора показались странными, но проще было сделать, чем объяснить, почему не.
С моей точки зрения в такой ситуации следует полагаться на авторитетные официальные источники. Например вот:
csrc.nist.gov/glossary/term/Multi_Factor-Authentication
Сертификат ФСТЭК на ПАК Рутокен есть и действует. Так что гос.заказчиков можно успокоить. Если есть какие-то сомнения, задавайте вопросы. Если надо будет потестировать какую-то конкретную конфигурацию — обращайтесь, рассмотрим.
habr.com/ru/company/aktiv-company/blog/457886
habr.com/ru/company/aktiv-company/blog/457886