Автор: ALEXey | 18172	17.03.2010 16:22
В чем разница между этими двумя устройствами? По просторам интернета поискал, ничего внятного не нашел. Возникла необходимость приобрести данные устройства для хранения ключей, в принципе для поставленной задачи будут приобретаться ruTokenы. Но про различия хотелось бы узнать больше.

Автор: Прохожий | 18180

17.03.2010 17:59

Rutoken разработан компаниями «Актив» и «Анкад» с учетом современных требований к устройствам защиты информации. Главным отличием Rutoken от зарубежных аналогов является аппаратно реализованный российский стандарт шифрования - ГОСТ 28147-89. eToken - персональное средство строгой аутентификации и хранения данных, аппаратно поддерживающее работу с цифровыми сертификатами и ЭЦП. eToken выпускается в двух форм-факторах: USB-ключа и смарт-карты. eToken поддерживает работу и интегрируется со всеми основными системами и приложениями, использующими технологии смарт-карт или PKI (Public Key Infrastructure). eToken может выступать в качестве единой корпоративной карты, служащей для визуальной идентификации сотрудника, для доступа в помещения, для входа в компьютер, в сеть, для доступа к защищенным данным, для защиты электронных документов (ЭЦП, шифрование), для установления защищенных соединений (VPN, SSL), для проведения финансовых транзакций. http://www.aladdin.ru/catalog/etoken/ рутокен это (негостированное понятие-скорее коммерческий лейбл) - разновидность е-токена для унутреннего потребления

Автор: malotavr | 18187

17.03.2010 18:47

> В чем разница между этими двумя устройствами? В способе выполнения криптографических операций по ГОСТ 34.10. В этом случае eToken является криптографическим контейнером: он отдает ключ наружу - криптоядру операционной системы, которая выполняет криптографичесикие операци в защищенном сегменте памяти операционной системы. RuToken выступает в роли криптопроцесора, выполняя такую операцию самостоятельно. Поэтому закрытый ключ RuToken не покидает.

Автор: Прохожий | 18188	17.03.2010 18:59
Спасибо за дополнение Mалотавр! Попутно благодарю за скан нетленки (Вы были правы Хрень и другому анализу не поддается и трогать больного автора не стоит - а вдруг он заразен неизвестной формой маразма?) Вы другой формой изложили мою более пространную мысль но ваши две последние строки - по сути квинтэссенция

Автор: раз-раз | 18210

18.03.2010 10:27

>> В этом случае eToken является криптографическим контейнером: он отдает ключ наружу - криптоядру операционной системы, которая выполняет криптографичесикие операци в защищенном сегменте памяти операционной системы. >> RuToken выступает в роли криптопроцесора, выполняя такую операцию самостоятельно. Поэтому закрытый ключ RuToken не покидает. А не наоборот ли? Если мне не изменяет память, именно в еТокене есть криптопроцессор и это еТокен не отдает ключи наружу, за счет чего он и дороже руТокена, в котором криптопроцессора нет.

Автор: раз-раз | 18211

18.03.2010 10:36

Из документации к еТокену: - Аппаратное выполнение криптографических операций в доверенной среде (в микросхеме ключа: генерация ключей шифрования, симметричное и асимметричное шифрование, вычисление хэш-функции, выработка ЭЦП). щих коммуникацию с компьютером и выполняющих функцию карт-ридера. Из описания: Криптография реализована в чипе смарт-карты, закрытые ключи никогда не покидают чип, что обеспечивает высочайшую защищенность этих устройств. Технология запатентована Аладдином. А вот про руТокены: - ruToken построен на базе серийного микроконтроллера, в котором аппаратно реализован только российский симметричный ГОСТ 28147-89, аппаратной поддержки западных алгоритмов нет – при их вызове осуществляется «проброс» к стандартному криптопровайдеру. Ключ в этом случае выполняет функцию «защищенной PIN кодом флэшпамяти» для хранения ключевых контейнеров.

