Довольно часто при оформлении сертификатов ключей электронной подписи можно наблюдать навязчивый пиар токенов с неизвлекаемым ключом. Продавцы из удостоверяющих центров уверяют, что, купив у них СКЗИ КриптоПРО CSP и токен с неизвлекаемым ключом (Рутокен ЭЦП или JaCarta ГОСТ), мы получим сертифицированные СКЗИ, обеспечивающие 100%-ную защиту от кражи ключей с токена. Но так ли это на самом деле? Для ответа на этот вопрос проведем простой эксперимент…
Конфигурация тестового стенда
Соберем тестовый стенд с конфигурацией, типовой для машин, участвующих в электронном документообороте (ЭДО):
- ОС MS Windows 7 SP1
- СКЗИ КриптоПРО CSP 3.9.8423
- Драйверы Рутокен для Windows (x86 и x64). Версия: v.4.1.0.0 от 20.06.2016, WHQL-certified
- Единый Клиент JaCarta и JaCarta SecurLogon. Версия 2.9.0 сборка 1531
- КриптоАРМ Стандарт Плюс 5. Версия 5.2.0.8847.
Для тестирования будут использоваться токены с неизвлекамым ключом:
- Рутокен ЭЦП. Версия 19.02.14.00 (02)
- JaCarta ГОСТ. Номер модели JC001-2.F09 v2.1
Методика тестирования
Смоделируем типовой процесс подготовки Администратором информационной безопасности ключевых документов для организации ЭДО:
- генерируется контейнер закрытого ключа и запрос на сертификат открытого ключа;
- после прохождения в удостоверяющем центре процедуры сертификации из запроса получается сертификат;
- сертификат в совокупности с контейнером закрытого ключа образует готовую для использования ключевую информацию. Данную ключевую информацию, записанную на носителе, будем называть исходным ключевым документом;
- с исходного ключевого документа изготавливаются копии, которые записываются на отчуждаемые носители (далее будем называть их рабочими ключевыми документами) и передаются уполномоченным пользователям;
- после изготовления необходимого количества рабочих ключевых документов исходный ключевой документ уничтожается или депонируется на хранение в орган криптографической защиты информации.
В нашем случае мы не будем пользоваться услугами центров сертификации, а сгенерируем ключевой контейнер с самоподписанным сертификатом и разместим его в реестре компьютера (АРМа генерации ключевой информации), это и будет исходный ключевой документ. Затем скопируем ключевую информацию на Рутокен ЭЦП и JaCarta ГОСТ, изготовив рабочие ключевые документы. После этого уничтожим исходный ключевой документ, удалив из реестра ключевой контейнер. И, наконец, попробуем скопировать ключевую информацию с рабочих ключевых документов обратно в реестр.
Проведение тестирования
1. Создадим исходный ключевой документ.
2.Сформируем рабочие ключевые документы.
Описание приведено применительно к JaCarta ГОСТ (для Рутокен ЭЦП действия аналогичны):
Таким образом получили рабочие ключевые документы на JaCarta ГОСТ (контейнер test-key-jacarta) и Рутокен ЭЦП (контейнер test-key-rutoken).
3.Уничтожим исходный ключевой документ
4. Скопируем ключевую информацию из рабочих ключевых документов
Описание приведено для JaCarta ГОСТ (для Рутокен ЭЦП действия аналогичны).
Как мы видим, ключевая информация успешно скопирована или, другим языком, извлечена из токенов с неизвлекаемым ключом. Получается, что производители токенов и СКЗИ врут? На самом деле нет, и ситуация сложнее, чем кажется на первый взгляд. Исследуем матчасть по токенам.
Матчасть
То, что на рынке принято называть токеном с неизвлекаемым ключом, правильно называется функциональным ключевым носителем (ФКН) (доп. инфо).
Главным отличием ФКН от обычных токенов (Рутокен S, JaCarta PKI, …) в том, что при выполнении криптографических преобразований (например, формирование электронной подписи) закрытый ключ не покидает устройство. В то время как при использовании обычных токенов закрытый ключ копируется с токена в память комптьютера.
Использование ФКН требует особой организации взаимодействия между прикладным криптографическим ПО и библиотекой СКЗИ (криптопровайдером или, по-другому, CSP).
Здесь важно увидеть, что программная часть библиотеки СКЗИ должна знать о существовании на токене апплета, реализующего криптографический функционал (например, генерация ключа, подпись данных и т.д.) и уметь с ним работать.
По-новому взглянем на наш тестовый стенд
В качестве одного из ключевых носителей использовался Рутокен ЭЦП. Через «Панель управления Рутокен» о нем можно получить следующую информацию:
В последней строке указана фраза «Поддержка КриптоПРО ФКН: Нет», а это значит, что на токене нет апплета, с которым умеет работать СКЗИ КриптоПРО CSP. Таким образом, реализация технологии ФКН с использованием СКЗИ и токенов, описанных в конфигурации тестового стенда, невозможна.
Аналогичная ситуация и с JaCarta ГОСТ. Более того, СКЗИ КриптоПРО CSP, по крайней мере та версия, которая использовалась в тестовом стенде, использует данные ключевые носители как «обычные токены», которые, в свою очередь, являются просто носителями ключа.
Это утверждение очень просто подтвердить. Для этого надо поставить СКЗИ КриптоПРО CSP на чистую машину без драйверов от токенов и подключить токен JaCarta ГОСТ. ОС Windows 7 обнаружит токен JaCarta ГОСТ как «Устройство чтения смарт-карт Microsoft Usbccid (WUDF)». теперь можно попробовать создать ключ на токене и скопировать его в реестр компьютера. Весь функционал СКЗИ успешно отработает.
Как сделать, чтобы все было хорошо?
Чтобы с помощью продуктов ООО “КРИПТО-ПРО” реализовать технологию ФКН, необходимо:
1. Купить специальную версию библиотеки СКЗИ:
— для Рутокен ЭЦП — СКЗИ КриптоПРО Рутокен CSP.
— для JaCarta ГОСТ – СКЗИ КриптоПро ФКН CSP.
2. Одновременно с библиотекой СКЗИ необходимо приобрести специально подготовленные токены, содержащие в себе программные части (апплеты), с которыми умеет работать КриптоПРО Рутокен CSP или КриптоПро ФКН CSP соответственно.
Получается, что Рутокен ЭЦП и JaCarta ГОСТ не являются токенами с неизвлекаемым ключом?
Опять нет. Данные устройства могут реализовывать функционал ФКН (но, возможно, в меньшем объеме, чем при использовании их совместно с СКЗИ КриптоПРО), но для этого нужен софт, который умеет работать с апплетами размещенными на токенах. Таким софтом может быть КриптоАРМ Стандарт 5 Плюс. Он это умеет. При генерации ключевой пары в мастере КриптоАРМ можно выбрать криптопровайдер, который будет использоваться, например, Rutoken ECP или eToken GOST. Это и позволит использовать токен как ФКН.
Выводы
- Не верьте продавцам, чушь вам городящим. Использование обычных версий криптопровайдера КриптоПРО CSP и обычных Рутокен ЭЦП или JaCarta ГОСт не позволяют реализовать технологию ФКН.
- Для использования технологии ФКН совместно с продуктами ООО «КРИПТО-ПРО» необходимы как специально подготовленные токены, содержащие апплет, с которым умеет работать СКЗИ, так и специальные версии криптопровайдера КриптоПРО CSP, которые умеют работать с апплетом на токенах.
- Рутокен ЭЦП и JaCarta ГОСТ умеет самостоятельно реализовывать технологию ФКН, но для этого необходим специальный софт.
Комментарии (126)
dosbear
25.07.2016 10:01Заголовок доставил. Думается, что УЦ, который выдал экспортируемую КЭП за такое может получить от Минкомсвязь России.
Помню были времена, когда УЦ выдавали ЭП на дискетах. Вот тогда ЭП часто копировали и извлекали.
imbasoft
25.07.2016 10:15Немного не так.
УЦ — обычно применяют распределенную схему генерации ключей. В данной схеме они ожидают от нас запрос на сертификат + подписанные бумажки, после получения которых они выпускают сертификат. Генерацию ключей и размещение их на носителях осуществляет пользователь.
Но когда вы «покупаете подпись», то вам скорее всего понадобятся СКЗИ и токены, вот здесь и проявляют себя продавцы в полную силу и начинают продавать то, что вам не надо.
all_777
25.07.2016 11:06Я, к сожалению, на прошлой неделе тоже «вспомнил», когда подошла бухгалтер и положила дискетку. Найти флоппик тот еще квест. А Вы помню были времена говорите… :)
BigW
25.07.2016 12:12Нигде в законах и подзаконных ФСБ я не помню упоминания о том что ключи должны быть неэкспортируемые. Есть только требования выдавать на ключевых (читай защищенных) носителях. Сертификат у токенов есть — все ок. Так же я нигде не помню прямого запрета хранить УЦ закрытые ключи пользователей (если генерация происходит не самостоятельно — 90% как мне кажется, всех случаев)… Так что с точки зрения закона — все ок.
imbasoft
25.07.2016 12:35+3С точки зрения закона — ок. С точки зрения документации на СКЗИ — ок. С точки зрения потребителя — не ок.
Проблема в том, что описываемый в статье случай, это что-то из разряда ввода потребителя в заблуждение.
Sheti
25.07.2016 21:35+1В гос. учреждениях в связи с ФЗ-44 работу с ключами скинули на сами учреждения. Выдали ПО для генерации, а дальше сами. Сами флэшку ищем, сами генерируем, сами ставим. Обеспечить в этих условиях все требования по работе с СКЗИ просто элементарно не возможно.
imbasoft
26.07.2016 09:13Вспоминается забавная ситуация.
Удостоверяющий центр Федерального казначейства ведет прием документов на изготовление ключей. Подходит дедушка, приносит документы и флешку.
Оператор УЦ смотрит флешку и говорит, у вас вместо запросов на сертификат на флешки лежат закрытые ключи.
Дед — А какая разница?Sheti
26.07.2016 11:51Ну к сожалению всё так бывает. Я лигбез по ключам проводил, но не думаю, что в голове что-то отложилось. Ключи утащить в таких учреждениях вообще не проблема. Благо этими ключами особо ничего не сделаешь.
BlancLoup
25.07.2016 10:07+1Автор, подскажите… какой именно функционал содержит апплет в аппаратной части? Точнее: можно ли с помощью него реализовать шифрование ГОСТ без установки ГОСТ-криптобиблиотек непосредственно на рабочую станцию. То есть пришел на любой комп и воткнул токен с ГОСТ и все крипто-апи запросы, например при TLS, пробрасываются непосредственно к аппаратной части?
areht
25.07.2016 10:19+1Вы же догадываетесь, что там чип, мягко говоря, не быстрый?
imbasoft
25.07.2016 10:33+1Из документации на токены.
На примере JaCarta — http://aladdin-rd.ru/catalog/jacarta/gost/specification. В ней исползуется чип — http://pdf1.alldatasheet.com/datasheet-pdf/view/255626/ATMEL/AT90SC25672RCT.html
BlancLoup
25.07.2016 11:02Догадываюсь… но возможно есть хитрый способ использования таких токенов просто как хранилища криптобиблиотек. Ну не знаю. Как место хранения длл-ек. Очень условно если говорить.
imbasoft
25.07.2016 10:24+1Автор, подскажите… какой именно функционал содержит апплет в аппаратной части?
Про функционал не подскажу, этот вопрос лучше адресовать производителям токенов. Неплохая документация по токенам — http://dev.rutoken.ru/
Точнее: можно ли с помощью него реализовать шифрование ГОСТ без установки ГОСТ-криптобиблиотек непосредственно на рабочую станцию.
В общем случае так сделать нельзя. Прикладное ПО (например, MS outlook) обращается к крипторафическим библиотека по какому либо стандартному интерфейсу, например MS CryptoAPI. Для того чтобы этот интерфейс был доступен и нужны криптопровайдеры. НО. Можно пойти по пути как сделал КриптоАРМ. Они умеют самостоятельно общаться с токеном, фактически реализуя встроенную криптобиблиотеку.
BigW
25.07.2016 14:59+1Если посчитать описание по ссылке https://habrahabr.ru/post/306034/#comment_9714356 проблема в чипах… (АУууу импортозамещение… )на уровне железа чип поддерживает только RSA, DES, 3DES, SHA-1 (так же как и etoken)… Для госта нужен апплет, для апплета нужно ПО, т.к. контроллер 8 битный — все работает жутко медленно… (Для RSA есть специальные 32 битные функция, и если я правильно понял операции происходят за 1 такт)
Выпускаем чип, поддерживающий гост «из коробки» — никакое ПО (кроме дров) не нужно. Но это удар по таким гигантам как Крипто-про и Инфотекс т.к. все будет работать, имхо, через openssl+токен напрямую (сейчас есть существенные заморочки)imbasoft
25.07.2016 15:31+1… все будет работать, имхо, через openssl+токен напрямую
А в чем координальное отличие? Вместо CSP будет требоваться OpenSSL, один cliet-side софт меняется на другой.
Утверждать что OpenSSL более безопасный чем тот же КриптоПРО CSP считаю не корректным. Надо сравнивать по моделям угроз и ТЗ систем для которых применяется СКЗИ.
В тоже время если вопрос в деньгах, то можно использовать бесплатный криптопровайдер VIPNET CSP или бесплатную версию КриптоПРО CSP (она становится таковой, когда заканчивается триал) правда у нее нет возможности формировать ЭП, можно только проверять.BigW
25.07.2016 15:43+1Кардинальных отличий, пожалуй нет, но:
1) На текущий момент Криптопровайдер Vipnet CSP не может работать с подписью КриптоПРО CSP и наоборот — разный контейнеры закрытого ключа
2) реализовать через них TLS можно, но в достаточной степени геморройно, хотя не так давно (пару недель) крипто ПРО выпустили движок для openssl и прикрутить приптопрошную подпись к сайту стало на порядок легче (сам еще не пробовал)
3) про безопасность я тут умолчу, т.к. полностью с вами согласен что сравнивать как минимум сложно
4) тот же серверный крипто-про стоит 60к руб… Для пользователей, согласен, есть некоторые варианты обойтись бесплатными версиями…imbasoft
25.07.2016 16:06+21) На текущий момент Криптопровайдер Vipnet CSP не может работать с подписью КриптоПРО CSP и наоборот — разный контейнеры закрытого ключа
Уточним. VIPNET CSP не может работать с ключевыми контейнерами сформированными КриптоПРО CSP, Но вы без проблем можете подписать запрос на сертификат сгенерированный из VIPNET CSP с помощью УЦ работающего на КриптоПРО CSP.
Поэтому тут вопрос скорее к Росстандарту и ФСБ России о том, что необходимо стандартизировать формат ключвых контейнеров.
2) реализовать через них TLS можно, но в достаточной степени геморройно,
Я бы сказал тут дело привычки. Поднять TLS на IIS+КриптоПРО CSP (серверный вариант) у меня занимало порядка 2-3 минут. Под *nix было сложнее.
В остальном согласен, за исключением цены — «Лицензия на право использования СКЗИ „КриптоПро CSP“ версии 3.9 на сервере 30 000,00р.», но тоже дороговато.
Проблема наших СКЗИ в том, что их преимущества для пользователей не очевидны.
По криптографии (взлом криптоалгоритма, баги криптосхем и т.д.) информационные системы ломают крайне редко, поэтому для обычного пользователя что отечественная библиотека СКЗИ, что импортная обеспечивают сравнимый уровень защиты, но в тоже время отечественные системы стоят денег, и порой довольно больших.
Более того, сама система использования отечественных СКЗИ — сертификация, реализация требований документации, и нормативки, например ФАПСИ 152 превращает все это просто в кошмар.BigW
25.07.2016 19:57Спасибо за уточнение, мне следует более ясно выражать свои мысли :)
— Да, опять же вы правы, запрос можно генерировать на vipnet и удовлетворить на УЦ криптопро и обратно — генерировать, например КриптоАРМ, и удовлетворять запрос на УЦ Vipnet.
-по поводу TLS так уж сложилось, что мы в организации сталкиваемся в основном со связкой «сервер приложений на линукс + сервер Бд на нем же», поэтому танцы с бубном актуальны, но по ощущениям с крипто-про проблем меньше (то ли просто делают качественнее, то ли дело в том, что продукт платный, то ли разработчики чаще с крипто-про дело имеют — не берусь судить).
-Уф, не пугайте меня так с ценой, я аж поперхнулся, месяц как смету верстали… :):):) говорил про «Лицензия на право использования СКЗИ „КриптоПро JCP“ на одном сервере с двумя ядрами (или с 4 ядрами с отключенным Hyper Threading», но, в общем-то, несущественное уточнение… надо яснее выражать свои мысли :(((
— А по поводу стандартизации и документов, и документов ФСБ в частности — вообще больная тема. они 795 приказ никак под актуальную редакцию 63 фз дописать не могут, не говоря про остальное:((((
152 и прочее — растет из гостайны, и гостайну и конфиденциалку (ЭП в частности) они разделять на уровне СКЗИ упорно не хотят. видимо, есть причины…
a513
26.07.2016 11:53А почему бы не использовать токены PKCS11, разработанные в соответствии с рекомендациями ТК26 ( https://www.tc26.ru/methods/project/PKCS11_v18.pdf ), и NSS?
vserg
25.07.2016 10:12Не в галке дело. По простому говоря если ключ генерировали внутри токена(выбирая провайдер правильный криптопровайдер.) то извлечь «стандартным» способом не выйдет.
Носители с извлекаемыми ключами дороже. Поэтому наверное самые распространенные это обычные токены.
Автор говорит что даже токены с не извлекаемыми ключами надо правильно готовить ))
KDorokhov
25.07.2016 10:20-5Я не Админ ИБ. Но статья понравилась.Четко, по делу. Можно в «Настольная Библия АИБа» вносить.
Спасибо!
\\Картинка огненная и в тему. Точно не помню из книги или диафильма.
IT_SECURITY
25.07.2016 11:16+3Во-первых, в используемых для аутентификации токенах не должно быть никакой возможности экспорта ключа. Во-вторых, должны использоваться открытые алгоритмы и технологии, а не кривое только-под-винду-Xp проприетарное ПО.
И на токене должна быть железная кнопка для ответа на запрос хоста — чтобы трояны не могли подбирать потихоньку пароль.
Ну и нужны дополнения в HTTP протокол, чтобы веб-сервисы поддерживали Challenge-Response. Тогда можно было бы отказаться от логинов/регистраций: такие данные, как email и имя хранились бы в токене, вход на сайт и регистрация происходили бы автоматически при вставленном токене.
Потерялся бы смысл в фишинге, троянах для воровства паролей. Не надо было бы запоминать или записывать сложные пароли. Имея несколько токенов, можно легко перелогиниваться. Пользвоателям было бы проще и безопаснее жить.
merlin-vrn
25.07.2016 11:39+2Ну и нужны дополнения в HTTP протокол, чтобы веб-сервисы поддерживали Challenge-Response. Тогда можно было бы отказаться от логинов/регистраций: такие данные, как email и имя хранились бы в токене, вход на сайт и регистрация происходили бы автоматически при вставленном токене.
Надо, чтобы браузер при работе с HTTPS умел использовать токены, а не только брать сертификаты из своего хранилища. Всё. С точки зрения сервера это простейшая аутентификация по ключу клиента, например мы такую уже сто лет в обед используем; в дикой природе можете посмотреть, как это работает, на сайте StartSSL. Соответственно на сервере указывается ЦС, которым выдан клиентский сертификат (ключ от которого в данном случае на токене), и для аутентификации можно использовать серийник, CN и т. д., любые поля сертификата клиента.
Никаких дополнений в протокол не нужно — вcё необходимое уже давно имеется.a1ien_n3t
25.07.2016 20:48>Надо, чтобы браузер при работе с HTTPS умел использовать токены, а не только брать сертификаты из своего хранилища.
А они и умеют(вовсяком случае Firefox). Добавляем библиотеку opensc в список security devices и все. И можем пользоватся логином по сертефикатам с неизвлекаемых токенов.a513
26.07.2016 18:21Ни только умеют работать с токенами PKCS11, но и с токенами с российской криптографией
http://soft.lissi.ru/solution/mozilla/
a1ien_n3t
26.07.2016 18:50Я уже писал вам что на часть ссылок с этого сайт все браузеры жалуются. А вы продолжаете на него давать ссылку.
И как там с MPL дела обстоят?a513
26.07.2016 19:32-1https://www.mozilla.org/ru/about/legal/terms/firefox/
О ваших правах
Mozilla Firefox — бесплатная программа с открытым исходным кодом, созданная многотысячным сообществом пользователей и разработчиков со всего мира. Вот несколько аспектов, о которых вам следует знать:
— Firefox предоставляется вам на условиях Публичной лицензии Mozilla. Это значит, что вы можете использовать, копировать и распространять Firefox. Вам также разрешается изменять исходный код Firefox в соответствии с вашими потребностями. Кроме того, публичная лицензия Mozilla даёт вам право распространять изменённые вами версии.
— т.д.a1ien_n3t
26.07.2016 19:56А теперь ознакомтесь с текстом лицензии. И поймите, что на этом сайте происходит ее нарушениее.
a513
27.07.2016 09:17-1И все же в чем у вас притензии?
В том что ребята модифицировали Mozilla для работы с российской криптографией, а вы нет?
Ведь они проделали огромную работу:
— проанализировали исходный код Mozilla (Firefox, Thunderbird, Seamonkey — http://soft.lissi.ru/solution/seamonkey/ ), исходный код NSS (Network Security System), разработали токены с поддержкой российской криптографии — http://soft.lissi.ru/about/news/2016/05/73/;
— при чем все это для различных платформ, включая Android — http://soft.lissi.ru/solution/android/;
— их бы поддержать, но кто их поддержит у нас ?!
— если вы нашли какие-то недочеты (вот вы говорите — ознакомтесь с текстом лицензии), так Подскажите им в чем они неправы, в чем они ошибаются.
А с точки зрения программиста — честь и хвала им.a1ien_n3t
27.07.2016 09:35Хватит постить линки, на каждый чих. Сдается что вы напрямую связанны с сайтом.
Как минимум если были изменения в исходном коде то больше нельзя использовать логотипы и исходное название продукта.jabr
27.07.2016 09:49«если были изменения в исходном коде то больше нельзя использовать логотипы и исходное название продукта»
т.е. «КриптоПро Fox» в этом плане кошерно?a1ien_n3t
27.07.2016 10:06Да. только еще и лого должно быть другое.
Например вот история названий форка у debian https://ru.wikipedia.org/wiki/Iceweasel
a513
27.07.2016 10:51https://ru.wikipedia.org/wiki/Iceweasel
Спустя десять лет в 2016 году прежние разногласия были урегулированы и браузер Iceweasel решено переименовать обратно в Mozilla Firefox[3].
merlin-vrn
27.07.2016 11:11+1Ладно, дебиану позвоили. Это исключение из правила сделано только для дебиана, не сомневайтесь, в тексте лицензии ничего не поменялось. А этим гаврикам никто не разрешал использовать ни название, ни логотипы.
a513
02.08.2016 18:49Похоже они учли ваши замечания — http://soft.lissi.ru/solution/mozilla/
a1ien_n3t
02.08.2016 22:36Ну почти, осталось только лого заменить.
a513
03.08.2016 09:59Странно, там написано (http://soft.lissi.ru/solution/mozilla/ ):
«Вместе с тем Mozilla накладывает ограничения на использование своих логотипов и торарных знаков в модифицированных версиях своих продуктов. Исходя из этого было принято решение дать модифицированным версиям свои названия:
-браузер Redfox (Красная Лиса), т.е. доработанный с целю поддержки российской криптографии браузер Firefox (Огненный Лис );
-почтовый клиент RedfoxMail, т.е. доработанный с целю поддержки российской криптографии почтовый клиент Thuderbird
— интегрированный пакет Redfox2in1, т.е. доработанный с целю поддержки российской криптографии пакет SeaMonkey.
Каждый из этих продуктов получил и свой логотип: см. http://soft.lissi.ru/images/red/1.png
AlexBT
27.07.2016 11:19Ну с Мозиллой без всяких модификаций работает и РуТокен через подключаемую собственную библиотеку.
a513
27.07.2016 11:37Здесь речь идет прежде всего о ГОСТ-ом HTTPS (TLS-1.0, TLS-1.0, TLS-1.2) с российскими шифрсьютами (TLS_GOSTR341001_WITH_28147_CNT_IMIT и TLS_GOSTR341112_256_WITH_28147_CNT_IMIT ), рекомендованными к использованию Техническим комитетом 26 (ТК 26).
AlexBT
27.07.2016 14:11А вот тут было бы неплохо, что бы Лисси выложила работающий демокомплект, что бы пользователи оценили все прелести шифросьютов, рекомендованных к использованию техническим комитетом 26.
Потому что одно дело поговорить про ТК26, другое дело показать товар лицом!
merlin-vrn
27.07.2016 11:09Извините, какой мне use-флаг использовать, чтобы собралось с поддержкой российской криптографии?
maxdm
25.07.2016 11:27+2Надо отметить, что формулировка о функционале ФКН без модулей КриптоПро не вполне верна: технология ФКН предполагает все же более безопасное использование токена, защищающее канал работы с ним (что может быть критичным, например, при удаленной работе). Подробнее об этом написано по указанной Вами ссылке, а также в статье О выработке неперебираемых ключей на основе перебираемых паролей
whirl
25.07.2016 11:30+1Во-вторых, должны использоваться открытые алгоритмы и технологии, а не кривое только-под-винду-Xp проприетарное ПО.
Ну мы же в России живем. Это же крипто про, какие открытые алгоритмы и технологии?
Не забудьте, что номер каждого токена должен быть вписан в пасспорт чтобы все знали кто есть кто
imbasoft
25.07.2016 13:13+1Уважаемый коллега, из КРИПТО-ПРО, согласен что аббревиатура ФКН это «ваше изобретение» (в хорошем смысле)
Когда писал статью, долго думал как назвать «токены с не извлекаемым ключом» по науке. Вы в своих статьях упоминаете термины «активный вычислитель» и др., на мой взгляд предлагаемые термины немного сложны для понимания не криптографам.
С другой стороны Функциональный ключевой носитель (ФКН) — сообщает базовые характеристики устройства:
— выполнение функций,
— хранение ключа.
Другое дело в том, что ваша реализации ФКН, возможно более продвинутая по сравнению с другими (ФКН от КРИПТО-ПРО, обеспечивает защиту канала связи между токеном и ЭВМ).
Таким образом термин ФКН на мой взгляд наиболее удачен в данном случае.
Peter-mad
25.07.2016 12:11-1Добрый день.
Статья называется: «Извлечение ключа из токена с неизвлекаемым ключом».
Так вот, если вы собрались делать «неизвлекаемый ключ», то хотя бы генерируйте сертификат не извлекаемым.
В пункте 1. Создадим исходный ключевой документ. — 4-й скриншот, стоит галка, которая все портит.
Поэтому Ваша «Методика тестирования» неверна.
И на заметку, у любого нормального УЦ по регламенту запрещено делать экспортируемые ключи и не при чет тут апплеты и технология ФКН.
merlin-vrn
25.07.2016 12:17Сертификат всегда извлекаем (и должен быть таковым), содержит в себе открытый ключ, а также дополнительные данные, и всё это подписано закрытым ключом УЦ (подпись естественно тоже публикуется). Часто ещё в бандл добавляется собственно сертификат УЦ, которым это всё подписано.
Неизвлекаемым должен быть и может быть именно закрытый ключ.
По поводу методики тестирования: сделать ключ и попытаться его извлечь — это нормальная методика, если стоит целью проверить, что ключ можно извлечь. Как вы себе представляете другую методику?
Peter-mad
25.07.2016 12:26Как? Не ставить эту галку. Именно так делается в УЦ. Просто потом людям голову дурят, что можно из любого токена вытащить закрытый ключ.
imbasoft
25.07.2016 13:20+1УЦ по распределенной схеме галки не ставит вообще никакие, так ключевую пару генерирует пользователь.
А по централизованной схеме, кто во что горазд.
У меня лично был опыт, когда при генерации ключа для ДБО ИКБ меня пустили за компьютер офицера безопасности Банка, ответственного за генерацию ключей, хотя в Банке я был впервые. Поэтому утверждать, что там делает УЦ по централизованной схеме это более чем смело.
А по поводу извлечения ключей — предлагаю просто попробовать. Возьмите (если у вас есть к ним доступ) ключи в вашей организации и попробуйте их скопировать :)
Я думаю после этого вы посмотрите на проблему под другим углом.Peter-mad
25.07.2016 13:32+1Я пишу это смело, т.к. мы являемся удостоверяющим центром. И у меня другой опыт. Ключи в нашей организации не скопируются, это я вам гарантирую.
imbasoft
25.07.2016 14:21+3Готовы на публичный эксперимент? :)
Отмечу, что рассматривается ситуация, когда нарушителю известны пароли и другая аутентификационная информация (например, брелки 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. Кроме это по мимо ключей УЦ вы наверняка еще пользутесь услугами дистанционного банковского обслуживания Интернет Клиент-Банк, а это отдельная песня.msuhanov
25.07.2016 16:48для защиты применяют АПМДЗ Соболь или Аккорд
Я так понимаю, что часть защитных мер осталась родом из мира DOS.imbasoft
25.07.2016 17:11+2В точку, но это прописано, в документации по СКЗИ, сертифицированной по КС2.
Из полезных свойств аппаратного модуля довереной загрузки (АМДЗ) в данном случае является только генератор случайных чисел, все остальное очень натянуто и не выдерживает критики.Kolyuchkin
25.07.2016 17:29Сертификация по уровню КС2 — это для защиты от уборщиц)))))) Поясню: класс защищенности КС2 (в самой понятной для обывателя формулировке) подразумевает защищенность изделия от нарушителей Н2 (нарушитель, имеющий доступ в помещение с защищаемыми техническими средствами, но не являющийся пользователем оных средств) и Н1 (нарушитель, не имеющий доступ в контролируемую зону; для осуществления атак может применять только технические средства, полученные из открытых источников)… Так что, чтобы оспорить качество сертифицированных продуктов, необходимо еще соответствующие условия создать.
msuhanov
25.07.2016 18:27Так что, чтобы оспорить качество сертифицированных продуктов, необходимо еще соответствующие условия создать.
Одним из требований к средствам УЦ для класса КС2 является контроль целостности программных средств. Собственно, аппаратные модули доверенной загрузки могут контролировать целостность данных только в операционных системах не сложнее DOS.Kolyuchkin
25.07.2016 19:19аппаратные модули доверенной загрузки могут контролировать целостность данных только в операционных системах не сложнее DOS
С чего Вы это взяли? АПМДЗ могут контролировать целостность данных независимо от типа ОС. АПМДЗ зачастую и не знают о типе ОС на хосте. Перед загрузкой ОС АПМДЗ могут проверять и файлы в поддерживаемых ФС и отдельные сектора дисков. Так что, какие данные пользователь прикажет проверять, такие АПМДЗ и проверит. А уж с приходом UEFI возможности по контролю расширились)msuhanov
25.07.2016 19:43С чего Вы это взяли?
В современных операционных системах данные могут быть в довольно сложной форме представления, нет никакой гарантии, что предзагрузочный контроль целостности АМДЗ «увидит» то же самое, что «увидит» и сама операционная система после передачи ей управления. Где гарантии, что в АМДЗ такой же, с позиции алгоритмов обработки данных, драйвер файловой системы, что и в Windows? Я занимался обратной разработкой ПО для контроля целостности в Аккорд-АМДЗ (на базе ACDOS и на базе Linux: AMDZ-NG) и могу смело сказать: можно изменить данные так, что контроль их целостности пройдет, но для операционной системы это будут другие данные, потому что «кривой парсер» закрытого формата в АМДЗ не учитывает некоторые состояния данных, которые учитывает операционная система.
А уж с приходом UEFI возможности по контролю расширились)
Наоборот. Например, в некоторых реализациях UEFI возможна загрузка с USB-накопителя после того, как управление будет передано менеджеру загрузки Windows. А вот еще доклад ОКБ САПР.Kolyuchkin
25.07.2016 20:06До недавнего времени и я занимался разработкой АПМДЗ (писал как раз OptionROM для UEFI)… И тоже могу с уверенностью сказать, что коллизии контроля целостности возникают из-за выбранных алгоритмов (в интернете достаточно статей про коллизии CRC16/32).
По второй части Вашего комментария могу так же ответить — все зависит от «конкретной реализации UEFI». Во время отладки я мог вообще что угодно делать с UEFI — чаще получалось ее просто «вешать»))) (это была шутка)
И мне хочется сделать промежуточный итог нашего обсуждения… Вернее, не итог, а просто напомнить, что ветка обсуждения началась с «класса защищенности КС2» и соответствующего этому классу «нарушителя Н2». Поэтому не стоит нас с вами (видимо обладающих специальными знаниями и опыт в соответствующей области) и описанные Вами способы компрометации АПМДЗ приравнивать к знаниям и возможностям «нарушителя Н2».msuhanov
25.07.2016 20:35До недавнего времени и я занимался разработкой АПМДЗ (писал как раз OptionROM для UEFI)… И тоже могу с уверенностью сказать, что коллизии контроля целостности возникают из-за выбранных алгоритмов (в интернете достаточно статей про коллизии CRC16/32).
Речь не об ошибках в алгоритмах расчета контрольных сумм в частности и не о стойкости хеш-функций вообще. АМДЗ, в случае с Windows, должен поддерживать NTFS и реестр (это самый минимум). Вот только никто досконально изучать драйвер NTFS и ядро Windows для реализации такой поддержки не будет, а значит могут существовать (и существуют) случаи, когда собственная реализация NTFS и реестра «видит» одни данные, а Windows – другие. Потому что формат данных закрыт и представление о нем было неполным или ошибочным.
Поэтому не стоит нас с вами (видимо обладающих специальными знаниями и опыт в соответствующей области) и описанные Вами способы компрометации АПМДЗ приравнивать к знаниям и возможностям «нарушителя Н2».
Не буду спорить :-) Но тогда встает вопрос об адекватности выбора модели нарушителя.Kolyuchkin
25.07.2016 21:39Тот АПМДЗ, в разработке которого я принимал участие, поддерживает NTFS (я сам туда вкрячивал NTFS-драйвер), ветки реестра тоже проверяет (это тоже файлы) и даже контролирует журнал транзакций NTFS (это тоже файл). Кстати, эти требования нам выкатило именно ФСБ при согласовании ТЗ. Жаль (или к счастью), но этот АПМДЗ «гражданский сектор» не увидит…
По поводу адекватности выбора модели нарушителя я с Вами полностью согласен. Иногда заказчики умышленно «понижали» степень конфиденциальности информации, лишь бы не платить лишние деньги на СЗИ…msuhanov
25.07.2016 22:29ветки реестра тоже проверяет
У кого-то не проверяется правильность сортировки ключей реестра в записях li/lf/lh/ri. Это значит, что список ключей, «видимый» АМДЗ, может отличаться от списка ключей после монтирования куста в Windows (Windows удалит все ключи, нарушающие порядок сортировки). Еще могут не проверяться ссылки на родительские ключи, что может привести к тому, что Windows удалит деревья ключей с неправильными ссылками при подключении куста (а в АМДЗ такие деревья будут считаться корректными). И так далее, список большой.
и даже контролирует журнал транзакций NTFS (это тоже файл)
$LogFile или TxF? Если что-то одно, то не годится :-)Kolyuchkin
26.07.2016 08:22Насчет анализа содержимого веток реестра я не заморачивался, считая, что если между двумя проверками бинарное содержимое файла не изменилось, то и ОС увидит в них то же самое, что и после предыдущей проверки. Возможно я не прав, не спорю.
Проверял $LogFile, потому как TxF — это технология поддержки транзакционности в NTFS (публичное API, насколько я смог на тот момент разобраться)… И меня отпугнул тот факт, что MicroSoft не рекомендовала ей пользоваться.msuhanov
26.07.2016 12:46что если между двумя проверками бинарное содержимое файла не изменилось
Оно должно изменяться всегда. В кусте SYSTEM, например, при каждой загрузке создается ссылка на выбранную конфигурацию в виде непостоянного ключа, информация о котором записывается в постоянный ключ и обновляется на диске. И так происходит со времен Windows NT 3.1.
BigW
25.07.2016 20:06ставлю свои 5 копеек, все мое имхо:
— АМДЗ применительно к СКЗИ это, конечно, бред. но в связке с СЗИ от НСД тот же SecretNet (да, да в котором дыру нашли, и за обновление формуляров которого на патченую версию, разрабы попросили 25% от стоимости) вроде как работает неплохо. т.к. работает драйвер на уровне системы уже и все нюансы ФС должен нормально учитывать…
— по поводу UEFI мне тоже кажется что с его(?) приходом все эти АМДЗ стали очень сильно неактуальны, при этом в банке угроз ФСТЭК угроз с изменение кода BIOS достаточно много и как от этого защищаться (на бумаге есс-но) кроме как установкой АМДЗ не очень ясно.
— у нас класс СКЗИ определен как КС3, поэтому, формально, у всех должен быть АМДЗ, но проконтролировать нереально…msuhanov
25.07.2016 20:43— АМДЗ применительно к СКЗИ это, конечно, бред. но в связке с СЗИ от НСД тот же SecretNet (да, да в котором дыру нашли, и за обновление формуляров которого на патченую версию, разрабы попросили 25% от стоимости) вроде как работает неплохо. т.к. работает драйвер на уровне системы уже и все нюансы ФС должен нормально учитывать…
Перед передачей управления программному СЗИ надо бы проверить целостность этого СЗИ и целостность его конфигурации, что уже создает проблемы.
— по поводу UEFI мне тоже кажется что с его(?) приходом все эти АМДЗ стали очень сильно неактуальны, при этом в банке угроз ФСТЭК угроз с изменение кода BIOS достаточно много и как от этого защищаться (на бумаге есс-но) кроме как установкой АМДЗ не очень ясно.
Тут можно многое написать, но это уже не совсем по теме обсуждения будет :-)
imbasoft
26.07.2016 09:33Использование АПМДЗ для СКЗИ — пережиток прошлого. В настоящее время эти устройства создают больше проблем, чем обеспечивают безопасность.
Рассмотрим типовой функционал АПМДЗ
1. Про функционал генератора случайных чисел писал — это ок.
2. Контроль целостности. Да АПМДЗ контролирует целостность файлов, хорошо ли плохо вопрос немного другой, но контролирует он ее только в момент перезагрузки системы. А как часто у вас перезагружаются prod. сервера?
То есть пратическая ценность этого функционала близка к 0.
3. Позволяют блокировать загрузку со съемных носителей (CD, floppy,...). Опять таки, как часто перезагружается сервер?
4. Позволяют осуществлять аутентификацию пользователей в момент загрузки по идентификаторам. Опять момент загрузки.
5. АПДМЗ по документации должны подключаться в разъем Reset на мат. плате компа. Много у серверов разъемов Reset?
6. АПМДЗ могут хранить ключи шифрования. Возможно это и будет удобно, но есть другие хранилища — токены, которые не хуже.
Недостатки:
1. Применение BMC, таких как ILO, IPMI с АПМДЗ неоднозначно.
2. Чистый АПМДЗ легко обойти, достаточно вынуть девайс из компа. Исключение составляют замки с шифраторами от АНКАД, но они настояльно дорогие, что мне ни разу не удалось убедить из купить.
Резюме. АПМДЗ создавались во времена DOS. Тогда их функционал нес практическую ценность. Сейчас нужны другие системы.BigW
26.07.2016 12:04Мне кажется надо просто отделить мух от котлет. АМДЗ для СКЗИ для гостайны — пусть все остается как есть (плохо это или хорошо, это отдельный вопрос и разговор). СКЗИ для конфиденциалки — оставить только программные реализации (по желанию оператор сам может наставить ПАКов каких и куда хочет, но не делать обязаловку из этого) и требования писать исходя из этого, Т.к.:
1. Методики оценки ущерба от разглашения КИ нет
2. моралка по суду максимум 5 тыс руб, т.к. очень сложно доказать иное…
3. штрафы откровенно смешные, и то если безопасник совсем безголовый. Если хоть что-то булькает, то все бумаги будут в порядке. На сколько они соответствуют жизни… Ну так я оператор, я так решил и модель угроз/нарушителя сам писал. вот сели мы вдвоем со сторожем и написали — он у нас эксперт ;))
4. Нет денег… одно рабочее место в органе власти со всей этой хренью обходится в ~ 60тыс рублей — Это пипец!!! Даллас лок+vipNet+соболь+Антивирь+ХанниПот +аттестация и это без железа!- это госы. На соболе можно сэкономить на текущий момент около 11 тыс — хоть что-то…
Ну и в качестве PS:
Токен это ПАК или нет? Ось есть, железо есть- вроде как ПАК :)))imbasoft
26.07.2016 13:05Токен в особенности с неизвлекаемым ключом — это ПАК. В Сертификате на JaCarta ГОСТ есть фараза:
"… Действие сертификата соответствия ФСБ России № СФ/111-2750 распространяется на совместное использование СКЗИ «Криптотокен» в составе электронных ключей JaCarta ГОСТ (eToken ГОСТ) и программных библиотек «Криптотокен ЭП», поставляемых в электронной форме… "
Peter-mad
25.07.2016 12:32Вот здесь галку уберите — http://ge.tt/6gtG6mc2
Статья называется «Извлечение ключа из токена с неизвлекаемым ключом», так вот делайте ключ неизвлекаемый, а потом тестируйте.imbasoft
25.07.2016 13:00+2Ждал этого комента :)
Давайте еще раз разберемся в чем разница между «не экспортируемым» ключом и «неизвлекаемым».
Например вы сгененрировали ключ и поставили галку что ключ неэкспортируемый. Что это значит? А значит это, то что средствами СКЗИ его скопировать не получиться. Но когда выполняется подпись документа, ключ с токена копируется в память ЭВМ, где обрабатывается криптопровайдером, Основной баг этой схемы в том, что ключ может быть похищен из ОЗУ.
Галочку что ключ «не экспортирумый» можно поставить и при генерации ключа на обычном токене, для этого необязательно покупть более дорогой токен с «неивзлекамым ключом».
Теперь рассмотрим неизвлекаемые ключи. В этой схеме ключи, хранящиеся на токенах никогда не подают в память ЭВМ все криптографические операции связанные с использованием ключа выполняются сугубо на токене. Таким образом ключ скоприровать невозможно.
В этом принципиальное отличие.
Суть статьи в том, что вы берете устройство — токен, заходите на сайт производителя, там везде токен с неизвлекаемым ключом это очень круто, безопасно и т.д. (с чем я согласен :)
Берете свое СКЗИ используете этот токен — СКЗИ работает, файлы подписываются, и у вас может сложится ложное мнение о том, что ваша схема — это схема с ФКН, но на самом деле нет.Peter-mad
25.07.2016 13:35-5Здравствуйте. Абсолютно согласен, что ключ может быть похищен из ОЗУ, но это немного другая история. Для этого нужно другое ПО, а не то описывают в статье.
imbasoft
25.07.2016 14:23Ну вот мы уже начинаем понимать друг друга :)
Цель статьи как раз и было показать, что то ПО которое обычно продает УЦ не позволяет достичь тех характеристик, которые работники УЦ заявляют при продаже.
eugzol
25.07.2016 15:07+3Т.е. я купил за 1000 рублей обычную флешку на 64кб. Спасибо, автор, открыл глаза :)
LPA77145
25.07.2016 15:14Я чего-то может не понимаю, но вы создаете ключи с отметкой «Пометить ключи как экспортируемые» (о чем свидетельствует установленная галка), потом копируете эти экспортируемые ключ в аппаратный токен. Далее производите удаление экспортируемых ключей из СКЗИ и обратно копируете экспортируемые ключи из аппаратного токена в реестр СКЗИ.
А возможно тоже самое проделать с ключом изначально созданным как «не экспортируемый», причем процесс извлечения ключей из аппартного токена произвести уже на другой тестовой машине?imbasoft
25.07.2016 15:42Ключ изначально созданный как «не экспортируемый» штатными средствами СКЗИ скопировать не получится. Но это не отменяет возможность применения других методов (см. комменты выше).
Только вот покупать токен, который позиционируется как токен с не извлекаемым ключом для этих целей (простановки галки «не экспортируемый» не нужно. Ровно тот же функционал вы получите не обычных токенах, которые стоят уверено дешевле.
Поясню. Вы взяли обычную флешку за 300 рублей, начали сгенерировали на ней ключ, поставили галку «не экспортируемый». Все, штатными средствами скопировать нельзя. Но не кто не отменял «Проводник Windows».
В случае токенов ситуация точно такая же.
Но если хочется чтоб ключ действительно нельзя было скопировать, то нужно использовать тот софт и те токены, что описаны в конце статьи, а не тот, что обычно втюхивают продавцы.LPA77145
25.07.2016 16:17С USB-flash накопители все понятно, это вообще то и не токены и конечен там можно и через файловый проводник все скопировать.
Тема вроде как звучит «Извлечение ключа из токена с неизвлекаемым ключом», стало быть и процесс тестирования должен начинаться с того, что ключи изначально создаются как «не экспортируемые» на токене, а не на HDD компьютера. А то, что из ОЗУ можно вытащить, так думаю от туда много чего при желании можно вытащить, только как это связано с темой поста про извлечение из токена?
В комментариях выше вы приводили различные примеры копирования в плоть до снятия ПЭМИН, но это же все отностится к перехвату данных. Хоть бы один вариант в тесте приведите, а так это голая теория! ;)
Да и не думаю, что из-за ключа стоимость от 2 до 5 тыс. руб., кто-то будет снимать электромагнитные наводки для выемки ключей из токена!!!msuhanov
25.07.2016 16:28Токены с неизвлекаемыми ключами позиционируются именно как защищенные от извлечения ключа вредоносной программой. Атаки на аппаратную часть (например, ПЭМИН) здесь на заднем плане. Но утечки через оперативную память тут в самый раз.
LPA77145
25.07.2016 16:34+1Тогда логичней в тесте показывать утечку ключей через оперативную память! Как считаете?
imbasoft
25.07.2016 17:19+1Да и не думаю, что из-за ключа стоимость от 2 до 5 тыс. руб., кто-то будет снимать электромагнитные наводки для выемки ключей из токена!!!
Я бы не был столь категоричен. Все завист от стоимости данных, которые защищены ключом. Например, если ключ от корр. счета Банка, на котором лежит несколько ярдов, то стоимость перехвата в данном случает будет зависит от стоимости приемника.
Широкополосник Rohde & Schwarz, который будет уметь такое стоил порядка 0,5 млн евров. Самопал на USRP существенно дешевле.LPA77145
25.07.2016 17:51А вы серьезно думайте, что компания с таким корр. счетом в Банке, будет сидеть в одноэтажном здании в помещении со стенами из картона и отсутствием как минимум СБ в структуре? И что злоумышленник пойдет с оборудованием подобного класса только для того, чтобы снять наводки с электронного ключа! Вы сами то в это верите?
Да и речь вообще не об этом, а о сути вашего поста «Извлечение ключа из токена с неизвлекаемым ключом». Просто содержимое не отражает сути названия темы. Лично мне как специалисту было бы намного интересно посмотреть на конкретные примеры извлечения подобных «не экспортируемых» ключей из токена, а не то, что вы описали механизм копирования в КрпитоПРО. Если для вас очевидный факт извлечение ключей из оперативки, интересно взглянуть как вы этого добьетесь и воспользуетесь извлеченными ключами на конкретных примерах. А пока по комментариям я вижу только размышления из разряда «фантазий» не относящиеся к сути вашей темы!imbasoft
26.07.2016 10:15А вы серьезно думайте, что компания с таким корр. счетом в Банке, будет сидеть в одноэтажном здании в помещении со стенами из картона и отсутствием как минимум СБ в структуре?
Видел такие организации :) Количество этажей роли не играет, равно как размещение СБ в здании. Поскольку знаю только одну организцию (гос. структура) в которой, в центральном офисе был развернут пост радиоконтроля.
И что злоумышленник пойдет с оборудованием подобного класса только для того, чтобы снять наводки с электронного ключа!
Злоумышлик пойдет не наводки снимать, а ключ извлекать, это немного другая постановка вопроса.
Вы сами то в это верите?
Тут сложнее.
Если мы говорим про практическую оценку актуальности угроз ПЭМИН, то я подхожу к этому со следующих позиций:
1. Извлечь ключ по ПЭМИН возможно.
— На расстоянии непосредственного контакта — условно до 10 метров (клиентская зона) устройства подобного класса будут стоит
менее 100 тыс. рублей.
— На дальних дистанциях (без зоны прямой видимости) — это прерогатива спец. служб или устойчивых преступных групп. Нужно дорогое оборудование.
2. Для реализации подобного класса угроз у злоумышлеников должна быть очень хорошая подготовка и знания.
3. Для защиты от ПЭМИН нужно реализовать целый комплекс мер, которые для обычной коммерческой организации практически не реализуемы:
— организация режима доступа в помещение.
— документирование и контроль трасс прохождения каналов связи и силовых линий и т. д.
Таким образом, ПЭМИН угроза не эфемерная
.
Спасает то, что специалистов по ней нет и стоимость взлома по ПЭМИН превышает стоимость взлома через классические каналы НСД. А факт, того что для защита от данного вида угроз необходимо реализовывать довольно дорогостоящий комплекс мер, переводит этот риск в разряд рисков с которым приходится жить.
Лично мне как специалисту было бы намного интересно посмотреть на конкретные примеры извлечения подобных «не экспортируемых» ключей из токена, а не то, что вы описали механизм копирования в КрпитоПРО
Это предмет отдельной статьи. В этой статье я хотел показать о типовом разводе, который можно проверить просто элементарными способами.LPA77145
26.07.2016 10:56То, что разводят на покупке ключей (да еще и предлагают никому ненужную техподдержку) это понятно.
Просто тест приведен неубедительный, рассчитанный на слабо разбирающегося (можно сказать вообще не разбирающегося) пользователя.
А то, что вы говорите про злоумышленника, который пойдет в организацию ключ извлекать из токена в это слабо верится (сам по себе ключ ничего не даст злоумышленнику).
Я думаю намного проще и эффективнее осуществить атаку с последующей возможностью удаленной эксплуатации того же ПК для отправки данных в Банк и пользоваться системой на свое усмотрение.
А если и произойдет утечка, то по глупости той организации, которая не соблюдала элементарные организационные и технические меры по обеспечению защиты ключей и того ПК, с которого осуществляются отправка данных в Банк.
Теперь осталось дождаться от вас статьи про утечку данных из токенов ;)BigW
26.07.2016 12:20ну на счет глупости я бы не был так категоричен. Приходите вы на собеседование или просто к секретарю типа курьер… отвлекаете бухгалтера. вешаете ему на клаву или рядом с компом стикер (как будто он под документ какой завалился, что типа бла бла приходил для техподдержки компа (обновления 1С и пр вас не было — перезвоните на мобильник)) 2 мин на все… Вам или сообщнику звонят — вы просите удаленку или просто приходите и делаете с компам что хотите- троян и прочее, а при наличии нормального шпионского ПО с реализациями 0-day уязвимостей вы полностью завладеете компьютером бухгалтера… а дальше — дело техники…
LPA77145
26.07.2016 12:51И часто вы проходите собеседование в кабинете бухгалтера с «операторской» машиной? :) Да и секретарь ну никак не будет сидеть с главным бухгалтером!!! Максимум куда вы дойдете это будет переговорная комната или ресепшен.
И как назвать по другому действия сотрудника, который по стикеру будет звонить на неизвестный мобильный телефон, как не глупость. Есть же здравый смысл или на крайней случай внутренняя телефония с почтой!!! :)))
Допустим даже если вам перезвонили по «утке» я не уверен, что вы сможете объяснить по телефону как включить удаленный доступ допустим того же teamviewer.
А вот если есть «неконтролируемый» удаленный доступ то, что это как не глупость организации в лице того же системного администратора или специалиста по ИБ?
И что вы понимаете под нормальным шпионским ПО с реализациями 0-day уязвимостью (вы сами то в руках такое ПО держали и использовали?). То, что вы описываете для начало попробуйте хотя бы у себя в организации осуществить, пусть даже с самописным трояном. ;)
Все, что вы приводите это в той или иной степени всего лишь отражение степени зрелости (компетенции) службы информационной безопасности в организации (или на крайней случай специалиста по ИБ)!!!BigW
26.07.2016 15:23— Ну по поводу бухгалтерии — это элементарно. Приходите в организацию, морда кирпичом и ломитесь в первую попавшуюся дверь (кроме приемной) тряся счетом на оплату услуг и вопросом где у вас бухгалтерия — в 90% случаев скажут. А дальше — чистая соц. инженерия, вломиться, взять бухгалтера за пуговичку, изобразить легкую стадию дибильности, отвлечь, оставить стикер… Да, есть шанс что не перезвонят, или перезвонят по внутреннему в техотдел. Но ведь могут и позвонить… Понятно, что этот сценарий больше применим к средним и мелким компаниям. Но у них вполне себе могут быть миллионные обороты…
— О, поверьте, s как доллар и тимвиевер — «как слышится так и пишется», «вбейте это в яндексе», «откройте интернет» это я ночью не проснувшись объясню самому деревянному пользователю, опыт есть, к сожалению… :)))) Лишь бы прав хватило на скачать и запустить…
— 0-day уязвимости сам лично не находил, но с троянами дело имел и писал и управление перехватывал, в академических целях еес-но, давно правда очень почти 10 лет уже…
— просто я хотел сказать, что даже при наличии крайне компетентных ИТ-спецов и безопасников, пресловутый человеческий фактор никто не отменял, но и головотяпства и откровенной лени, тоже, увы, более чем хватает…
mexobrlabs
25.07.2016 15:43-1токен был придуман с целью аппаратно ограничить подбор паролей к ключу (токену) — ограниченное количество попыток — и не решал задачи неизвлекаемости ключа. Неизвлекаемость ключа обеспечивается носителями типа ФКН и используемых как ФКН :), о чем и говорится в статье…
Saffron
25.07.2016 17:17+1Феерическая глупость. Если ключ можно извлечь, то его можно потом брутфорсить как хочешь
mexobrlabs
25.07.2016 17:39… это выглядит глупостью только сейчас, но история такова и решались другие задачи в первую очередь. Заполучив (украв) носитель типа «флешка» вы можете брутфорсить сколько угодно, если ключ запаролен. На токен (вы не знаете пин) — у вас не так много попыток.
Eklykti
25.07.2016 23:15Хитрый план:
- Покупаем токен, несколько раз переспрашиваем продавца под диктофон, что он точно неизвлекаемый.
- Записываем ключ.
- Извлекаем.
- Подаём заявление в суд на производителя за вводящую в заблуждение рекламу и в прокуратуру на орган сертификации, подписавший сертификат, что он таки неизвлекаемый.
- Ржом.
a513
26.07.2016 11:35Первое в чем абсолютно прав автор и о чем я говорю с начала 2000-х:
Аналогичная ситуация и с JaCarta ГОСТ. Более того, СКЗИ КриптоПРО CSP, по крайней мере та версия, которая использовалась в тестовом стенде, использует данные ключевые носители как «обычные токены», которые, в свою очередь, являются просто носителями ключа.
А теперь о неизвлекаемости закрытого ключа. Когда говорим о неизвлекаемом закрытом ключе — речь идет обустройствах со встроенным процессором, на котором выполняются криптографические операции. Такие устройства как правило имеют интерфейс PKCS#11. Примером такого токена может служить USB-ключи «MS_KEY K» компании «МультиСофт» (http://soft.lissi.ru/products/skzi/ms_key_k/ ). Здесь ключ нельзя извлечь по определению, а формирование подписи ведется на этом же токене: наруже виден только handle этого ключа.
Но что делают продавцы CSP с поддержкой ГОСТ! Они говорят, что для хранения используются те или иные токены/USB-ключи и т.п. Но при этом для генерации ключа, а соответственно и его хранения и использования, используют свою библиотеку, которая генерит ключ на компьютере, а затем с использованием интерфейса PKCS11 как объект кладется на токен. В этом случае токен может быть без поддержки ГОСТ-ов, вся поддержка в библиотеке CSP.
Хотя сегодня на рынке есть CSP, которые по-честному используют функционал ГОСТ-ых токенов.
И именно об этом надо спрашивать продавцаa1ien_n3t
26.07.2016 11:47+1Отличный сайт soft.lissi.ru который имеет жалобы на малавари и не открывается в браузерах.
Почитал оказывается они еще нарушают лицензию Mozilla.
bamovetz
26.07.2016 17:12Не нравится этот сайт — вот вам другой (http://multisoft.ru/katalog/zawita-informacii/skzi-mskey-k/mskey-k-isp5hx/).
Это сайт производителя.
DemT
26.07.2016 11:40Если сгенерировать ключи не КриптоАрм'ом, а через API разработчика, используя внутренний криптопровайдер токена, то через КриптоПро/VipNet контейнеры так просто уже не скопировать (КриптоПро их даже не увидит). Для работы с такой ЭП нужно использовать адаптированное под данный носитель ПО (например такие ЭП работает в ЕГАИС от ФСРАР после установки специального плагина для браузера). Что касается того, что УЦ не всегда используют встроенные в носитель средства, то это последствия необходимости обеспечения совместимости с теми системами в которых хочет работать пользователь.
so1aris
26.07.2016 17:12Т.е. решить проблему дохнущих джакарт и последующей беготни за новыми ключами+сертификатами не выйдет?
DemT
27.07.2016 09:02Если Вы про джакарты SE, то там печаль. От разработчика было письмо, что при высоких нагрузках носитель дохнет(точнее блочится). aladdin-rd.ru/company/info_message
so1aris
27.07.2016 12:15Ну да, я про то и говорю. И далее приходится бежать не только за новым носителем, но и платить УЦ за новые ключи и сертификат. А можно было бы сделать копию этого хозяйства — обходились бы только новым носителем, к тому же их пока по гарантии меняют
AlexBT
27.07.2016 13:49Токен то не дохнет. Он выключается. Не держите его в порту на постоянку. И трясите произоводителя софта, на котором Джакарта отстреливается.
А если учесть, что Джакарта и сертификат на нее приобретается в одном месте, то и сертификат должны выпустить по гарантии до конца срока его действия, если уж Джакарта больная попалась.so1aris
27.07.2016 14:18Ну они рекомендуют другую криптобиблиотеку использовать, юзеры вроде пишут, с ней постабильней работает. Но и много ключей нерабочих — некоторые пишут о накоплении уже по десятку ключей на замену. А вот о бесплатной выдаче новых ключей/сертификатов никто не пишет, только о том, что за это денег приходится платить :)
AlexBT
27.07.2016 14:32А что значит другую криптобиблиотеку использовать? Из под винды на Люникс уйти? Эта Джакарта специально для ЕГАИС выпускалась и должна работать с тем комплектом ПО, который для нее написан. Она же не зря PKI/ГОСТ/SE называется. Для нее специальное условие неуменьшаемый счетчик ЭП, выполненных на этом токене и включение номера апплета и содержания счетчика в состав ЭП подписываемого документа. Может сейчас уже что и появилось от сторонних производителей, но первоначально там все исключительно свое, егаисовское было.
so1aris
27.07.2016 14:41Ну, буквально это и значит — заменить jctranscrypt.dll на libtranscrypt.dll. Без замены ОС ))
merlin-vrn
27.07.2016 12:37Почему оно блочится под виндой, но не под линуксом? Софт под виндой некорректно работает с ключиком?
AlexBT
27.07.2016 13:44Скорее всего да. И причина может быть в опросах носителя софтом. Например, программа проверяет — воткнут носитель или нет в порт. Джакарта насчитала, например, тысячу опросов и отключилась. Выдернули из порта, воткнули по новой — Джакарта опять тысячу опросов насчитала и выключилась по новой. Но такое поведение не для всех токенов справедливо. Это какая-то партия себя так ведет. Потому что на десяток штук всего одна такая хитрая попалась. При чем, если программа не запущена, то эта Джакарта может жить сутками не выключаясь. Запустили программу — и начались отключения.
Beast2040
26.07.2016 12:52-2ТС пометил ключи как экспортируемые (в пункте 1), а потом удивляется почему ему удалось их скопировать на другой носитель. Если эту галку не ставить, то и скопировать средствами СКЗИ ничего не удастся, даже если генерить на обычную флешку. Такие ключи (не экспортируемые), хоть и можно потом скопировать с флешки вручную, все равно их использовать на другом носителе не получится (без бубна).
Rigmar
26.07.2016 17:49Много страшных слов. А то что действительно важно, то есть закрытый RSA ключ на котором и генерятся сертификаты, по прежнему в безопасности.
AlexBT
27.07.2016 10:10Автор немного перепутал две задачи:
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
Пробный период — две недели без денег.
Выпустить можно в самой программе самоподписанные сертификаты под ГОСТ, без обращения в УЦ, с записью ключевых документов и сертификата на вышеуказанные Токены. Документация с описанием как сделать есть.
И после этого попытаться вытащить сформированный закрытый ключ.
На любой из операций — при любом взаимодействии с Токеном.
О результатах отписаться.
Сразу скажу, что производители перечисленных токенов утверждают, что закрытые ключи, сформированные средствами токенов не извлекаются ни при каких обстоятельствах.
imbasoft
27.07.2016 10:13Автор немного перепутал две задачи:
1. использовать Токен как флешку для хранения файлов с ключевой информацией и сертификата открытого ключа;
2. использовать Токен как смарткарту для формирования неизвлекаемого закрытого ключа.
Автор не путал :), он хотел как раз это и объяснить. Путают продавцы.AlexBT
27.07.2016 10:59Да ладно, чего хотеть от девочки, продавца бакалейных товаров?
Она же продает товар артикул номер, не зная вкуса, и отличает продаваемое только по цвету упаковочного конверта…
Т.е. — она явно не специалист с высшим образованием в области информационной безопасности. Просто симпатичная!
Шучу.
А в целом предложение попробовать вышеописанный комплект и отписаться о результатах остается в силе.
Потому что у Крипто АРМа свой подход к работе с Токенами.
Он тоже может использовать их как флешку для контейнеров, а может и как СКЗИ с не извлекаемым ключом.
С Эникриптером ситуация однозначна — если РуТокен, ДжаКарта или Смарт-Парк (ФОРОС или Магистра) — то только неизвлекаемый закрытый ключ (полная спецификация изготовителя СКЗИ), Если Крипто ПРО или Вип-НЕТ, то софтверные контейнера с записью на диск.
Дальше средствами Крипто ПРО или Вип-НЕТа можно гонять как бог на душу положит, но это будет операция копирования файлов с одного носителя на другие. С соответствующими проблемами сохранения закрытого ключа в неприкосновенности.
bamovetz
27.07.2016 11:02Главная недоговоренность у автора статьи в том что речь ведется о работе с токеном через Крипто Про CSP.
Кто не знает — Крипто Про хранит ключи и сертификаты на токене в отдельной папке и в обычных бинарных файлах. В результате токен обеспечивает только авторизацию для доступа к данным файлам. Так что все вопросы к Крипто-Про.
Если работать с сертификатами через pkcs11 или через CSP от производителя токена (не у всех есть), в крайнем случае через APDU команды напрямую то закрытые ключи генерятся на токене и извлечь их нельзя.
Так же автор почему то не упоминает что есть и токены реализующие ГОСТ алгоритмы нативно а не через Java-апплет. Например указанный выше MS-KEY K. Там вообще нет Java-машины и скорость повыше.AlexBT
27.07.2016 14:19Крипто ПРО тоже разные бывают. Есть такой комплект, который называется Крипто ПРО еТокен ГОСТ вер. 3.9.
Так он работает с Джакартой через PKCS#11, в результате генерится неизвлекаемый из памяти еТокена закрытый ключ. То есть так как и положено для работы со смарт-картой с крипто процессором на борту. Там, правда, тоже свои заморочки с форматами упаковки Крипто ПРО. А именно сертификат укладывается на Джакарту как бинарный объект, и простой Гость его как сертификат не видит. Это специально для того, что бы халявы не было, для Крипто ПРО онли…
ITMatika
Другими словами, практически любой ключ (сертификат?) можно извлечь из практически любого ходового носителя ЭЦП и скопировать, даже если стоит галка, что ключ неизвлекаемый?
imbasoft
Скопировать ключи можно не с любых токенов, но довольно с многих.
Галкой «неизвлекамый» — вы наварено называете «не экспортируемый». Стоит отметить, что наличие данной галки — обрабатывается только СКЗИ. А это значит, что если ключевая информация доступна в обход СКЗИ (например, ключ хранятся на флешке или в реестре), то она может быть успешно скопирована не смотря на галку.
Таким образом, ответить на ваш вопрос о возможности копирования ключей, для которых стоит галка «не экспортируемый» можно следующим образом:
— Если к ключевой информации можно обратится в обход СКЗИ, то не смотря на эту галку их скопировать можно.
Применительно к токенам обходные маневры расписаны в статье
Akr0n
И все-таки, не понял. Вот есть Рутокен, закрытый ключ помечен как не экспортируемый, сгенерирован на ОС, где поддержки КриптоПро ФНК нет, только дефолтные драйвера Рутокен. Ни в реестре, ни на какой-либо флэшке он не хранится, только на токене. Его можно извлечь или нет?
imbasoft
Штатными средствами СКЗИ нет.
Akr0n
Ну, это понятно :)
А самописным средством, получается, можно? В момент шифрования из памяти?
imbasoft
Самописными можно если есть доступ к ключу в обход СКЗИ.
например, ваше ПО может работать с токеном напрямую и у вас есть от токена пароль.
Saffron
Только если он ГОСТовый. За бугром такой фигни нет — там понимают, чем электронный ключ отличается от флешки. А у нас поторопились импортозаместить.
imbasoft
Вступлюсь за наших разработчиков.
Игра с «экспортируемым» и «не экспортируемым» ключом справедлива практически для любых криптопровайдеров, что наших, что импортных. Можете ее легко повторить на чистой Windows.
Токены не являются чисто российским изобретением и применяются в том числе и за бугром. Более того и наши и импортные токены реализуют один стандарт — ISO/IEC 7816 + вариации, поэтому утверждать что наши токены хуже, не совсем корректно.
BigW
Сам я не проверял (нет технической возможности), но слышал что на у них там как раз экспортировать RSA ключ нельзя (если галка есть) что штатными кириптосредствами что чем-нибудь сапописным именно из-за железной поддержки этого алгоритма чипом.