22.03.2005 7:08:08Хранение ключей на eToken Ответов: 37
Гена
В eToken Pro есть возможность сгенерировать и использовать ключи на самом eToken, т.е. ключ никаким образом не может быть считан. Скажите пожалуйста при использовании eToken в качестве хранилища ключей эта возможность пропадает или остается? Т.е. гарантируется защита от считывания секретного ключа пользователем, который имеет доступ (пользуется) к этому ключу.
 
Ответы:
22.03.2005 10:37:05Василий
Смотря что понимать под словом "гарантируется". При хранении ключа на токене пользователю не предоставляется (в составе продуктов: "КриптоПро CSP", "eToken RTE", "eToken Utilites", "eToken для КриптоПро CSP") других средств доступа к контейнеру, кроме использования функций CSP, разумеется, при условии правильного ввода ПИН-кода.
22.03.2005 11:14:17Гена
Под словом "гарантируется" понимается, что зная ПИН код пользователь не может скопировать секретный ключ куда-нибудь себе и вдальнейшем использовать. Т.е. не может его украсть.
22.03.2005 11:24:55Василий
Разумеется, зная ПИН, злоумышленник получает полный доступ к содержимому eTokena (и к контейнеру, для любого CSP, на котором контейнер сделан). При этом, если при создании контейнера был выставлен флажок, разрешающий экспорт ключей, то злоумышленник сможет скопировать этот контейнер (опять же, для любого CSP). Если этот флажок не выставлен - контейнер нельзя копировать средствами, предоставляемыми тем ПО, что я перечислил.
23.03.2005 11:25:47Roman
Если это правда, то eToken-у место на помойке.

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

Можно лишь сгенерить ключ в устройсте, и некоторые устройства позволяют импортировать ключи извне.
23.03.2005 12:21:39Гена
Если использовать средства eToken, то секретный ключ не покидает предела eToken. А если использывать КриптоПро, то получается есть возможность его скопировать. Да мрачно :(
23.03.2005 13:08:26Василий
Спорим, что можно секретный ключ, созданный на стандартном eToken CSP, экспортировать во внешний файл при тех условиях, что были описаны (флажок, разрешающий экспорт и знание ПИНа).
Что Вы так привязались к КриптоПро CSP - поведение абсолютно одинаковое, повторюсь, для любого CSP, хранящего ключи на токене.
Хотите безопасности - не надо раздавать свои етокены (вместе с ПИН-кодами) - это вроде совсем не сложно.
23.03.2005 13:22:13Roman
2 Василий:
Именно так я и сказал: на помойке место eToken-у, а не КриптоПро :)

> Хотите безопасности - не надо раздавать свои етокены (вместе с ПИН-кодами) - это вроде совсем не сложно.

Это в корне неверно. _Единственный_ смысл существования подобных устройств (токенов, смарт-карт и т.п.) - что пользователь не рискует кражей секретного ключа при использовании устройства в неконтролируемой им среде.
23.03.2005 14:57:16Василий
Логично, но ПИН-код - вещь всё же довольно секретная. С ходу предполагать, что он известен окружающим, наверное, не стоит.
Кроме того, если на контейнере нет флажка, разрешающего экспорт, то злоумышленник не сможет его скопировать, о чём я уже писал.
23.03.2005 15:33:05Roman
> Логично, но ПИН-код - вещь всё же довольно секретная. С ходу предполагать, что он известен окружающим, наверное, не стоит.

???

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

> Кроме того, если на контейнере нет флажка, разрешающего экспорт, то злоумышленник не сможет его скопировать

А КриптоПро выставляет этот флаг?
23.03.2005 17:11:56Василий
Если злоумышленник имеет как етокен, так и ПИН-код, зачем ему вообще заморачиваться с копированием ключей - можно и так прекрасно его использовать :)

Кроме того, ПИН-код - не мировая константа, пользователь может менять его хоть каждый день.

Флаг выставляет приложение, которое генерит контейнер. CSP может быть при этом любым.
Например, при создании запроса на сертификат через веб-интерфейс MS CA, пользователь имеет возможность либо ставить этот флаг, либо не ставить.
23.03.2005 21:35:01Roman
> Если злоумышленник имеет как етокен, так и ПИН-код, зачем ему вообще заморачиваться с копированием ключей - можно и так прекрасно его использовать :)

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

> Флаг выставляет приложение, которое генерит контейнер.

Т.о. приложение, создающее ключ, отвечает за его сохранность. Видимо, это и есть ответ на заданный в теме вопрос.