Автор: раз-раз | 18214	18.03.2010 10:47
>> В способе выполнения криптографических операций по ГОСТ 34.10. Прошу прощения. Слона-то я и не заметил :) Действительно, в случае использования российской криптографии еТокен может использоваться как защищенный носитель для ключевых контейнеров, аппаратной поддержки наших алгоритмов в нем не реализовано.

Автор: sc63 | 18244	18.03.2010 15:35
.....eToken может выступать в качестве единой корпоративной карты, служащей для визуальной идентификации сотрудника, для доступа в помещения, для входа в компьютер.... Есть модификации Рутокена с RFID метками, выполняют те-же функции

Автор: ALEXey | 18523	26.03.2010 09:28
Итого: Если используется "заморское" шифрование (например, ключи на Microsoft CA), то лучше eToken, если же отечественный производитель ГОСТ 34.10 - то ruToken. Я правильно понял?

Автор: malotavr | 18547

26.03.2010 12:56

Не совсем. Если честно, то принципиальной разницы между ними нет. Для нарушителя низкой квалификации они одинаковы, поскольку перехватить ключ, отдаваемый eToken'ом он не сумеет. Дяля реверсера с высокой квалификацией "неотдача" ключа - не помеха. Ему не нужен ключ - он перехватит ПИН к носителю и от имени пользователя даст ключу команду на выполнение криптографической операции. Так что все отличие между этими ключевыми носителями - "голимый пиар".

Автор: Светлана | 18584

26.03.2010 23:18

malotavr, опишите, пожалуйста, подробнее атаку с командой от имени пользователя. На примере любой какой-нибудь операции, только от начала до конца, если можно - с задачи злоумышленника до ее успешной реализации. Мне кажется, несколько теоретическое построение. ПС: Обратите внимание, пожалуйста, что аппаратно шифровать рутокеном можно только ОЧЕНЬ неторопливо. Когда речь идет о приличной скорости - это программная реализация (известны же возможности того процессора, на котором он построен). Поэтому плюсы от этой аппаратности не стоит преувеличивать (это на всякий случай так, что я не то чтобы рутокен отстаиваю своим вопросом )) ). К вопросу ALEXey - если устройства Вы приобретаете для ХРАНЕНИЯ ключей, то речь наверняка идет о ключах подписи, значит, аппаратный ГОСТ 28147-89 для Вас погоды не делает. С точки зрения хранения ключей подписи разницы нет, но рутокен - дешевле. Если же речь идет о генерации ключей и непосредственных криптографических вычислениях, то имеет смысл рассматривать другие альтернативы. В частности, ПСКЗИ ШИПКА. В ней и российские, и импортные алгоритмы аппаратно реализованы.

Автор: malotavr | 18588

27.03.2010 13:22

