Comments 111
Другими словами, практически любой ключ (сертификат?) можно извлечь из практически любого ходового носителя ЭЦП и скопировать, даже если стоит галка, что ключ неизвлекаемый?
Скопировать ключи можно не с любых токенов, но довольно с многих.
Галкой «неизвлекамый» — вы наварено называете «не экспортируемый». Стоит отметить, что наличие данной галки — обрабатывается только СКЗИ. А это значит, что если ключевая информация доступна в обход СКЗИ (например, ключ хранятся на флешке или в реестре), то она может быть успешно скопирована не смотря на галку.
Таким образом, ответить на ваш вопрос о возможности копирования ключей, для которых стоит галка «не экспортируемый» можно следующим образом:
— Если к ключевой информации можно обратится в обход СКЗИ, то не смотря на эту галку их скопировать можно.
Применительно к токенам обходные маневры расписаны в статье
Галкой «неизвлекамый» — вы наварено называете «не экспортируемый». Стоит отметить, что наличие данной галки — обрабатывается только СКЗИ. А это значит, что если ключевая информация доступна в обход СКЗИ (например, ключ хранятся на флешке или в реестре), то она может быть успешно скопирована не смотря на галку.
Таким образом, ответить на ваш вопрос о возможности копирования ключей, для которых стоит галка «не экспортируемый» можно следующим образом:
— Если к ключевой информации можно обратится в обход СКЗИ, то не смотря на эту галку их скопировать можно.
Применительно к токенам обходные маневры расписаны в статье
Только если он ГОСТовый. За бугром такой фигни нет — там понимают, чем электронный ключ отличается от флешки. А у нас поторопились импортозаместить.
Вступлюсь за наших разработчиков.
Игра с «экспортируемым» и «не экспортируемым» ключом справедлива практически для любых криптопровайдеров, что наших, что импортных. Можете ее легко повторить на чистой Windows.
Токены не являются чисто российским изобретением и применяются в том числе и за бугром. Более того и наши и импортные токены реализуют один стандарт — ISO/IEC 7816 + вариации, поэтому утверждать что наши токены хуже, не совсем корректно.
Игра с «экспортируемым» и «не экспортируемым» ключом справедлива практически для любых криптопровайдеров, что наших, что импортных. Можете ее легко повторить на чистой Windows.
Токены не являются чисто российским изобретением и применяются в том числе и за бугром. Более того и наши и импортные токены реализуют один стандарт — ISO/IEC 7816 + вариации, поэтому утверждать что наши токены хуже, не совсем корректно.
Заголовок доставил. Думается, что УЦ, который выдал экспортируемую КЭП за такое может получить от Минкомсвязь России.
Помню были времена, когда УЦ выдавали ЭП на дискетах. Вот тогда ЭП часто копировали и извлекали.
Помню были времена, когда УЦ выдавали ЭП на дискетах. Вот тогда ЭП часто копировали и извлекали.
Немного не так.
УЦ — обычно применяют распределенную схему генерации ключей. В данной схеме они ожидают от нас запрос на сертификат + подписанные бумажки, после получения которых они выпускают сертификат. Генерацию ключей и размещение их на носителях осуществляет пользователь.
Но когда вы «покупаете подпись», то вам скорее всего понадобятся СКЗИ и токены, вот здесь и проявляют себя продавцы в полную силу и начинают продавать то, что вам не надо.
УЦ — обычно применяют распределенную схему генерации ключей. В данной схеме они ожидают от нас запрос на сертификат + подписанные бумажки, после получения которых они выпускают сертификат. Генерацию ключей и размещение их на носителях осуществляет пользователь.
Но когда вы «покупаете подпись», то вам скорее всего понадобятся СКЗИ и токены, вот здесь и проявляют себя продавцы в полную силу и начинают продавать то, что вам не надо.
Я, к сожалению, на прошлой неделе тоже «вспомнил», когда подошла бухгалтер и положила дискетку. Найти флоппик тот еще квест. А Вы помню были времена говорите… :)
Нигде в законах и подзаконных ФСБ я не помню упоминания о том что ключи должны быть неэкспортируемые. Есть только требования выдавать на ключевых (читай защищенных) носителях. Сертификат у токенов есть — все ок. Так же я нигде не помню прямого запрета хранить УЦ закрытые ключи пользователей (если генерация происходит не самостоятельно — 90% как мне кажется, всех случаев)… Так что с точки зрения закона — все ок.
С точки зрения закона — ок. С точки зрения документации на СКЗИ — ок. С точки зрения потребителя — не ок.
Проблема в том, что описываемый в статье случай, это что-то из разряда ввода потребителя в заблуждение.
Проблема в том, что описываемый в статье случай, это что-то из разряда ввода потребителя в заблуждение.
В гос. учреждениях в связи с ФЗ-44 работу с ключами скинули на сами учреждения. Выдали ПО для генерации, а дальше сами. Сами флэшку ищем, сами генерируем, сами ставим. Обеспечить в этих условиях все требования по работе с СКЗИ просто элементарно не возможно.
Вспоминается забавная ситуация.
Удостоверяющий центр Федерального казначейства ведет прием документов на изготовление ключей. Подходит дедушка, приносит документы и флешку.
Оператор УЦ смотрит флешку и говорит, у вас вместо запросов на сертификат на флешки лежат закрытые ключи.
Дед — А какая разница?
Удостоверяющий центр Федерального казначейства ведет прием документов на изготовление ключей. Подходит дедушка, приносит документы и флешку.
Оператор УЦ смотрит флешку и говорит, у вас вместо запросов на сертификат на флешки лежат закрытые ключи.
Дед — А какая разница?
Автор, подскажите… какой именно функционал содержит апплет в аппаратной части? Точнее: можно ли с помощью него реализовать шифрование ГОСТ без установки ГОСТ-криптобиблиотек непосредственно на рабочую станцию. То есть пришел на любой комп и воткнул токен с ГОСТ и все крипто-апи запросы, например при TLS, пробрасываются непосредственно к аппаратной части?
Вы же догадываетесь, что там чип, мягко говоря, не быстрый?
Из документации на токены.
На примере JaCarta — http://aladdin-rd.ru/catalog/jacarta/gost/specification. В ней исползуется чип — http://pdf1.alldatasheet.com/datasheet-pdf/view/255626/ATMEL/AT90SC25672RCT.html
На примере JaCarta — http://aladdin-rd.ru/catalog/jacarta/gost/specification. В ней исползуется чип — http://pdf1.alldatasheet.com/datasheet-pdf/view/255626/ATMEL/AT90SC25672RCT.html
Догадываюсь… но возможно есть хитрый способ использования таких токенов просто как хранилища криптобиблиотек. Ну не знаю. Как место хранения длл-ек. Очень условно если говорить.
Автор, подскажите… какой именно функционал содержит апплет в аппаратной части?
Про функционал не подскажу, этот вопрос лучше адресовать производителям токенов. Неплохая документация по токенам — http://dev.rutoken.ru/
Точнее: можно ли с помощью него реализовать шифрование ГОСТ без установки ГОСТ-криптобиблиотек непосредственно на рабочую станцию.
В общем случае так сделать нельзя. Прикладное ПО (например, MS outlook) обращается к крипторафическим библиотека по какому либо стандартному интерфейсу, например MS CryptoAPI. Для того чтобы этот интерфейс был доступен и нужны криптопровайдеры. НО. Можно пойти по пути как сделал КриптоАРМ. Они умеют самостоятельно общаться с токеном, фактически реализуя встроенную криптобиблиотеку.
Если посчитать описание по ссылке https://habrahabr.ru/post/306034/#comment_9714356 проблема в чипах… (АУууу импортозамещение… )на уровне железа чип поддерживает только RSA, DES, 3DES, SHA-1 (так же как и etoken)… Для госта нужен апплет, для апплета нужно ПО, т.к. контроллер 8 битный — все работает жутко медленно… (Для RSA есть специальные 32 битные функция, и если я правильно понял операции происходят за 1 такт)
Выпускаем чип, поддерживающий гост «из коробки» — никакое ПО (кроме дров) не нужно. Но это удар по таким гигантам как Крипто-про и Инфотекс т.к. все будет работать, имхо, через openssl+токен напрямую (сейчас есть существенные заморочки)
Выпускаем чип, поддерживающий гост «из коробки» — никакое ПО (кроме дров) не нужно. Но это удар по таким гигантам как Крипто-про и Инфотекс т.к. все будет работать, имхо, через openssl+токен напрямую (сейчас есть существенные заморочки)
… все будет работать, имхо, через openssl+токен напрямую
А в чем координальное отличие? Вместо CSP будет требоваться OpenSSL, один cliet-side софт меняется на другой.
Утверждать что OpenSSL более безопасный чем тот же КриптоПРО CSP считаю не корректным. Надо сравнивать по моделям угроз и ТЗ систем для которых применяется СКЗИ.
В тоже время если вопрос в деньгах, то можно использовать бесплатный криптопровайдер VIPNET CSP или бесплатную версию КриптоПРО CSP (она становится таковой, когда заканчивается триал) правда у нее нет возможности формировать ЭП, можно только проверять.
Кардинальных отличий, пожалуй нет, но:
1) На текущий момент Криптопровайдер Vipnet CSP не может работать с подписью КриптоПРО CSP и наоборот — разный контейнеры закрытого ключа
2) реализовать через них TLS можно, но в достаточной степени геморройно, хотя не так давно (пару недель) крипто ПРО выпустили движок для openssl и прикрутить приптопрошную подпись к сайту стало на порядок легче (сам еще не пробовал)
3) про безопасность я тут умолчу, т.к. полностью с вами согласен что сравнивать как минимум сложно
4) тот же серверный крипто-про стоит 60к руб… Для пользователей, согласен, есть некоторые варианты обойтись бесплатными версиями…
1) На текущий момент Криптопровайдер Vipnet CSP не может работать с подписью КриптоПРО CSP и наоборот — разный контейнеры закрытого ключа
2) реализовать через них TLS можно, но в достаточной степени геморройно, хотя не так давно (пару недель) крипто ПРО выпустили движок для openssl и прикрутить приптопрошную подпись к сайту стало на порядок легче (сам еще не пробовал)
3) про безопасность я тут умолчу, т.к. полностью с вами согласен что сравнивать как минимум сложно
4) тот же серверный крипто-про стоит 60к руб… Для пользователей, согласен, есть некоторые варианты обойтись бесплатными версиями…
1) На текущий момент Криптопровайдер Vipnet CSP не может работать с подписью КриптоПРО CSP и наоборот — разный контейнеры закрытого ключа
Уточним. VIPNET CSP не может работать с ключевыми контейнерами сформированными КриптоПРО CSP, Но вы без проблем можете подписать запрос на сертификат сгенерированный из VIPNET CSP с помощью УЦ работающего на КриптоПРО CSP.
Поэтому тут вопрос скорее к Росстандарту и ФСБ России о том, что необходимо стандартизировать формат ключвых контейнеров.
2) реализовать через них TLS можно, но в достаточной степени геморройно,
Я бы сказал тут дело привычки. Поднять TLS на IIS+КриптоПРО CSP (серверный вариант) у меня занимало порядка 2-3 минут. Под *nix было сложнее.
В остальном согласен, за исключением цены — «Лицензия на право использования СКЗИ „КриптоПро CSP“ версии 3.9 на сервере 30 000,00р.», но тоже дороговато.
Проблема наших СКЗИ в том, что их преимущества для пользователей не очевидны.
По криптографии (взлом криптоалгоритма, баги криптосхем и т.д.) информационные системы ломают крайне редко, поэтому для обычного пользователя что отечественная библиотека СКЗИ, что импортная обеспечивают сравнимый уровень защиты, но в тоже время отечественные системы стоят денег, и порой довольно больших.
Более того, сама система использования отечественных СКЗИ — сертификация, реализация требований документации, и нормативки, например ФАПСИ 152 превращает все это просто в кошмар.
Спасибо за уточнение, мне следует более ясно выражать свои мысли :)
— Да, опять же вы правы, запрос можно генерировать на vipnet и удовлетворить на УЦ криптопро и обратно — генерировать, например КриптоАРМ, и удовлетворять запрос на УЦ Vipnet.
-по поводу TLS так уж сложилось, что мы в организации сталкиваемся в основном со связкой «сервер приложений на линукс + сервер Бд на нем же», поэтому танцы с бубном актуальны, но по ощущениям с крипто-про проблем меньше (то ли просто делают качественнее, то ли дело в том, что продукт платный, то ли разработчики чаще с крипто-про дело имеют — не берусь судить).
-Уф, не пугайте меня так с ценой, я аж поперхнулся, месяц как смету верстали… :):):) говорил про «Лицензия на право использования СКЗИ „КриптоПро JCP“ на одном сервере с двумя ядрами (или с 4 ядрами с отключенным Hyper Threading», но, в общем-то, несущественное уточнение… надо яснее выражать свои мысли :(((
— А по поводу стандартизации и документов, и документов ФСБ в частности — вообще больная тема. они 795 приказ никак под актуальную редакцию 63 фз дописать не могут, не говоря про остальное:((((
152 и прочее — растет из гостайны, и гостайну и конфиденциалку (ЭП в частности) они разделять на уровне СКЗИ упорно не хотят. видимо, есть причины…
— Да, опять же вы правы, запрос можно генерировать на vipnet и удовлетворить на УЦ криптопро и обратно — генерировать, например КриптоАРМ, и удовлетворять запрос на УЦ Vipnet.
-по поводу TLS так уж сложилось, что мы в организации сталкиваемся в основном со связкой «сервер приложений на линукс + сервер Бд на нем же», поэтому танцы с бубном актуальны, но по ощущениям с крипто-про проблем меньше (то ли просто делают качественнее, то ли дело в том, что продукт платный, то ли разработчики чаще с крипто-про дело имеют — не берусь судить).
-Уф, не пугайте меня так с ценой, я аж поперхнулся, месяц как смету верстали… :):):) говорил про «Лицензия на право использования СКЗИ „КриптоПро JCP“ на одном сервере с двумя ядрами (или с 4 ядрами с отключенным Hyper Threading», но, в общем-то, несущественное уточнение… надо яснее выражать свои мысли :(((
— А по поводу стандартизации и документов, и документов ФСБ в частности — вообще больная тема. они 795 приказ никак под актуальную редакцию 63 фз дописать не могут, не говоря про остальное:((((
152 и прочее — растет из гостайны, и гостайну и конфиденциалку (ЭП в частности) они разделять на уровне СКЗИ упорно не хотят. видимо, есть причины…
А почему бы не использовать токены PKCS11, разработанные в соответствии с рекомендациями ТК26 ( https://www.tc26.ru/methods/project/PKCS11_v18.pdf ), и NSS?
Не в галке дело. По простому говоря если ключ генерировали внутри токена(выбирая провайдер правильный криптопровайдер.) то извлечь «стандартным» способом не выйдет.
Носители с извлекаемыми ключами дороже. Поэтому наверное самые распространенные это обычные токены.
Автор говорит что даже токены с не извлекаемыми ключами надо правильно готовить ))
Носители с извлекаемыми ключами дороже. Поэтому наверное самые распространенные это обычные токены.
Автор говорит что даже токены с не извлекаемыми ключами надо правильно готовить ))
Я не Админ ИБ. Но статья понравилась.Четко, по делу. Можно в «Настольная Библия АИБа» вносить.
Спасибо!
\\Картинка огненная и в тему. Точно не помню из книги или диафильма.
Спасибо!
\\Картинка огненная и в тему. Точно не помню из книги или диафильма.
Это что получается, злоумышленнику достаточно купить КриптоПРО CSP без поддержки ФКН и все, можно извлекать ключи с любых токенов?
Во-первых, в используемых для аутентификации токенах не должно быть никакой возможности экспорта ключа. Во-вторых, должны использоваться открытые алгоритмы и технологии, а не кривое только-под-винду-Xp проприетарное ПО.
И на токене должна быть железная кнопка для ответа на запрос хоста — чтобы трояны не могли подбирать потихоньку пароль.
Ну и нужны дополнения в HTTP протокол, чтобы веб-сервисы поддерживали Challenge-Response. Тогда можно было бы отказаться от логинов/регистраций: такие данные, как email и имя хранились бы в токене, вход на сайт и регистрация происходили бы автоматически при вставленном токене.
Потерялся бы смысл в фишинге, троянах для воровства паролей. Не надо было бы запоминать или записывать сложные пароли. Имея несколько токенов, можно легко перелогиниваться. Пользвоателям было бы проще и безопаснее жить.
И на токене должна быть железная кнопка для ответа на запрос хоста — чтобы трояны не могли подбирать потихоньку пароль.
Ну и нужны дополнения в HTTP протокол, чтобы веб-сервисы поддерживали Challenge-Response. Тогда можно было бы отказаться от логинов/регистраций: такие данные, как email и имя хранились бы в токене, вход на сайт и регистрация происходили бы автоматически при вставленном токене.
Потерялся бы смысл в фишинге, троянах для воровства паролей. Не надо было бы запоминать или записывать сложные пароли. Имея несколько токенов, можно легко перелогиниваться. Пользвоателям было бы проще и безопаснее жить.
Ну и нужны дополнения в HTTP протокол, чтобы веб-сервисы поддерживали Challenge-Response. Тогда можно было бы отказаться от логинов/регистраций: такие данные, как email и имя хранились бы в токене, вход на сайт и регистрация происходили бы автоматически при вставленном токене.
Надо, чтобы браузер при работе с HTTPS умел использовать токены, а не только брать сертификаты из своего хранилища. Всё. С точки зрения сервера это простейшая аутентификация по ключу клиента, например мы такую уже сто лет в обед используем; в дикой природе можете посмотреть, как это работает, на сайте StartSSL. Соответственно на сервере указывается ЦС, которым выдан клиентский сертификат (ключ от которого в данном случае на токене), и для аутентификации можно использовать серийник, CN и т. д., любые поля сертификата клиента.
Никаких дополнений в протокол не нужно — вcё необходимое уже давно имеется.
Надо отметить, что формулировка о функционале ФКН без модулей КриптоПро не вполне верна: технология ФКН предполагает все же более безопасное использование токена, защищающее канал работы с ним (что может быть критичным, например, при удаленной работе). Подробнее об этом написано по указанной Вами ссылке, а также в статье О выработке неперебираемых ключей на основе перебираемых паролей
Во-вторых, должны использоваться открытые алгоритмы и технологии, а не кривое только-под-винду-Xp проприетарное ПО.
Ну мы же в России живем. Это же крипто про, какие открытые алгоритмы и технологии?
Не забудьте, что номер каждого токена должен быть вписан в пасспорт чтобы все знали кто есть кто
Уважаемый коллега, из КРИПТО-ПРО, согласен что аббревиатура ФКН это «ваше изобретение» (в хорошем смысле)
Когда писал статью, долго думал как назвать «токены с не извлекаемым ключом» по науке. Вы в своих статьях упоминаете термины «активный вычислитель» и др., на мой взгляд предлагаемые термины немного сложны для понимания не криптографам.
С другой стороны Функциональный ключевой носитель (ФКН) — сообщает базовые характеристики устройства:
— выполнение функций,
— хранение ключа.
Другое дело в том, что ваша реализации ФКН, возможно более продвинутая по сравнению с другими (ФКН от КРИПТО-ПРО, обеспечивает защиту канала связи между токеном и ЭВМ).
Таким образом термин ФКН на мой взгляд наиболее удачен в данном случае.
Когда писал статью, долго думал как назвать «токены с не извлекаемым ключом» по науке. Вы в своих статьях упоминаете термины «активный вычислитель» и др., на мой взгляд предлагаемые термины немного сложны для понимания не криптографам.
С другой стороны Функциональный ключевой носитель (ФКН) — сообщает базовые характеристики устройства:
— выполнение функций,
— хранение ключа.
Другое дело в том, что ваша реализации ФКН, возможно более продвинутая по сравнению с другими (ФКН от КРИПТО-ПРО, обеспечивает защиту канала связи между токеном и ЭВМ).
Таким образом термин ФКН на мой взгляд наиболее удачен в данном случае.
Ошибся кнопкой, писал ответ на комментарий выше.
Добрый день.
Статья называется: «Извлечение ключа из токена с неизвлекаемым ключом».
Так вот, если вы собрались делать «неизвлекаемый ключ», то хотя бы генерируйте сертификат не извлекаемым.
В пункте 1. Создадим исходный ключевой документ. — 4-й скриншот, стоит галка, которая все портит.
Поэтому Ваша «Методика тестирования» неверна.
И на заметку, у любого нормального УЦ по регламенту запрещено делать экспортируемые ключи и не при чет тут апплеты и технология ФКН.
Статья называется: «Извлечение ключа из токена с неизвлекаемым ключом».
Так вот, если вы собрались делать «неизвлекаемый ключ», то хотя бы генерируйте сертификат не извлекаемым.
В пункте 1. Создадим исходный ключевой документ. — 4-й скриншот, стоит галка, которая все портит.
Поэтому Ваша «Методика тестирования» неверна.
И на заметку, у любого нормального УЦ по регламенту запрещено делать экспортируемые ключи и не при чет тут апплеты и технология ФКН.
Сертификат всегда извлекаем (и должен быть таковым), содержит в себе открытый ключ, а также дополнительные данные, и всё это подписано закрытым ключом УЦ (подпись естественно тоже публикуется). Часто ещё в бандл добавляется собственно сертификат УЦ, которым это всё подписано.
Неизвлекаемым должен быть и может быть именно закрытый ключ.
По поводу методики тестирования: сделать ключ и попытаться его извлечь — это нормальная методика, если стоит целью проверить, что ключ можно извлечь. Как вы себе представляете другую методику?
Неизвлекаемым должен быть и может быть именно закрытый ключ.
По поводу методики тестирования: сделать ключ и попытаться его извлечь — это нормальная методика, если стоит целью проверить, что ключ можно извлечь. Как вы себе представляете другую методику?
Как? Не ставить эту галку. Именно так делается в УЦ. Просто потом людям голову дурят, что можно из любого токена вытащить закрытый ключ.
УЦ по распределенной схеме галки не ставит вообще никакие, так ключевую пару генерирует пользователь.
А по централизованной схеме, кто во что горазд.
У меня лично был опыт, когда при генерации ключа для ДБО ИКБ меня пустили за компьютер офицера безопасности Банка, ответственного за генерацию ключей, хотя в Банке я был впервые. Поэтому утверждать, что там делает УЦ по централизованной схеме это более чем смело.
А по поводу извлечения ключей — предлагаю просто попробовать. Возьмите (если у вас есть к ним доступ) ключи в вашей организации и попробуйте их скопировать :)
Я думаю после этого вы посмотрите на проблему под другим углом.
А по централизованной схеме, кто во что горазд.
У меня лично был опыт, когда при генерации ключа для ДБО ИКБ меня пустили за компьютер офицера безопасности Банка, ответственного за генерацию ключей, хотя в Банке я был впервые. Поэтому утверждать, что там делает УЦ по централизованной схеме это более чем смело.
А по поводу извлечения ключей — предлагаю просто попробовать. Возьмите (если у вас есть к ним доступ) ключи в вашей организации и попробуйте их скопировать :)
Я думаю после этого вы посмотрите на проблему под другим углом.
Я пишу это смело, т.к. мы являемся удостоверяющим центром. И у меня другой опыт. Ключи в нашей организации не скопируются, это я вам гарантирую.
Готовы на публичный эксперимент? :)
Отмечу, что рассматривается ситуация, когда нарушителю известны пароли и другая аутентификационная информация (например, брелки iButton и др.) используемая для защиты ключей от НСД.
На текущий момент, подобную защиту вы сможете обеспечить только если применяется честная схема с ФКН и (или) применяются HSM.
В типовой конфигурации УЦ используют следующие ключи:
1. Ключ самого УЦ или как он раньше назывался ключ уполномоченного лица удостоверяющего центра.
В типовом случае хранится в реестре CA (ФСБ в тоже время требует, чтобы использовался отчуждаемый носитель), для защиты применяют АПМДЗ Соболь или Аккорд. По хорошему должен хранится в HSM. Копирование ключа (если не используется HSM) возможно следующими способами:
— при наличии аутентификационной информации (паролей, идентификаторов iButton и др.) штатными средствами СКЗИ;
— при доступе к резервных копиям УЦ.
— из оперативной памяти, при наличии возможности запуска кода с правами Local System;
— из файла подкачки.
— при совершении сервисного обслуживания техники.
Если ключ хранится на отчуждаемом носителе (не ФКН) в сервной, то копирование возможно способами как указано далее.
2. Ключи авторизации работников УЦ. Данные ключи используются для авторизации персонала при осуществлении доступа к критически важным функциям таким как выпуск сертификата, заведение нового пользователя, отзыв сертификата, выпуск CRL и т.д. Как правильно данные ключи хранятся на «обычных» токенах, защищенных паролем + используется СКЗИ, от производителя УЦ.
Скопировать возможно следующими способами:
1. Штатными средствами СКЗИ (при наличии паролей от токенов)
2. Путем предвартиельного получения пароля от токена: соц. инжинирия, трояны.
3. Путем перехвата ключа в канале связи между компом и токеном: usbCAP, трояны
3. Инфраструктуре ключи, например ключи для организации TLS до Web-интефрейса УЦ. Обычно хранятся в реестре или в файлах. Способы копирования перечислены выше.
4. Ключи пользователей УЦ. Здесь я надеюсь, что у вас хранятся только открытые ключи. Хранение закрытых ключей на стороне УЦ дискредитирует всю схему PKI.
Ну и наконец универсальный способ (без принятия мер защиты) копирования любых ключей — side channel атаки, включая применение СТС (специальных технических средств негласного съема информации) и всеми горячо нелюбимый ПЭМИН.
Поэтому утверждение что в вашем УЦ нельзя скопировать ключи — довольно смелое :), корректней было бы сказать, что злоумышленник обладающий суммой X-рублей не сможет скопировать у вас ключи.
P.S. Кроме это по мимо ключей УЦ вы наверняка еще пользутесь услугами дистанционного банковского обслуживания Интернет Клиент-Банк, а это отдельная песня.
Отмечу, что рассматривается ситуация, когда нарушителю известны пароли и другая аутентификационная информация (например, брелки iButton и др.) используемая для защиты ключей от НСД.
На текущий момент, подобную защиту вы сможете обеспечить только если применяется честная схема с ФКН и (или) применяются HSM.
В типовой конфигурации УЦ используют следующие ключи:
1. Ключ самого УЦ или как он раньше назывался ключ уполномоченного лица удостоверяющего центра.
В типовом случае хранится в реестре CA (ФСБ в тоже время требует, чтобы использовался отчуждаемый носитель), для защиты применяют АПМДЗ Соболь или Аккорд. По хорошему должен хранится в HSM. Копирование ключа (если не используется HSM) возможно следующими способами:
— при наличии аутентификационной информации (паролей, идентификаторов iButton и др.) штатными средствами СКЗИ;
— при доступе к резервных копиям УЦ.
— из оперативной памяти, при наличии возможности запуска кода с правами Local System;
— из файла подкачки.
— при совершении сервисного обслуживания техники.
Если ключ хранится на отчуждаемом носителе (не ФКН) в сервной, то копирование возможно способами как указано далее.
2. Ключи авторизации работников УЦ. Данные ключи используются для авторизации персонала при осуществлении доступа к критически важным функциям таким как выпуск сертификата, заведение нового пользователя, отзыв сертификата, выпуск CRL и т.д. Как правильно данные ключи хранятся на «обычных» токенах, защищенных паролем + используется СКЗИ, от производителя УЦ.
Скопировать возможно следующими способами:
1. Штатными средствами СКЗИ (при наличии паролей от токенов)
2. Путем предвартиельного получения пароля от токена: соц. инжинирия, трояны.
3. Путем перехвата ключа в канале связи между компом и токеном: usbCAP, трояны
3. Инфраструктуре ключи, например ключи для организации TLS до Web-интефрейса УЦ. Обычно хранятся в реестре или в файлах. Способы копирования перечислены выше.
4. Ключи пользователей УЦ. Здесь я надеюсь, что у вас хранятся только открытые ключи. Хранение закрытых ключей на стороне УЦ дискредитирует всю схему PKI.
Ну и наконец универсальный способ (без принятия мер защиты) копирования любых ключей — side channel атаки, включая применение СТС (специальных технических средств негласного съема информации) и всеми горячо нелюбимый ПЭМИН.
Поэтому утверждение что в вашем УЦ нельзя скопировать ключи — довольно смелое :), корректней было бы сказать, что злоумышленник обладающий суммой X-рублей не сможет скопировать у вас ключи.
P.S. Кроме это по мимо ключей УЦ вы наверняка еще пользутесь услугами дистанционного банковского обслуживания Интернет Клиент-Банк, а это отдельная песня.
для защиты применяют АПМДЗ Соболь или Аккорд
Я так понимаю, что часть защитных мер осталась родом из мира DOS.
В точку, но это прописано, в документации по СКЗИ, сертифицированной по КС2.
Из полезных свойств аппаратного модуля довереной загрузки (АМДЗ) в данном случае является только генератор случайных чисел, все остальное очень натянуто и не выдерживает критики.
Из полезных свойств аппаратного модуля довереной загрузки (АМДЗ) в данном случае является только генератор случайных чисел, все остальное очень натянуто и не выдерживает критики.
Сертификация по уровню КС2 — это для защиты от уборщиц)))))) Поясню: класс защищенности КС2 (в самой понятной для обывателя формулировке) подразумевает защищенность изделия от нарушителей Н2 (нарушитель, имеющий доступ в помещение с защищаемыми техническими средствами, но не являющийся пользователем оных средств) и Н1 (нарушитель, не имеющий доступ в контролируемую зону; для осуществления атак может применять только технические средства, полученные из открытых источников)… Так что, чтобы оспорить качество сертифицированных продуктов, необходимо еще соответствующие условия создать.
Так что, чтобы оспорить качество сертифицированных продуктов, необходимо еще соответствующие условия создать.
Одним из требований к средствам УЦ для класса КС2 является контроль целостности программных средств. Собственно, аппаратные модули доверенной загрузки могут контролировать целостность данных только в операционных системах не сложнее DOS.
аппаратные модули доверенной загрузки могут контролировать целостность данных только в операционных системах не сложнее DOS
С чего Вы это взяли? АПМДЗ могут контролировать целостность данных независимо от типа ОС. АПМДЗ зачастую и не знают о типе ОС на хосте. Перед загрузкой ОС АПМДЗ могут проверять и файлы в поддерживаемых ФС и отдельные сектора дисков. Так что, какие данные пользователь прикажет проверять, такие АПМДЗ и проверит. А уж с приходом UEFI возможности по контролю расширились)
С чего Вы это взяли?
В современных операционных системах данные могут быть в довольно сложной форме представления, нет никакой гарантии, что предзагрузочный контроль целостности АМДЗ «увидит» то же самое, что «увидит» и сама операционная система после передачи ей управления. Где гарантии, что в АМДЗ такой же, с позиции алгоритмов обработки данных, драйвер файловой системы, что и в Windows? Я занимался обратной разработкой ПО для контроля целостности в Аккорд-АМДЗ (на базе ACDOS и на базе Linux: AMDZ-NG) и могу смело сказать: можно изменить данные так, что контроль их целостности пройдет, но для операционной системы это будут другие данные, потому что «кривой парсер» закрытого формата в АМДЗ не учитывает некоторые состояния данных, которые учитывает операционная система.
А уж с приходом UEFI возможности по контролю расширились)
Наоборот. Например, в некоторых реализациях UEFI возможна загрузка с USB-накопителя после того, как управление будет передано менеджеру загрузки Windows. А вот еще доклад ОКБ САПР.
До недавнего времени и я занимался разработкой АПМДЗ (писал как раз OptionROM для UEFI)… И тоже могу с уверенностью сказать, что коллизии контроля целостности возникают из-за выбранных алгоритмов (в интернете достаточно статей про коллизии CRC16/32).
По второй части Вашего комментария могу так же ответить — все зависит от «конкретной реализации UEFI». Во время отладки я мог вообще что угодно делать с UEFI — чаще получалось ее просто «вешать»))) (это была шутка)
И мне хочется сделать промежуточный итог нашего обсуждения… Вернее, не итог, а просто напомнить, что ветка обсуждения началась с «класса защищенности КС2» и соответствующего этому классу «нарушителя Н2». Поэтому не стоит нас с вами (видимо обладающих специальными знаниями и опыт в соответствующей области) и описанные Вами способы компрометации АПМДЗ приравнивать к знаниям и возможностям «нарушителя Н2».
По второй части Вашего комментария могу так же ответить — все зависит от «конкретной реализации UEFI». Во время отладки я мог вообще что угодно делать с UEFI — чаще получалось ее просто «вешать»))) (это была шутка)
И мне хочется сделать промежуточный итог нашего обсуждения… Вернее, не итог, а просто напомнить, что ветка обсуждения началась с «класса защищенности КС2» и соответствующего этому классу «нарушителя Н2». Поэтому не стоит нас с вами (видимо обладающих специальными знаниями и опыт в соответствующей области) и описанные Вами способы компрометации АПМДЗ приравнивать к знаниям и возможностям «нарушителя Н2».
До недавнего времени и я занимался разработкой АПМДЗ (писал как раз OptionROM для UEFI)… И тоже могу с уверенностью сказать, что коллизии контроля целостности возникают из-за выбранных алгоритмов (в интернете достаточно статей про коллизии CRC16/32).
Речь не об ошибках в алгоритмах расчета контрольных сумм в частности и не о стойкости хеш-функций вообще. АМДЗ, в случае с Windows, должен поддерживать NTFS и реестр (это самый минимум). Вот только никто досконально изучать драйвер NTFS и ядро Windows для реализации такой поддержки не будет, а значит могут существовать (и существуют) случаи, когда собственная реализация NTFS и реестра «видит» одни данные, а Windows – другие. Потому что формат данных закрыт и представление о нем было неполным или ошибочным.
Поэтому не стоит нас с вами (видимо обладающих специальными знаниями и опыт в соответствующей области) и описанные Вами способы компрометации АПМДЗ приравнивать к знаниям и возможностям «нарушителя Н2».
Не буду спорить :-) Но тогда встает вопрос об адекватности выбора модели нарушителя.
Тот АПМДЗ, в разработке которого я принимал участие, поддерживает NTFS (я сам туда вкрячивал NTFS-драйвер), ветки реестра тоже проверяет (это тоже файлы) и даже контролирует журнал транзакций NTFS (это тоже файл). Кстати, эти требования нам выкатило именно ФСБ при согласовании ТЗ. Жаль (или к счастью), но этот АПМДЗ «гражданский сектор» не увидит…
По поводу адекватности выбора модели нарушителя я с Вами полностью согласен. Иногда заказчики умышленно «понижали» степень конфиденциальности информации, лишь бы не платить лишние деньги на СЗИ…
По поводу адекватности выбора модели нарушителя я с Вами полностью согласен. Иногда заказчики умышленно «понижали» степень конфиденциальности информации, лишь бы не платить лишние деньги на СЗИ…
ветки реестра тоже проверяет
У кого-то не проверяется правильность сортировки ключей реестра в записях li/lf/lh/ri. Это значит, что список ключей, «видимый» АМДЗ, может отличаться от списка ключей после монтирования куста в Windows (Windows удалит все ключи, нарушающие порядок сортировки). Еще могут не проверяться ссылки на родительские ключи, что может привести к тому, что Windows удалит деревья ключей с неправильными ссылками при подключении куста (а в АМДЗ такие деревья будут считаться корректными). И так далее, список большой.
и даже контролирует журнал транзакций NTFS (это тоже файл)
$LogFile или TxF? Если что-то одно, то не годится :-)
Насчет анализа содержимого веток реестра я не заморачивался, считая, что если между двумя проверками бинарное содержимое файла не изменилось, то и ОС увидит в них то же самое, что и после предыдущей проверки. Возможно я не прав, не спорю.
Проверял $LogFile, потому как TxF — это технология поддержки транзакционности в NTFS (публичное API, насколько я смог на тот момент разобраться)… И меня отпугнул тот факт, что MicroSoft не рекомендовала ей пользоваться.
Проверял $LogFile, потому как TxF — это технология поддержки транзакционности в NTFS (публичное API, насколько я смог на тот момент разобраться)… И меня отпугнул тот факт, что MicroSoft не рекомендовала ей пользоваться.
что если между двумя проверками бинарное содержимое файла не изменилось
Оно должно изменяться всегда. В кусте SYSTEM, например, при каждой загрузке создается ссылка на выбранную конфигурацию в виде непостоянного ключа, информация о котором записывается в постоянный ключ и обновляется на диске. И так происходит со времен Windows NT 3.1.
ставлю свои 5 копеек, все мое имхо:
— АМДЗ применительно к СКЗИ это, конечно, бред. но в связке с СЗИ от НСД тот же SecretNet (да, да в котором дыру нашли, и за обновление формуляров которого на патченую версию, разрабы попросили 25% от стоимости) вроде как работает неплохо. т.к. работает драйвер на уровне системы уже и все нюансы ФС должен нормально учитывать…
— по поводу UEFI мне тоже кажется что с его(?) приходом все эти АМДЗ стали очень сильно неактуальны, при этом в банке угроз ФСТЭК угроз с изменение кода BIOS достаточно много и как от этого защищаться (на бумаге есс-но) кроме как установкой АМДЗ не очень ясно.
— у нас класс СКЗИ определен как КС3, поэтому, формально, у всех должен быть АМДЗ, но проконтролировать нереально…
— АМДЗ применительно к СКЗИ это, конечно, бред. но в связке с СЗИ от НСД тот же SecretNet (да, да в котором дыру нашли, и за обновление формуляров которого на патченую версию, разрабы попросили 25% от стоимости) вроде как работает неплохо. т.к. работает драйвер на уровне системы уже и все нюансы ФС должен нормально учитывать…
— по поводу UEFI мне тоже кажется что с его(?) приходом все эти АМДЗ стали очень сильно неактуальны, при этом в банке угроз ФСТЭК угроз с изменение кода BIOS достаточно много и как от этого защищаться (на бумаге есс-но) кроме как установкой АМДЗ не очень ясно.
— у нас класс СКЗИ определен как КС3, поэтому, формально, у всех должен быть АМДЗ, но проконтролировать нереально…
— АМДЗ применительно к СКЗИ это, конечно, бред. но в связке с СЗИ от НСД тот же SecretNet (да, да в котором дыру нашли, и за обновление формуляров которого на патченую версию, разрабы попросили 25% от стоимости) вроде как работает неплохо. т.к. работает драйвер на уровне системы уже и все нюансы ФС должен нормально учитывать…
Перед передачей управления программному СЗИ надо бы проверить целостность этого СЗИ и целостность его конфигурации, что уже создает проблемы.
— по поводу UEFI мне тоже кажется что с его(?) приходом все эти АМДЗ стали очень сильно неактуальны, при этом в банке угроз ФСТЭК угроз с изменение кода BIOS достаточно много и как от этого защищаться (на бумаге есс-но) кроме как установкой АМДЗ не очень ясно.
Тут можно многое написать, но это уже не совсем по теме обсуждения будет :-)
Использование АПМДЗ для СКЗИ — пережиток прошлого. В настоящее время эти устройства создают больше проблем, чем обеспечивают безопасность.
Рассмотрим типовой функционал АПМДЗ
1. Про функционал генератора случайных чисел писал — это ок.
2. Контроль целостности. Да АПМДЗ контролирует целостность файлов, хорошо ли плохо вопрос немного другой, но контролирует он ее только в момент перезагрузки системы. А как часто у вас перезагружаются prod. сервера?
То есть пратическая ценность этого функционала близка к 0.
3. Позволяют блокировать загрузку со съемных носителей (CD, floppy,...). Опять таки, как часто перезагружается сервер?
4. Позволяют осуществлять аутентификацию пользователей в момент загрузки по идентификаторам. Опять момент загрузки.
5. АПДМЗ по документации должны подключаться в разъем Reset на мат. плате компа. Много у серверов разъемов Reset?
6. АПМДЗ могут хранить ключи шифрования. Возможно это и будет удобно, но есть другие хранилища — токены, которые не хуже.
Недостатки:
1. Применение BMC, таких как ILO, IPMI с АПМДЗ неоднозначно.
2. Чистый АПМДЗ легко обойти, достаточно вынуть девайс из компа. Исключение составляют замки с шифраторами от АНКАД, но они настояльно дорогие, что мне ни разу не удалось убедить из купить.
Резюме. АПМДЗ создавались во времена DOS. Тогда их функционал нес практическую ценность. Сейчас нужны другие системы.
Рассмотрим типовой функционал АПМДЗ
1. Про функционал генератора случайных чисел писал — это ок.
2. Контроль целостности. Да АПМДЗ контролирует целостность файлов, хорошо ли плохо вопрос немного другой, но контролирует он ее только в момент перезагрузки системы. А как часто у вас перезагружаются prod. сервера?
То есть пратическая ценность этого функционала близка к 0.
3. Позволяют блокировать загрузку со съемных носителей (CD, floppy,...). Опять таки, как часто перезагружается сервер?
4. Позволяют осуществлять аутентификацию пользователей в момент загрузки по идентификаторам. Опять момент загрузки.
5. АПДМЗ по документации должны подключаться в разъем Reset на мат. плате компа. Много у серверов разъемов Reset?
6. АПМДЗ могут хранить ключи шифрования. Возможно это и будет удобно, но есть другие хранилища — токены, которые не хуже.
Недостатки:
1. Применение BMC, таких как ILO, IPMI с АПМДЗ неоднозначно.
2. Чистый АПМДЗ легко обойти, достаточно вынуть девайс из компа. Исключение составляют замки с шифраторами от АНКАД, но они настояльно дорогие, что мне ни разу не удалось убедить из купить.
Резюме. АПМДЗ создавались во времена DOS. Тогда их функционал нес практическую ценность. Сейчас нужны другие системы.
Мне кажется надо просто отделить мух от котлет. АМДЗ для СКЗИ для гостайны — пусть все остается как есть (плохо это или хорошо, это отдельный вопрос и разговор). СКЗИ для конфиденциалки — оставить только программные реализации (по желанию оператор сам может наставить ПАКов каких и куда хочет, но не делать обязаловку из этого) и требования писать исходя из этого, Т.к.:
1. Методики оценки ущерба от разглашения КИ нет
2. моралка по суду максимум 5 тыс руб, т.к. очень сложно доказать иное…
3. штрафы откровенно смешные, и то если безопасник совсем безголовый. Если хоть что-то булькает, то все бумаги будут в порядке. На сколько они соответствуют жизни… Ну так я оператор, я так решил и модель угроз/нарушителя сам писал. вот сели мы вдвоем со сторожем и написали — он у нас эксперт ;))
4. Нет денег… одно рабочее место в органе власти со всей этой хренью обходится в ~ 60тыс рублей — Это пипец!!! Даллас лок+vipNet+соболь+Антивирь+ХанниПот +аттестация и это без железа!- это госы. На соболе можно сэкономить на текущий момент около 11 тыс — хоть что-то…
Ну и в качестве PS:
Токен это ПАК или нет? Ось есть, железо есть- вроде как ПАК :)))
1. Методики оценки ущерба от разглашения КИ нет
2. моралка по суду максимум 5 тыс руб, т.к. очень сложно доказать иное…
3. штрафы откровенно смешные, и то если безопасник совсем безголовый. Если хоть что-то булькает, то все бумаги будут в порядке. На сколько они соответствуют жизни… Ну так я оператор, я так решил и модель угроз/нарушителя сам писал. вот сели мы вдвоем со сторожем и написали — он у нас эксперт ;))
4. Нет денег… одно рабочее место в органе власти со всей этой хренью обходится в ~ 60тыс рублей — Это пипец!!! Даллас лок+vipNet+соболь+Антивирь+ХанниПот +аттестация и это без железа!- это госы. На соболе можно сэкономить на текущий момент около 11 тыс — хоть что-то…
Ну и в качестве PS:
Токен это ПАК или нет? Ось есть, железо есть- вроде как ПАК :)))
Токен в особенности с неизвлекаемым ключом — это ПАК. В Сертификате на JaCarta ГОСТ есть фараза:
"… Действие сертификата соответствия ФСБ России № СФ/111-2750 распространяется на совместное использование СКЗИ «Криптотокен» в составе электронных ключей JaCarta ГОСТ (eToken ГОСТ) и программных библиотек «Криптотокен ЭП», поставляемых в электронной форме… "
"… Действие сертификата соответствия ФСБ России № СФ/111-2750 распространяется на совместное использование СКЗИ «Криптотокен» в составе электронных ключей JaCarta ГОСТ (eToken ГОСТ) и программных библиотек «Криптотокен ЭП», поставляемых в электронной форме… "
Вот здесь галку уберите — http://ge.tt/6gtG6mc2
Статья называется «Извлечение ключа из токена с неизвлекаемым ключом», так вот делайте ключ неизвлекаемый, а потом тестируйте.
Статья называется «Извлечение ключа из токена с неизвлекаемым ключом», так вот делайте ключ неизвлекаемый, а потом тестируйте.
Ждал этого комента :)
Давайте еще раз разберемся в чем разница между «не экспортируемым» ключом и «неизвлекаемым».
Например вы сгененрировали ключ и поставили галку что ключ неэкспортируемый. Что это значит? А значит это, то что средствами СКЗИ его скопировать не получиться. Но когда выполняется подпись документа, ключ с токена копируется в память ЭВМ, где обрабатывается криптопровайдером, Основной баг этой схемы в том, что ключ может быть похищен из ОЗУ.
Галочку что ключ «не экспортирумый» можно поставить и при генерации ключа на обычном токене, для этого необязательно покупть более дорогой токен с «неивзлекамым ключом».
Теперь рассмотрим неизвлекаемые ключи. В этой схеме ключи, хранящиеся на токенах никогда не подают в память ЭВМ все криптографические операции связанные с использованием ключа выполняются сугубо на токене. Таким образом ключ скоприровать невозможно.
В этом принципиальное отличие.
Суть статьи в том, что вы берете устройство — токен, заходите на сайт производителя, там везде токен с неизвлекаемым ключом это очень круто, безопасно и т.д. (с чем я согласен :)
Берете свое СКЗИ используете этот токен — СКЗИ работает, файлы подписываются, и у вас может сложится ложное мнение о том, что ваша схема — это схема с ФКН, но на самом деле нет.
Давайте еще раз разберемся в чем разница между «не экспортируемым» ключом и «неизвлекаемым».
Например вы сгененрировали ключ и поставили галку что ключ неэкспортируемый. Что это значит? А значит это, то что средствами СКЗИ его скопировать не получиться. Но когда выполняется подпись документа, ключ с токена копируется в память ЭВМ, где обрабатывается криптопровайдером, Основной баг этой схемы в том, что ключ может быть похищен из ОЗУ.
Галочку что ключ «не экспортирумый» можно поставить и при генерации ключа на обычном токене, для этого необязательно покупть более дорогой токен с «неивзлекамым ключом».
Теперь рассмотрим неизвлекаемые ключи. В этой схеме ключи, хранящиеся на токенах никогда не подают в память ЭВМ все криптографические операции связанные с использованием ключа выполняются сугубо на токене. Таким образом ключ скоприровать невозможно.
В этом принципиальное отличие.
Суть статьи в том, что вы берете устройство — токен, заходите на сайт производителя, там везде токен с неизвлекаемым ключом это очень круто, безопасно и т.д. (с чем я согласен :)
Берете свое СКЗИ используете этот токен — СКЗИ работает, файлы подписываются, и у вас может сложится ложное мнение о том, что ваша схема — это схема с ФКН, но на самом деле нет.
UFO just landed and posted this here
Я чего-то может не понимаю, но вы создаете ключи с отметкой «Пометить ключи как экспортируемые» (о чем свидетельствует установленная галка), потом копируете эти экспортируемые ключ в аппаратный токен. Далее производите удаление экспортируемых ключей из СКЗИ и обратно копируете экспортируемые ключи из аппаратного токена в реестр СКЗИ.
А возможно тоже самое проделать с ключом изначально созданным как «не экспортируемый», причем процесс извлечения ключей из аппартного токена произвести уже на другой тестовой машине?
А возможно тоже самое проделать с ключом изначально созданным как «не экспортируемый», причем процесс извлечения ключей из аппартного токена произвести уже на другой тестовой машине?
Ключ изначально созданный как «не экспортируемый» штатными средствами СКЗИ скопировать не получится. Но это не отменяет возможность применения других методов (см. комменты выше).
Только вот покупать токен, который позиционируется как токен с не извлекаемым ключом для этих целей (простановки галки «не экспортируемый» не нужно. Ровно тот же функционал вы получите не обычных токенах, которые стоят уверено дешевле.
Поясню. Вы взяли обычную флешку за 300 рублей, начали сгенерировали на ней ключ, поставили галку «не экспортируемый». Все, штатными средствами скопировать нельзя. Но не кто не отменял «Проводник Windows».
В случае токенов ситуация точно такая же.
Но если хочется чтоб ключ действительно нельзя было скопировать, то нужно использовать тот софт и те токены, что описаны в конце статьи, а не тот, что обычно втюхивают продавцы.
Только вот покупать токен, который позиционируется как токен с не извлекаемым ключом для этих целей (простановки галки «не экспортируемый» не нужно. Ровно тот же функционал вы получите не обычных токенах, которые стоят уверено дешевле.
Поясню. Вы взяли обычную флешку за 300 рублей, начали сгенерировали на ней ключ, поставили галку «не экспортируемый». Все, штатными средствами скопировать нельзя. Но не кто не отменял «Проводник Windows».
В случае токенов ситуация точно такая же.
Но если хочется чтоб ключ действительно нельзя было скопировать, то нужно использовать тот софт и те токены, что описаны в конце статьи, а не тот, что обычно втюхивают продавцы.
С USB-flash накопители все понятно, это вообще то и не токены и конечен там можно и через файловый проводник все скопировать.
Тема вроде как звучит «Извлечение ключа из токена с неизвлекаемым ключом», стало быть и процесс тестирования должен начинаться с того, что ключи изначально создаются как «не экспортируемые» на токене, а не на HDD компьютера. А то, что из ОЗУ можно вытащить, так думаю от туда много чего при желании можно вытащить, только как это связано с темой поста про извлечение из токена?
В комментариях выше вы приводили различные примеры копирования в плоть до снятия ПЭМИН, но это же все отностится к перехвату данных. Хоть бы один вариант в тесте приведите, а так это голая теория! ;)
Да и не думаю, что из-за ключа стоимость от 2 до 5 тыс. руб., кто-то будет снимать электромагнитные наводки для выемки ключей из токена!!!
Тема вроде как звучит «Извлечение ключа из токена с неизвлекаемым ключом», стало быть и процесс тестирования должен начинаться с того, что ключи изначально создаются как «не экспортируемые» на токене, а не на HDD компьютера. А то, что из ОЗУ можно вытащить, так думаю от туда много чего при желании можно вытащить, только как это связано с темой поста про извлечение из токена?
В комментариях выше вы приводили различные примеры копирования в плоть до снятия ПЭМИН, но это же все отностится к перехвату данных. Хоть бы один вариант в тесте приведите, а так это голая теория! ;)
Да и не думаю, что из-за ключа стоимость от 2 до 5 тыс. руб., кто-то будет снимать электромагнитные наводки для выемки ключей из токена!!!
Токены с неизвлекаемыми ключами позиционируются именно как защищенные от извлечения ключа вредоносной программой. Атаки на аппаратную часть (например, ПЭМИН) здесь на заднем плане. Но утечки через оперативную память тут в самый раз.
Да и не думаю, что из-за ключа стоимость от 2 до 5 тыс. руб., кто-то будет снимать электромагнитные наводки для выемки ключей из токена!!!
Я бы не был столь категоричен. Все завист от стоимости данных, которые защищены ключом. Например, если ключ от корр. счета Банка, на котором лежит несколько ярдов, то стоимость перехвата в данном случает будет зависит от стоимости приемника.
Широкополосник Rohde & Schwarz, который будет уметь такое стоил порядка 0,5 млн евров. Самопал на USRP существенно дешевле.
А вы серьезно думайте, что компания с таким корр. счетом в Банке, будет сидеть в одноэтажном здании в помещении со стенами из картона и отсутствием как минимум СБ в структуре? И что злоумышленник пойдет с оборудованием подобного класса только для того, чтобы снять наводки с электронного ключа! Вы сами то в это верите?
Да и речь вообще не об этом, а о сути вашего поста «Извлечение ключа из токена с неизвлекаемым ключом». Просто содержимое не отражает сути названия темы. Лично мне как специалисту было бы намного интересно посмотреть на конкретные примеры извлечения подобных «не экспортируемых» ключей из токена, а не то, что вы описали механизм копирования в КрпитоПРО. Если для вас очевидный факт извлечение ключей из оперативки, интересно взглянуть как вы этого добьетесь и воспользуетесь извлеченными ключами на конкретных примерах. А пока по комментариям я вижу только размышления из разряда «фантазий» не относящиеся к сути вашей темы!
Да и речь вообще не об этом, а о сути вашего поста «Извлечение ключа из токена с неизвлекаемым ключом». Просто содержимое не отражает сути названия темы. Лично мне как специалисту было бы намного интересно посмотреть на конкретные примеры извлечения подобных «не экспортируемых» ключей из токена, а не то, что вы описали механизм копирования в КрпитоПРО. Если для вас очевидный факт извлечение ключей из оперативки, интересно взглянуть как вы этого добьетесь и воспользуетесь извлеченными ключами на конкретных примерах. А пока по комментариям я вижу только размышления из разряда «фантазий» не относящиеся к сути вашей темы!
А вы серьезно думайте, что компания с таким корр. счетом в Банке, будет сидеть в одноэтажном здании в помещении со стенами из картона и отсутствием как минимум СБ в структуре?
Видел такие организации :) Количество этажей роли не играет, равно как размещение СБ в здании. Поскольку знаю только одну организцию (гос. структура) в которой, в центральном офисе был развернут пост радиоконтроля.
И что злоумышленник пойдет с оборудованием подобного класса только для того, чтобы снять наводки с электронного ключа!
Злоумышлик пойдет не наводки снимать, а ключ извлекать, это немного другая постановка вопроса.
Вы сами то в это верите?
Тут сложнее.
Если мы говорим про практическую оценку актуальности угроз ПЭМИН, то я подхожу к этому со следующих позиций:
1. Извлечь ключ по ПЭМИН возможно.
— На расстоянии непосредственного контакта — условно до 10 метров (клиентская зона) устройства подобного класса будут стоит
менее 100 тыс. рублей.
— На дальних дистанциях (без зоны прямой видимости) — это прерогатива спец. служб или устойчивых преступных групп. Нужно дорогое оборудование.
2. Для реализации подобного класса угроз у злоумышлеников должна быть очень хорошая подготовка и знания.
3. Для защиты от ПЭМИН нужно реализовать целый комплекс мер, которые для обычной коммерческой организации практически не реализуемы:
— организация режима доступа в помещение.
— документирование и контроль трасс прохождения каналов связи и силовых линий и т. д.
Таким образом, ПЭМИН угроза не эфемерная
.
Спасает то, что специалистов по ней нет и стоимость взлома по ПЭМИН превышает стоимость взлома через классические каналы НСД. А факт, того что для защита от данного вида угроз необходимо реализовывать довольно дорогостоящий комплекс мер, переводит этот риск в разряд рисков с которым приходится жить.
Лично мне как специалисту было бы намного интересно посмотреть на конкретные примеры извлечения подобных «не экспортируемых» ключей из токена, а не то, что вы описали механизм копирования в КрпитоПРО
Это предмет отдельной статьи. В этой статье я хотел показать о типовом разводе, который можно проверить просто элементарными способами.
То, что разводят на покупке ключей (да еще и предлагают никому ненужную техподдержку) это понятно.
Просто тест приведен неубедительный, рассчитанный на слабо разбирающегося (можно сказать вообще не разбирающегося) пользователя.
А то, что вы говорите про злоумышленника, который пойдет в организацию ключ извлекать из токена в это слабо верится (сам по себе ключ ничего не даст злоумышленнику).
Я думаю намного проще и эффективнее осуществить атаку с последующей возможностью удаленной эксплуатации того же ПК для отправки данных в Банк и пользоваться системой на свое усмотрение.
А если и произойдет утечка, то по глупости той организации, которая не соблюдала элементарные организационные и технические меры по обеспечению защиты ключей и того ПК, с которого осуществляются отправка данных в Банк.
Теперь осталось дождаться от вас статьи про утечку данных из токенов ;)
Просто тест приведен неубедительный, рассчитанный на слабо разбирающегося (можно сказать вообще не разбирающегося) пользователя.
А то, что вы говорите про злоумышленника, который пойдет в организацию ключ извлекать из токена в это слабо верится (сам по себе ключ ничего не даст злоумышленнику).
Я думаю намного проще и эффективнее осуществить атаку с последующей возможностью удаленной эксплуатации того же ПК для отправки данных в Банк и пользоваться системой на свое усмотрение.
А если и произойдет утечка, то по глупости той организации, которая не соблюдала элементарные организационные и технические меры по обеспечению защиты ключей и того ПК, с которого осуществляются отправка данных в Банк.
Теперь осталось дождаться от вас статьи про утечку данных из токенов ;)
ну на счет глупости я бы не был так категоричен. Приходите вы на собеседование или просто к секретарю типа курьер… отвлекаете бухгалтера. вешаете ему на клаву или рядом с компом стикер (как будто он под документ какой завалился, что типа бла бла приходил для техподдержки компа (обновления 1С и пр вас не было — перезвоните на мобильник)) 2 мин на все… Вам или сообщнику звонят — вы просите удаленку или просто приходите и делаете с компам что хотите- троян и прочее, а при наличии нормального шпионского ПО с реализациями 0-day уязвимостей вы полностью завладеете компьютером бухгалтера… а дальше — дело техники…
И часто вы проходите собеседование в кабинете бухгалтера с «операторской» машиной? :) Да и секретарь ну никак не будет сидеть с главным бухгалтером!!! Максимум куда вы дойдете это будет переговорная комната или ресепшен.
И как назвать по другому действия сотрудника, который по стикеру будет звонить на неизвестный мобильный телефон, как не глупость. Есть же здравый смысл или на крайней случай внутренняя телефония с почтой!!! :)))
Допустим даже если вам перезвонили по «утке» я не уверен, что вы сможете объяснить по телефону как включить удаленный доступ допустим того же teamviewer.
А вот если есть «неконтролируемый» удаленный доступ то, что это как не глупость организации в лице того же системного администратора или специалиста по ИБ?
И что вы понимаете под нормальным шпионским ПО с реализациями 0-day уязвимостью (вы сами то в руках такое ПО держали и использовали?). То, что вы описываете для начало попробуйте хотя бы у себя в организации осуществить, пусть даже с самописным трояном. ;)
Все, что вы приводите это в той или иной степени всего лишь отражение степени зрелости (компетенции) службы информационной безопасности в организации (или на крайней случай специалиста по ИБ)!!!
И как назвать по другому действия сотрудника, который по стикеру будет звонить на неизвестный мобильный телефон, как не глупость. Есть же здравый смысл или на крайней случай внутренняя телефония с почтой!!! :)))
Допустим даже если вам перезвонили по «утке» я не уверен, что вы сможете объяснить по телефону как включить удаленный доступ допустим того же teamviewer.
А вот если есть «неконтролируемый» удаленный доступ то, что это как не глупость организации в лице того же системного администратора или специалиста по ИБ?
И что вы понимаете под нормальным шпионским ПО с реализациями 0-day уязвимостью (вы сами то в руках такое ПО держали и использовали?). То, что вы описываете для начало попробуйте хотя бы у себя в организации осуществить, пусть даже с самописным трояном. ;)
Все, что вы приводите это в той или иной степени всего лишь отражение степени зрелости (компетенции) службы информационной безопасности в организации (или на крайней случай специалиста по ИБ)!!!
— Ну по поводу бухгалтерии — это элементарно. Приходите в организацию, морда кирпичом и ломитесь в первую попавшуюся дверь (кроме приемной) тряся счетом на оплату услуг и вопросом где у вас бухгалтерия — в 90% случаев скажут. А дальше — чистая соц. инженерия, вломиться, взять бухгалтера за пуговичку, изобразить легкую стадию дибильности, отвлечь, оставить стикер… Да, есть шанс что не перезвонят, или перезвонят по внутреннему в техотдел. Но ведь могут и позвонить… Понятно, что этот сценарий больше применим к средним и мелким компаниям. Но у них вполне себе могут быть миллионные обороты…
— О, поверьте, s как доллар и тимвиевер — «как слышится так и пишется», «вбейте это в яндексе», «откройте интернет» это я ночью не проснувшись объясню самому деревянному пользователю, опыт есть, к сожалению… :)))) Лишь бы прав хватило на скачать и запустить…
— 0-day уязвимости сам лично не находил, но с троянами дело имел и писал и управление перехватывал, в академических целях еес-но, давно правда очень почти 10 лет уже…
— просто я хотел сказать, что даже при наличии крайне компетентных ИТ-спецов и безопасников, пресловутый человеческий фактор никто не отменял, но и головотяпства и откровенной лени, тоже, увы, более чем хватает…
— О, поверьте, s как доллар и тимвиевер — «как слышится так и пишется», «вбейте это в яндексе», «откройте интернет» это я ночью не проснувшись объясню самому деревянному пользователю, опыт есть, к сожалению… :)))) Лишь бы прав хватило на скачать и запустить…
— 0-day уязвимости сам лично не находил, но с троянами дело имел и писал и управление перехватывал, в академических целях еес-но, давно правда очень почти 10 лет уже…
— просто я хотел сказать, что даже при наличии крайне компетентных ИТ-спецов и безопасников, пресловутый человеческий фактор никто не отменял, но и головотяпства и откровенной лени, тоже, увы, более чем хватает…
токен был придуман с целью аппаратно ограничить подбор паролей к ключу (токену) — ограниченное количество попыток — и не решал задачи неизвлекаемости ключа. Неизвлекаемость ключа обеспечивается носителями типа ФКН и используемых как ФКН :), о чем и говорится в статье…
Хитрый план:
- Покупаем токен, несколько раз переспрашиваем продавца под диктофон, что он точно неизвлекаемый.
- Записываем ключ.
- Извлекаем.
- Подаём заявление в суд на производителя за вводящую в заблуждение рекламу и в прокуратуру на орган сертификации, подписавший сертификат, что он таки неизвлекаемый.
- Ржом.
Если сгенерировать ключи не КриптоАрм'ом, а через API разработчика, используя внутренний криптопровайдер токена, то через КриптоПро/VipNet контейнеры так просто уже не скопировать (КриптоПро их даже не увидит). Для работы с такой ЭП нужно использовать адаптированное под данный носитель ПО (например такие ЭП работает в ЕГАИС от ФСРАР после установки специального плагина для браузера). Что касается того, что УЦ не всегда используют встроенные в носитель средства, то это последствия необходимости обеспечения совместимости с теми системами в которых хочет работать пользователь.
Т.е. решить проблему дохнущих джакарт и последующей беготни за новыми ключами+сертификатами не выйдет?
Если Вы про джакарты SE, то там печаль. От разработчика было письмо, что при высоких нагрузках носитель дохнет(точнее блочится). aladdin-rd.ru/company/info_message
Ну да, я про то и говорю. И далее приходится бежать не только за новым носителем, но и платить УЦ за новые ключи и сертификат. А можно было бы сделать копию этого хозяйства — обходились бы только новым носителем, к тому же их пока по гарантии меняют
Токен то не дохнет. Он выключается. Не держите его в порту на постоянку. И трясите произоводителя софта, на котором Джакарта отстреливается.
А если учесть, что Джакарта и сертификат на нее приобретается в одном месте, то и сертификат должны выпустить по гарантии до конца срока его действия, если уж Джакарта больная попалась.
А если учесть, что Джакарта и сертификат на нее приобретается в одном месте, то и сертификат должны выпустить по гарантии до конца срока его действия, если уж Джакарта больная попалась.
Ну они рекомендуют другую криптобиблиотеку использовать, юзеры вроде пишут, с ней постабильней работает. Но и много ключей нерабочих — некоторые пишут о накоплении уже по десятку ключей на замену. А вот о бесплатной выдаче новых ключей/сертификатов никто не пишет, только о том, что за это денег приходится платить :)
А что значит другую криптобиблиотеку использовать? Из под винды на Люникс уйти? Эта Джакарта специально для ЕГАИС выпускалась и должна работать с тем комплектом ПО, который для нее написан. Она же не зря PKI/ГОСТ/SE называется. Для нее специальное условие неуменьшаемый счетчик ЭП, выполненных на этом токене и включение номера апплета и содержания счетчика в состав ЭП подписываемого документа. Может сейчас уже что и появилось от сторонних производителей, но первоначально там все исключительно свое, егаисовское было.
Почему оно блочится под виндой, но не под линуксом? Софт под виндой некорректно работает с ключиком?
Скорее всего да. И причина может быть в опросах носителя софтом. Например, программа проверяет — воткнут носитель или нет в порт. Джакарта насчитала, например, тысячу опросов и отключилась. Выдернули из порта, воткнули по новой — Джакарта опять тысячу опросов насчитала и выключилась по новой. Но такое поведение не для всех токенов справедливо. Это какая-то партия себя так ведет. Потому что на десяток штук всего одна такая хитрая попалась. При чем, если программа не запущена, то эта Джакарта может жить сутками не выключаясь. Запустили программу — и начались отключения.
ТС пометил ключи как экспортируемые (в пункте 1), а потом удивляется почему ему удалось их скопировать на другой носитель. Если эту галку не ставить, то и скопировать средствами СКЗИ ничего не удастся, даже если генерить на обычную флешку. Такие ключи (не экспортируемые), хоть и можно потом скопировать с флешки вручную, все равно их использовать на другом носителе не получится (без бубна).
Много страшных слов. А то что действительно важно, то есть закрытый RSA ключ на котором и генерятся сертификаты, по прежнему в безопасности.
Автор немного перепутал две задачи:
1. использовать Токен как флешку для хранения файлов с ключевой информацией и сертификата открытого ключа;
2. использовать Токен как смарткарту для формирования неизвлекаемого закрытого ключа.
То есть, если использовать JaCarta/ГОСТ или RuToken ЕЦП 2.0 по из прямому назначению — как СКЗИ, а не как дискету для контейнеров Крипто-ПРО, то извлечь закрытый ключ не получится ни каким образом. Он никогда не покидает защищенную память Токена и не попадает в ОЗУ компьютера. Все действия с использованием этого закрытого ключа осуществляются внутри Токена.
Проверить это утверждение можно на следующем комплекте:
Аппаратная часть Токены:
JaCarta/ГОСТ;
RuToken ЕЦП 2.0;
ФОРОС от Смарт-парка (http://smart-park.ru/index.php/products/usb-keys/97-usb-keys-foros.html)
Программа — Эникриптер — эникриптер.рф.
Ссылка на программу www.atlas-2.ru/files/U/100345/4//anycrptr.exe
Пробный период — две недели без денег.
Выпустить можно в самой программе самоподписанные сертификаты под ГОСТ, без обращения в УЦ, с записью ключевых документов и сертификата на вышеуказанные Токены. Документация с описанием как сделать есть.
И после этого попытаться вытащить сформированный закрытый ключ.
На любой из операций — при любом взаимодействии с Токеном.
О результатах отписаться.
Сразу скажу, что производители перечисленных токенов утверждают, что закрытые ключи, сформированные средствами токенов не извлекаются ни при каких обстоятельствах.
1. использовать Токен как флешку для хранения файлов с ключевой информацией и сертификата открытого ключа;
2. использовать Токен как смарткарту для формирования неизвлекаемого закрытого ключа.
То есть, если использовать JaCarta/ГОСТ или RuToken ЕЦП 2.0 по из прямому назначению — как СКЗИ, а не как дискету для контейнеров Крипто-ПРО, то извлечь закрытый ключ не получится ни каким образом. Он никогда не покидает защищенную память Токена и не попадает в ОЗУ компьютера. Все действия с использованием этого закрытого ключа осуществляются внутри Токена.
Проверить это утверждение можно на следующем комплекте:
Аппаратная часть Токены:
JaCarta/ГОСТ;
RuToken ЕЦП 2.0;
ФОРОС от Смарт-парка (http://smart-park.ru/index.php/products/usb-keys/97-usb-keys-foros.html)
Программа — Эникриптер — эникриптер.рф.
Ссылка на программу www.atlas-2.ru/files/U/100345/4//anycrptr.exe
Пробный период — две недели без денег.
Выпустить можно в самой программе самоподписанные сертификаты под ГОСТ, без обращения в УЦ, с записью ключевых документов и сертификата на вышеуказанные Токены. Документация с описанием как сделать есть.
И после этого попытаться вытащить сформированный закрытый ключ.
На любой из операций — при любом взаимодействии с Токеном.
О результатах отписаться.
Сразу скажу, что производители перечисленных токенов утверждают, что закрытые ключи, сформированные средствами токенов не извлекаются ни при каких обстоятельствах.
Автор немного перепутал две задачи:
1. использовать Токен как флешку для хранения файлов с ключевой информацией и сертификата открытого ключа;
2. использовать Токен как смарткарту для формирования неизвлекаемого закрытого ключа.
Автор не путал :), он хотел как раз это и объяснить. Путают продавцы.
Да ладно, чего хотеть от девочки, продавца бакалейных товаров?
Она же продает товар артикул номер, не зная вкуса, и отличает продаваемое только по цвету упаковочного конверта…
Т.е. — она явно не специалист с высшим образованием в области информационной безопасности. Просто симпатичная!
Шучу.
А в целом предложение попробовать вышеописанный комплект и отписаться о результатах остается в силе.
Потому что у Крипто АРМа свой подход к работе с Токенами.
Он тоже может использовать их как флешку для контейнеров, а может и как СКЗИ с не извлекаемым ключом.
С Эникриптером ситуация однозначна — если РуТокен, ДжаКарта или Смарт-Парк (ФОРОС или Магистра) — то только неизвлекаемый закрытый ключ (полная спецификация изготовителя СКЗИ), Если Крипто ПРО или Вип-НЕТ, то софтверные контейнера с записью на диск.
Дальше средствами Крипто ПРО или Вип-НЕТа можно гонять как бог на душу положит, но это будет операция копирования файлов с одного носителя на другие. С соответствующими проблемами сохранения закрытого ключа в неприкосновенности.
Она же продает товар артикул номер, не зная вкуса, и отличает продаваемое только по цвету упаковочного конверта…
Т.е. — она явно не специалист с высшим образованием в области информационной безопасности. Просто симпатичная!
Шучу.
А в целом предложение попробовать вышеописанный комплект и отписаться о результатах остается в силе.
Потому что у Крипто АРМа свой подход к работе с Токенами.
Он тоже может использовать их как флешку для контейнеров, а может и как СКЗИ с не извлекаемым ключом.
С Эникриптером ситуация однозначна — если РуТокен, ДжаКарта или Смарт-Парк (ФОРОС или Магистра) — то только неизвлекаемый закрытый ключ (полная спецификация изготовителя СКЗИ), Если Крипто ПРО или Вип-НЕТ, то софтверные контейнера с записью на диск.
Дальше средствами Крипто ПРО или Вип-НЕТа можно гонять как бог на душу положит, но это будет операция копирования файлов с одного носителя на другие. С соответствующими проблемами сохранения закрытого ключа в неприкосновенности.
Главная недоговоренность у автора статьи в том что речь ведется о работе с токеном через Крипто Про CSP.
Кто не знает — Крипто Про хранит ключи и сертификаты на токене в отдельной папке и в обычных бинарных файлах. В результате токен обеспечивает только авторизацию для доступа к данным файлам. Так что все вопросы к Крипто-Про.
Если работать с сертификатами через pkcs11 или через CSP от производителя токена (не у всех есть), в крайнем случае через APDU команды напрямую то закрытые ключи генерятся на токене и извлечь их нельзя.
Так же автор почему то не упоминает что есть и токены реализующие ГОСТ алгоритмы нативно а не через Java-апплет. Например указанный выше MS-KEY K. Там вообще нет Java-машины и скорость повыше.
Кто не знает — Крипто Про хранит ключи и сертификаты на токене в отдельной папке и в обычных бинарных файлах. В результате токен обеспечивает только авторизацию для доступа к данным файлам. Так что все вопросы к Крипто-Про.
Если работать с сертификатами через pkcs11 или через CSP от производителя токена (не у всех есть), в крайнем случае через APDU команды напрямую то закрытые ключи генерятся на токене и извлечь их нельзя.
Так же автор почему то не упоминает что есть и токены реализующие ГОСТ алгоритмы нативно а не через Java-апплет. Например указанный выше MS-KEY K. Там вообще нет Java-машины и скорость повыше.
Крипто ПРО тоже разные бывают. Есть такой комплект, который называется Крипто ПРО еТокен ГОСТ вер. 3.9.
Так он работает с Джакартой через PKCS#11, в результате генерится неизвлекаемый из памяти еТокена закрытый ключ. То есть так как и положено для работы со смарт-картой с крипто процессором на борту. Там, правда, тоже свои заморочки с форматами упаковки Крипто ПРО. А именно сертификат укладывается на Джакарту как бинарный объект, и простой Гость его как сертификат не видит. Это специально для того, что бы халявы не было, для Крипто ПРО онли…
Так он работает с Джакартой через PKCS#11, в результате генерится неизвлекаемый из памяти еТокена закрытый ключ. То есть так как и положено для работы со смарт-картой с крипто процессором на борту. Там, правда, тоже свои заморочки с форматами упаковки Крипто ПРО. А именно сертификат укладывается на Джакарту как бинарный объект, и простой Гость его как сертификат не видит. Это специально для того, что бы халявы не было, для Крипто ПРО онли…
Спасибо за статью. Смог пройти квест получения ЭЦП с неэкпортируемым ключом за 700 руб. Застрял на том что для привязки сертификата к ключу в утилите рутокен его надо было сконвертировать из PEM в DER (openssl отлично справился). И почему-то показывает что сертификат невалидной цепочкой доверия, но на госуслуги пускает по нему.
Валидность цепочек доверия обуславливается настройкой доверия в локальном хранилище сертификатов.
Sign up to leave a comment.
Извлечение ключа из токена с неизвлекаемым ключом