Кстати, насколько я понимаю, этот флаг может быть нужен только для отладки, поэтому CSP мог бы "прятать" его от обычного пользователя.
24.03.2005 8:03:41Гена
Вот как получается КриптоПро на программном уровне использует ключевые контейнеры, но возможно использовать на аппаратном (долго шифрует, но можно шифровать контейнер). И еще я создал неэкспортируемый секретный ключ при помощи КриптоПро на eToken. Да програмно я его не могу экспортировать, но при помощи eToken Editor я скопировал весь ключевой контейнер себе на диск. Остается верить что он как нибудь защищен привяской к уникальному номеру eToken. А то обидно будет что если я его скопирую на другой eToken у меня все заработает.
24.03.2005 10:20:11Василий
По поводу eToken Editor - Вы правы, скопировать контейнер им на другой токен можно. Привязка к сер. номеру токена есть, но, только на той машине, где использовался оригинальный контейнер. Поэтому на другой машине (и даже на той же, если удалить привязку и переустановить сертификат) контейнер будет работать.

Но, эта утилита - eToken Editor - не распространяется свободно.

Вообще, какой-то странный спор у нас тут. Если предполагается, что злоумышленник имеет доступ как к самому токену, так и к ПИН-коду, о какой безопасности вообще можно говорить??? Сама эта ситуация называется "компрометация ключа", и, по всем правилам, сертификат должен быть немедленно отозван, и использовать его (и соответствующий ему контейнер) больше нельзя!
Если не хватает технических мер по обеспечению безопасности (дополнительно можно указать: блокирование компьютера при отсутствии пользователя, ограничение доступа к компьютеру по сети) - надо использовать организационные (например, ограничение доступа в помещение с компьютером; хранение токена, когда он не используется, в сейфе).
24.03.2005 11:12:06Гена
Что касается спора, то представте такую ситуацию:
Человек когда работал на предприятии имел доступ к зашифрованной информации по ключу eToken. И зная, например, что через неделю увольняется копирует себе этот секретный ключ для дальнейшего использования. Что делать? Можно после увольнения отзывать сертификат и все данные перешифровывать, а можно исключить такую ситуацию. Например, использывать eToken, где есть возможность создать на ключе аппаратними (через CryptoAPI криптопровайдера) средствами, в таком случае нам доступен только открытый ключ и возможность использывание аппаратных функций шифрования. Конечно я не спорю что есть возможность в таком случае вычислить зыкрытый ключь, но это не вопрос копирования.
24.03.2005 12:13:23Roman
2 Василий:
> Если предполагается, что злоумышленник имеет доступ как к самому токену, так и к ПИН-коду, о какой безопасности вообще можно говорить?

Повторюсь: у злоумышленника нет постоянного доступа к токену, но может быть временный доступ, например, при использовании токена в контролируемой злоумышленником среде. Задача токена - не допустить кражи секретного ключа (PIN украсть легко), иначе злоумышленник получит возможность аутентифицироваться, как владелец токена, _без_ токена.

Рекомендация использовать токен только в полностью контролируемой владельцем среде бессмыслена, т.к. в этом случае токен не нужен, можно дискетой или флешкой обойтись.
24.03.2005 12:34:22Roman
2 Гена:
> Можно после увольнения отзывать сертификат и все данные перешифровывать

Зачем перешифровывать данные? Отзыв сертификата и помещение его в CRL. Правда, это уже OT.

> [...] есть возможность в таком случае вычислить закрытый ключ

Это шутка?

Что касается основной темы, я думаю, Василий всё-таки ошибается, иначе бы eToken не сертифицировали.

Из описания eToken http://www.aladdin.ru/ufiles/28_3product_PDF.PDF:

"Закрытые ключи, сгенерированные eToken или импортированные в него, хранятся в закрытой памяти смарт-карты и не могут быть из неё извлечены.

Это подтверждается международными сертификатами безопасности ITSEC Level E4, FIPS 140-1 -- Level 2, 3."

Думаю, что извлечение закрытых ключей исключено не только при использовании типового программного обеспечения, а вообще.
24.03.2005 13:40:39Гена
2 Roman: Меня на эти мысли вот эта статья навела
http://www.cryptology.ru/pages/canmeth/04.01.05.rsaattack.html

А что касается отзыва сертификата, то это только "флашок" что ключ неиспользывать, а нужно его использывать для шифрования. Если бы дело ограничивалось только ЭЦП...
24.03.2005 14:46:49Сергей Муругов
Уважаемые господа.
eToken чисто зарубежное изделие и понятие неизвлекаемости закрытого ключа относится только к RSA. Что касаемо отечественной криптографии, то если очень на пальцах, закрытый ключ для токена – это объект атрибутом которого в частности является криптоалгоритм, до тех пор пока токен не будет знать про ГОСТ, то он может использоваться исключительно в качестве дискеты с пин-кодом и не более. И разработчики из КриптоПРО тут совершенно не причем!!! Такова железка.