> На примере любой какой-нибудь операции, только от начала до конца, если можно - с задачи злоумышленника до ее успешной реализации. Издеваетесь? :) Это стандартная техника, который используется при фишинге. Злоумышленнику требуется решить три задачи: 1. Получить доступ к рабочему месту пользователя 2. Поднять себе привилегии до локального администратора, LOCAL_SYSTEM или до получения системной привилегии SE_DEBUG 3. Перехватить PIN 4. Выполнить криптографическую операцию (единственое новгшество, которое требуется нарушителю) Решение 1. Стандартная атака на рабочее место. Методов - десятки, от спамовой рассылки до адресной атаки с элементами социальной инженерии. Результат атаки - пользователь идет браузером по указанной нарушителем ссылке, открывает Flash-ролик, вордовый или PDF документ, RARовски архив - и в его сессии отрабатывает эксплойт. Уязвимость - непропатченный клиентский софт, который не патчится в 100% организаций. Результат - на рабочем месте пользователя работает троян с reverse shell до сервера нарушителя. 2. Методов повышения привилегий тоже десятки, от эксплуатации уязвимостей ОС до выдергивания и брутфорса парольных хэшей. Используемые уязвимости - непропатченная операционка (80% организаций) или наплевательское отношение к рекомендациям Microsoft по настройке перационой системы (100% орагнизаций). Результат очевиден, нам существенно только наличие привидегии SE_DEBUG, которая позволяет трояну нарушителя работать с памятью других процессов. 3. Перехват PIN - на примере eToken (с другими носителями работает аналогично). Выполняется стандартная атака DLL injection. Используя стандартную функцию Win32 API CreateRemoteThread троян создает в одном из процессов eToken RTE новый поток. В качестве функции потока используется стандартная функция Win32 API LoadLibrary, в качестве ее аргумента - имя одной из DLL трояна. В результате в память процесса RTE загружается эта DLL, управление передается ее функции инициализации. Функции инициализации доступна вся виртуальная память процесса, поэтому она перестраивает блок импорта/экспорта так, чтобы вместо функции создания окна ввода PIN вызывалась бы одна из функций инъектированной DLL. Эта функция, в свою очередь, показывает модальное диалоговое окно ввода PIN, и после его закрытия получает доступ ко всем введенным в это окно даным (в том числе - к элементу управлдения EditBox , в котором в открытом виде лежит PIN. 4. Троян готовит сообщение, которое нужно подписать, инициализирует контекст для работы с криптоядром токена, вызывает в этом контексте функцию MS CryptoAPI CryptSignMessage, передавая в качестве аргумента созданное рояном подписываемое сообщение, аналогично п. 3 подавляет создание модального диалогового окна ввода PIN, и сразу возращает стыренное на шаге 3 значение PIN. Криптоядро послушно выполняет запрошенную операцию. Все. Вообще-то такие вещи положено знать - это стандартная атака на клиентскую криптосистему. Но у нас криптографов таким атакам не учат, а некриптографы впадают в священный трепет при слове "криптография", забывая, что криптосистема без защиты операционной системы - ничто :)

Автор: Светлана | 18590	27.03.2010 16:22
А что за объект "сообщение", которое троян будет подписывать от лица пользователя?

Автор: Светлана | 18591	27.03.2010 16:24
Я, собственно, именно это имела в виде в просьбе рассказать механизм, а не криптографию )) Я хочу понять, что конкретно, подписанное от моего лица может возникнуть, и как это подписанное от моего лица станет использовать злоумышленник. Вашу квалификацию очень уважаю, потому и спрашиваю ))

Автор: Светлана | 18592

27.03.2010 16:37

Я объясню, почему я таким странным образом ставлю вопрос. Мне понятно, как можно использовать украденный закрытый ключ. Украв его, я могу не привязываться к сеансу работы легального владельца (когда его - етокен, как мы с Вами решили? ;) ) подключен к компьютеру и возможно обращение к его криптодвижку. Я спокойно, не обязательно даже на этом же компьютере, не прибегая к написанию программ, а вполне прямо - составляю, например, извещение, или что мне там еще нужно, и подписываю. А каковы мои действия, если я знаю всего лишь пин? Ну, то есть напрашивается - кража токена (неприятно, конечно, да). А система с подготовкой того, что мне нужно подписать на чужом ключе, с помощью трояна... ну, то есть, наверное, все возможно, но как-то очень уж трудоемко. Сильно увеличивается цена вопроса. Обычно в тех системах, где обрабатываются документы, такая атака на которые - реальна, все же есть защита от НСД достаточного уровня, чтобы троян не заработал )) Хочется в это верить, по крайней мере.

Автор: Светлана | 18593	27.03.2010 17:06
Да, и, конечно, я понимаю, что сама спровоцировала, хоть и не то имела в виду спросить, но все-таки, наверное, так уж подробно - это как-то лишнее. Правда, редактировать тут нельзя свои сообщения - вылетит - не поймаешь ))

Автор: malotavr | 18594

27.03.2010 18:07