24.03.2005 15:03:31Roman
> http://www.cryptology.ru/pages/canmeth/04.01.05.rsaattack.html

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

> А что касается отзыва сертификата, то это только "флашок" что ключ неиспользывать, а нужно его использывать для шифрования. Если бы дело ограничивалось только ЭЦП...

Если бывший хозяин токена имел доступ к шифруемым данным (а без этого их нельзя было бы зашифровать), то что мешает ему скопировать сами данные, вместо копирования ключа из токена?
24.03.2005 15:13:32Roman
2 Сергей Муругов:
ГОСТ-овские алгоритмы не патентованы, поэтому зарубежные производители вполне могут их релизовать в своих изделиях (хотя в eToken, похоже, этого действительно нет).

С другой стороны, RSA не запрещён к использованию в РФ, и, по-моему, поддерживается КриптоПро CSP. Разве нет?
24.03.2005 15:26:17maxdm
RSA КриптоПро CSP не поддерживается.
24.03.2005 15:28:49Василий
Эксперимент показывает, что закрытый ключ из контейнера, сделанного при помощи eToken base CSP, нельзя скопировать с eTtokena PRO средствами экспорта сертификата (с ключом) в файл. По-видимому, при генерации ключей просто принудительно сбрасывается флажок, разрешающий экспорт ключей (даже если его ставить).
Для КриптоПро CSP ещё проще - у нас просто не поддерживается экспорт секретного ключа в файл для любого носителя.
Для eToken R2 и eToken base CSP - это действие возможно.

Остаётся копирование контейнеров.
Для eToken PRO нельзя скопировать контейнер ключа, сделанный на eToken base CSP - просто нет средств для этого (в составе перечисленного в ходе дискуссии ПО).
Можно копировать контейнер, сделанный КриптоПро CSP средствами КриптоПро CSP (если был установлен флажок, разрешающий экспорт).
24.03.2005 15:29:59Муругов Сергей
RSA конечно КриптоПРО не поддерживается :-) Для RSA есть целый спектр других CSP. Еще раз если не понятно я ранее написал, пока не будет токена имеющего на борту ГОСТ - токен это фактически дискета.
24.03.2005 15:50:49Гена
Есть токен с российским алгоритмом - это ruToken. Но только он аппаратно подерживает алгоритм симметричного шифрования ГОСТ-28147-89. Задав вопрос а планируется и когда реализация других алгоритмов мне был дан такой ответ:
"... На данный момент аппаратная реализация асимметричного гостовского алгоритма шифрования затруднена отсутствием соответствующего серийного чипа, а разработка собственного чипа пока, к сожалению, нерентабельна. ..."
24.03.2005 16:11:39Roman
2 Василий:
> просто нет средств для этого (в составе перечисленного в ходе дискуссии ПО).

Помилуйте, неужели Вы думаете, что злоумышленник не разберётся, как ползоваться APDU в обход CSP :)
24.03.2005 16:16:00Roman
2 Муругов Сергей:
> RSA конечно КриптоПРО не поддерживается :-)

Упс...

> пока не будет токена имеющего на борту ГОСТ - токен это фактически дискета.

Это если пытаться его использовать с КриптоПро CSP. Что в связи с вышесказанным представляется бессмысленным.
24.03.2005 17:21:12Муругов Сергей
У нас, говорю от имени Нового Адама, тоже есть продукты для PKI и мы тоже используем токены и eToken и ruToken в частности, и размещаем там ключевые контейнеры и мы находимся точно в таком же положении как и КриптоПРО. Еще раз говорю, разработчики КриптоПРО НЕ ПРИ ЧЕМ, они могли сделать только то, что может железка. И такая ситуация у всех разработчиков продукты которых, хранят чуждые для буржуйского изделия ГОСТовые контейнеры.
24.03.2005 20:40:11Roman
> разработчики КриптоПРО НЕ ПРИ ЧЕМ, они могли сделать только то, что может железка.

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