> Я хочу понять, что конкретно, подписанное от моего лица может возникнуть, и как это подписанное от моего лица станет использовать злоумышленник. Самый распространенный случай - платежи в системах Клиент-Банк. А хакера стоит точно такая же клиентская софтина, которой он легально пользуется. Собственно, все, что ему нужно - разобраться в протоколе обмена информацией между банком и клиентом. Как правило, программисты - существа ленивые, и для обмена используется один из стандартных форматов - S/MIME или XML. Используя свой комплект ключей, реверсер сравнительно легко этот формат расковыривает. Расковыряв протокол, ему уже несложно понять формат сообщения и подготовить абсолютно корректное платежное поручение. Ему нужны только ваши платежные реквизиты, ваш ключ и ваш PIN к ключевому носителю. - Когда такие системы только появлялись, атака на такую систему выглядела совсем просто: отслеживалось наличие в дисководе ключевой дискеты, ее содержимое копировалось, после чего нарушитель, использую точкно такую же клиентскую программу, что и клиент банка, выполнял платеж от его имени. Это было совсем просто, и это до сих пор актуально для многих банков. Чтобы защититься от этого, пошли по двум путям: во-первых, стали выдавать клиентам токены, во-вторых, стали фиксировать за клиентом IP-адрес, с которого платежи могут приниматься. Оба этих решения быстро были обойдены. Ключ их eToken'а выковыривается примерно так же, как я и описал, только шаг 4 выглядит по-другому и достаточно сложно. А из-за фиксации IP-адреса, в платежных системах многих банков красть ключ бесполезно - нужно не только подписать платежное поручение вашим ключом, но и отправить его с вашей машины. Поэтому вместо кражи ключа нарушителю приходится получать контроль над вашей машиной. А получив контроль, можно и с криптоядром поработать, и ваш PIN получить. Итог его работы - с вашего компа, в тот момент, когда в USB торчит ваш ключевой носитель, в ваш банк отправляется синтаксически коорректное платежное поручение, подписанное вашим закрытым ключом. Да, это сложно. Но ненамного сложнее, чем написать трояна к банкомату :) > Обычно в тех системах, где обрабатываются документы, такая атака на которые - реальна, все же есть защита от НСД достаточного уровня, чтобы троян не заработал )) Блажен, кто верует :) Я уже не раз приводил оценки: получение полного контроля над доменом AD организаций, которые достаточно серьезно относится к своей безопасности, занимает 3-5 рабочих дней. Проблема в низком "среднебольничном" уровне квалификации российских безопасников, поэтому тот набор мер и средств, что многие считают "защитой от НСД достаточного уровня", для реального нарушителя препятствием не является вовсе.

Автор: Сергей | 22790

19.10.2010 03:11

malotavr, > Я уже не раз приводил оценки: получение полного контроля над доменом AD организаций, которые достаточно серьезно относится к своей безопасности, занимает 3-5 рабочих дней. Проблема в низком "среднебольничном" уровне квалификации российских безопасников, поэтому тот набор мер и средств, что многие считают "защитой от НСД достаточного уровня", для реального нарушителя препятствием не является вовсе. Не соглашусь с Вашим утверждением насчёт 3-5 дней. Либо много меньше, либо наоборот. Аудит событий в течение одних лишь попыток получить доступ к AD, не прибегая к социальной инженерии, - тоже не проблема? Не подумайте, не пытаюсь усомниться в Вашей квалификации, интересны идеи.

Автор: Робинзон | 22798

19.10.2010 11:19