Согласитесь, не совсем нормально, что КриптоПро рекомендует к использованию eToken, а Aladdin - КриптоПро, при этом пользователь может узнать о том, что eToken в комбинации с ГОСТ-ориентированными криптопродуктами ничем не лучше обычной флешки, лишь внимательно изучив список поддерживаемых алгоритмов или случайно наткнувшись на Ваш пост в форуме.
25.03.2005 9:26:38Муругов Сергей
Уважаемый …. Вы совершенно не правы. Защита – это всегда комплекс оргтехмероприятий. И разработчики совершенно правы, что не только доносят до вас современные решения, но и настоятельно их рекомендуют к использованию, например, тот же eToken – это не только контейнер ключей, но и средство которое может участвовать в авторизации пользователя, почитайте на том же Aladdin для токена есть и сертификат Гостехкомиссии, наверное все это не спроста; это не просто дискета, а защищенный отчуждаемый носитель. А вот когда такие носители смогут внутри себя создавать не извлекаемые ключевые пары для ГОСТ будет еще лучше. И еще раз вас никто не вводил в заблуждение – вам рекомендуют наиболее защищенное решение при настоящем развитии технологии.
25.03.2005 10:30:06Василий
>> просто нет средств для этого (в составе перечисленного в ходе дискуссии ПО).
>
Помилуйте, неужели Вы думаете, что злоумышленник не разберётся, как ползоваться APDU в обход CSP :)
<

не могу не оставить без комментариев.
Приведите, плиз, пример схемы похищения ключа в этом случае (естественно, с удалённого компьютера) - как коннектиться, что запускать и т.п. Отсюда сразу будут видны меры по защите.

А если злоумышленник имеет сам етокен, то это, повторяю, называется "компрометация ключа".
25.03.2005 12:20:18Roman
2 Муругов Сергей:
> тот же eToken – это не только контейнер ключей, но и средство которое может участвовать в авторизации пользователя

Участвовать в авторизации пользователя он может только посредством ключей, в нём записанных.

> это не просто дискета, а защищенный отчуждаемый носитель

А это не Вы писали (не один раз):

> пока не будет токена имеющего на борту ГОСТ - токен это фактически дискета.

Насколько я понял, ГОСТ-ориентированные CSP для работы просто копируют закрытый ключ с токена, передавая ему введённый ползователем PIN. Это ничуть не защищённее, чем просто хранить ключ в запароленном PEM или DER файле.
25.03.2005 12:36:40Roman
2 Василий:
> Приведите, плиз, пример схемы похищения ключа в этом случае (естественно, с удалённого компьютера) - как коннектиться, что запускать и т.п.

Технологии захвата контроля за средой, в которой используется токен, выходят за рамки темы. Моё утверждение состоит в том, что, если такой захват исключён, то ключи можно хранить и в открытом виде. Если же недружественный контроль возможен, то хранение ключей на несовместимом по алгоритмам токене не даёт никаких преимуществ по сравнению с зашифрованным на пароле файлом, шифрованной файловой системой и т.п. - что стОит намного дешевле токена.
25.03.2005 12:38:46Муругов Сергей
Вы напрасно из контекста вырываете фразы, про дискету было писано в том смысле, что само устройство не предоставляет специальных средств защиты закрытого ключа для ГОСТовых алгоритмов. Что касается аналогии с файлом, то и тут вы не правы, чтобы удаленно извлечь из токена данные надо очень сильно постараться и скорее всего с отрицательным результатом. Вариант по физическому доступу к токену, как верно ранее было замечено, не рассматривается – это самая настоящая компрометация ключа. А использование токена значительно сужает перечень применимых атак на контейнер и вообще на рабочее место и именно поэтому и рекомендуется разработчиками.
25.03.2005 12:59:42Roman
Объясните, пожалуйста: если злоумышленник захватил контроль над компьютером и смог украсть пароль (PIN), то какая разница, использовать этот пароль для извлечения ключа из зашифрованного файла или из токена, когда тот подключён?
25.03.2005 15:11:08Roman
Что касается компрометации ключа, то в этом как раз весь смысл токенов и смарт-карт: для компрометации злоумышленнику нужно украсть сам токен.

В обсуждаемом же случае ключ может быть скомпрометирован (== украден для дальнейшего использования без санкции владельца) при _однократном_ физическом доступе к токену, когда владелец подключит его в недружественной среде.
28.03.2005 7:37:39Гена
Что касается как украсть ключ с токена (мы имеем полный доступ на удаленном компьютере, а эти вопросы здесь не обсуждаются): Для кражи ПИН-кода можно использывать клавиатурного шпиона + троян. После чего для кражи секретного ключа используется "своя" программа, которая написанна с использыванием eToken Development Kit на низком уровне (APDU функции). Это позволит слить файлы созданые КриптоПро.
28.03.2005 7:56:06Гена
Да повторил идею Романа.
У меня возникла идея, а что если для ЭЦП использывать двойную подпись? Т.е. на одном eToken будут находиться два секретных ключа, один из которых аппаратно защищен от копирования, а другой предназначен для шифрования российскими алгоритмами.