Коллеги, ваша высокоинтеллектуальная дискуссия крайне интересна, но несколько уклоняется от сути вопроса. Полагаю, что с вопросами цены следует обратиться к разработчикам-производителям этих самых токенов. Рутокен -все бы ничего, но сертификация этого устройства в ФСБ на соответствие гост 28147-89 имеет ограниченный характер, поскольку идет ссылка на формуляр, а там на другой документ из комплекта эксплуатационной документации и из него мы узнаем что: Поскольку Rutoken не имеет аппаратной генерации ключей, в состав сертифициро-ванного изделия входит АРМ для генерации первичной ключевой информации (глав-ного ключа шифрования Rutoken ) - "КРИПТОН-ЗАМОК/К"– один на организацию (подразделение), не подключенный к сети. Состав сертифицированного СКЗИ «ruToken» входит: - автоматизированное рабочее место (АРМ ГК), предназначенное для генерации первичной ключевой информации (ключ датчика случайных чисел) и записи ее в аппаратные модули «ruToken» (одно на сеть связи, не подключенное к сети компьютерной связи) (КБДЖ.466452.006). В комплектации: устройство «КРИПТОН-ЗАМОК/К», включающий аппаратный ДСЧ (КБДЖ.468243.035); драйвер устройства «КРИПТОН-ЗАМОК/К» (КБДЖ.00174-0100); библиотека специальных функций устройства «КРИПТОН-ЗАМОК/К» для ОС Windows 2000/XP/2003 (КБДЖ.00600-0100); программа rtARM_GK.exe для записи ключа для ДСЧ в память аппаратного модуля «ruToken» (КБДЖ.00142-0100) Кроме того, данный сертификат требует соблюдение следующих условий: Срок действия пароля (PIN-кода) пользователя – не более 30 дней. Срок действия главного ключа – не более 1 года. Уничтожение или замена главного ключа должна производиться с полным переформатированием Rutoken (с полной потерей всех пользовательских данных). При использовании Rutoken в системах, подлежащих обязательной защите, в обяза-тельном порядке требуется проведение работ по оценке корректности встраивания. Поскольку Rutoken является СКЗИ (в соответствии с сертификатом) то Организация-поставщик и ее партнеры-дилеры должны иметь соответствующие ли-цензии ФСБ на распространение шифросредств. Требуется вести поэкземплярный учет (в т.ч. при генерации ключа в журнале учета пользователей должна делаться соответствующая запись с указанием Ф.И.О. пользователя и даты генерации ключа). Действуют запрет на вывоз Rutoken за пределы РФ, без оформления соответ-свующего разрешения в ФСБ. Должны быть проведены работы по оценке корректности встраивания СКЗИ Rutoken в информационную систему. Сертификат №1461 ФСТЭК России от 18 сентября 2007 г. и Сертификат №1395 ФСТЭК Рос-сии от 30 мая 2007 г. получены не на ключевой носитель Rutoken а на системное и прикладное программное обеспечение (драйвера). Сертификат соответствия ФСТЭК РФ №1461, по 3-му уровню контроля отсутствия НДВ подтверждает отсутствие функций и свойств не заявленных в документации на изделие Поддерживаемые операционные системы Windows 98, МЕ, 2000, ХР, 2003 При использовании Vista и 7 –условия этих сертификатов не соблюдаются. Сертификат ФСБ требует соблюдения следующих условий: Срок действия пароля (PIN-кода) пользователя – не более 30 дней. Срок действия главного ключа – не более 1 года. Уничтожение или замена главного ключа должна производиться с полным переформатированием Rutoken (с полной потерей всех пользовательских данных).

Автор: Сергей | 53741	01.10.2014 12:55
А не подскажете, что быстрей подписывает, рутокен или Етокен? Иногда важно подписать очень быстро ..

Автор: sekira | 53758	01.10.2014 18:18
Думаю милисикунды при записи встроеной памяти и обмену по USB (речь о килобайтах!) непринципиальны. А дальше вопросы ПО для которого используется криптопровайдер и носитель ключевой информации от него нужно плясать.

Автор: Пессимист | 53767

02.10.2014 11:25

re: Думаю милисикунды при записи встроеной памяти и обмену по USB (речь о килобайтах!) непринципиальны. Там не миллисекунды. Токен который не отдаёт ключ наружу должен производить достаточно сложные преобразования внутри. Внутренний процессор относительно слабый и уступает по производительности ЦП среднего компьютера. Как я понимаю, по порядку величины задержка в сотни или даже тысячи миллисекунд на одну операцию. Для ручной подписи это не критично. Но если в автоматическом режиме нужно подписывать десятки и сотни файлов то разница заметна.

Просмотров темы: 54034

Copyright © 2004-2019, ООО "ГРОТЕК"