В четверг выступали с Мишей на конференции. Кто не смог присутствовать, но сильно хотел, выкладываю презентацию и демонстрационное видео.
Презентация:
Демонстрационное видео, традиционно, у Миши в канале:
Извлечение неэкспортируемого контейнера секретного ключа из APDU-трафика:
http://www.youtube.com/watch?v=9ugl1Xwh5s4
Извлечение неэкспортируемого контейнера секретного ключа при помощи утилиты Antitoken (эмуляция работы приложения криптопровайдера):
http://www.youtube.com/watch?v=TrcBM_bBq6E
Извлечение неэкспортируемого контейнера секретного ключа при помощи утилиты secretdump4cp (патчинг флага неэкспортируемаости в памяти процесса):
http://www.youtube.com/watch?v=7Jg73qbZqC0
Атаки на пароль пользователя:
http://www.youtube.com/watch?v=v4Q4d-i04lk
Все используемые утилиты доступны в Git: https://github.com/votadlos/Antitoken
Выступление снималось, вероятно, будет видео.
Несколько слов об обсуждении с залом.
Посыл из зала 1: Данная схема с токенами не предполагает использование на скомпрометированном компьютере.
Ответ 1: Вся презентация про то, что токен нужен только для того, чтобы ключ там хранился неизвлекаемым образом. Если ключ из токена неизвлекаем, то токен безопасно вставлять в скомпрометированный компьютер - ключ из токена не будет утащен. Верно и другое утверждение: если для использования токена мы требуем доверенность компьютера (т.е., что токен можно использовать исключительно на нескомпрометированном компьютере), то токен нам не нужен: действительно, если компьютер не может быть взломан, то ключ из компьютера не может быть извлечен :)
Посыл из зала 1': Если токен, даже с неизвлекаемым ключом будет использоваться на скомпрометированном компьютере, то эта схема не будет безопасной, так как злоумышленник сможет генерить подпись (и прочие криптопреобразования) не экспортируя при этом ключ.
Ответ 1': Вот с этим согласен! Но этот случай несколько более сложен, чем просто скопировать (экспортировать) ключ и далее использовать его по своему усмотрению.
Посыл из зала 2: То что вы показали - это верно для КС1, а для КС2 так не сработает.
Ответ 2: Во-первых, я не знаю где взять нормальное техническое описание КС1, КС2 и пр. Технические спецификации этих КС* также защищены "дополнительным уровнем защиты" о котором упомянуто на слайде 8. А во-вторых, мы исследовали самую распространенную схему применения ГОСТовой криптографии, причем эта схема позволяет подпись считать квалифицированной. В моем понимании безопасность должна постоянно адаптироваться под среду, о чем я не раз писал, поэтому надо строить защиту не от каких-то сферических моделей нарушителей в вакууме, а от наиболее распространенных сценариев атак. К сожалению, на практике мы имеем, что самая распространенная схема использования ГОСТовой криптографии с токенами вместе с тем является самой небезопасной, при том, что есть более безопасные схемы.
Презентация:
Демонстрационное видео, традиционно, у Миши в канале:
Извлечение неэкспортируемого контейнера секретного ключа из APDU-трафика:
http://www.youtube.com/watch?v=9ugl1Xwh5s4
Извлечение неэкспортируемого контейнера секретного ключа при помощи утилиты Antitoken (эмуляция работы приложения криптопровайдера):
http://www.youtube.com/watch?v=TrcBM_bBq6E
Извлечение неэкспортируемого контейнера секретного ключа при помощи утилиты secretdump4cp (патчинг флага неэкспортируемаости в памяти процесса):
http://www.youtube.com/watch?v=7Jg73qbZqC0
Атаки на пароль пользователя:
http://www.youtube.com/watch?v=v4Q4d-i04lk
Все используемые утилиты доступны в Git: https://github.com/votadlos/Antitoken
Выступление снималось, вероятно, будет видео.
Несколько слов об обсуждении с залом.
Посыл из зала 1: Данная схема с токенами не предполагает использование на скомпрометированном компьютере.
Ответ 1: Вся презентация про то, что токен нужен только для того, чтобы ключ там хранился неизвлекаемым образом. Если ключ из токена неизвлекаем, то токен безопасно вставлять в скомпрометированный компьютер - ключ из токена не будет утащен. Верно и другое утверждение: если для использования токена мы требуем доверенность компьютера (т.е., что токен можно использовать исключительно на нескомпрометированном компьютере), то токен нам не нужен: действительно, если компьютер не может быть взломан, то ключ из компьютера не может быть извлечен :)
Посыл из зала 1': Если токен, даже с неизвлекаемым ключом будет использоваться на скомпрометированном компьютере, то эта схема не будет безопасной, так как злоумышленник сможет генерить подпись (и прочие криптопреобразования) не экспортируя при этом ключ.
Ответ 1': Вот с этим согласен! Но этот случай несколько более сложен, чем просто скопировать (экспортировать) ключ и далее использовать его по своему усмотрению.
Посыл из зала 2: То что вы показали - это верно для КС1, а для КС2 так не сработает.
Ответ 2: Во-первых, я не знаю где взять нормальное техническое описание КС1, КС2 и пр. Технические спецификации этих КС* также защищены "дополнительным уровнем защиты" о котором упомянуто на слайде 8. А во-вторых, мы исследовали самую распространенную схему применения ГОСТовой криптографии, причем эта схема позволяет подпись считать квалифицированной. В моем понимании безопасность должна постоянно адаптироваться под среду, о чем я не раз писал, поэтому надо строить защиту не от каких-то сферических моделей нарушителей в вакууме, а от наиболее распространенных сценариев атак. К сожалению, на практике мы имеем, что самая распространенная схема использования ГОСТовой криптографии с токенами вместе с тем является самой небезопасной, при том, что есть более безопасные схемы.
26 comments:
Хороший доклад, но один нюанс, схемы с перехватом аутентифицированного APDU трафика уже лет пять, как используются в банковских троянах. Тут без разницы на экспортируемый ключ или нет и где проверяется подпись ;)
Почти три года назад рассказывал на PHD об этом =)
http://www.slideshare.net/matrosov/smartcard-vulnerabilities-in-modern-banking-malware
Саш, спасибо за коммент!
Два уточнения:
Во-первых мы из APDU-трафка перехватывали непосредственно секретный ключ :). Проблема тут как раз в нарушении "Основного принципа" - ключ покидает токен (поэтому может быть перехвачен из трафика).
Во-вторых, перехват из APDU-трафика не самый хороший вариант, так как требует административного доступа (чтобы ставить хук в winscard.dll), поэтому есть другие методы, показанные в Демо2 и Демо3 - работают от непривилегированного пользователя.
Сагласен, по поводу секретного ключа это здорово, прикольные демки. В случае троянов, все прозаичнее, они просто перехватывали пароль к токену и потом управляли на уровне APDU с C&C подтверждене платежных документов.
Отлично что вы на самом деле обратили внимание общественности на проблему, что токены, которые не имеют возможности подписи/шифрования непосредственно на устройстве извликают ключ все равно в память компьтера. И вот тут все зависит от софта насколько он эту самую ключевую информацию защищенно хранит. В случае вредоносного ПО, тут ничего не меняется, тк нужна только возможность доступа к токену, которая обеспечивается установкой вредоносного ПО. А все пароли оператор сам введет :)
Одним из месседжей доклада было то, что если ключ из токена уходит в приложение - не существует надежных механизмов обеспечения защиты.
Тут все предельно просто: если бы софтверно можно было бы обеспечить сохранность ключа, токены были бы не нужны :)
Еще раз спасибо за внимание к нашей работе!
Скажите, если я вам дам такой токен на час. Вы сможете принести мне через час распечатанный ключ?
1. Помимо токена нужен будет и пароль от него.
2. Распечатанный ключ в каком формате?
Если вы хотите распечатать ключ в формате PKCS#12, то к сожалению, у меня никак не дойдут руки сделать утилитку и выложить ее в свободный доступ, которая сделает из файлов экспорта КриптоПРО (*.key) PKCS#12.
Но такие утилитки есть платные:
P12FromGostCSP от Лисси: http://soft.lissi.ru/downloads/
Вытащить из P12 ключ можно, например, openssl-ем:
http://reply-to-all.blogspot.ru/2012/10/openssl.html
см. команду 3.3*
вытащив ключ, его можно распечатать.
На ваш вопрос ответ: "скорее, да", если вы используете криптопровайдер "КриптоПРО CSP", т.е. не используете схемы с поддержкой ФКН (https://www.cryptopro.ru/products/fkc/info), т.е. не "КриптоПРО Rutoken CSP", не "КриптоПРО eToken CSP".
"Скорее", потому что я не покупал утилитку от Лисси, а свою пока не написал, чтобы все это проверить. Как только я это проверю "скорее," пропадет.
Ну вы же понимаете провокационность моего вопроса ;) Я требую смелости!
Ответьте просто: ДА или НЕТ?
Провокационности вашего вопроса я не понял. Ответ: "Да".
Отлично!
А как же ваше: "1. Помимо токена нужен будет и пароль от него"?
Я действительно не понимаю...
Так сможете? Готовы продемонстрировать?
Еще раз, мы даем вам токен, идем пить кофе и вы через час принесете закрытый ключ? Правильно? Без подвохов и приколов?
Без подвохов.
Вы даете:
1. Пароль от токена.
2. Сам токен.
Я вам отдаю:
1. Копию вашего ключа.
Как это делается показано в трех видео, ссылки на которые даны в посте: "Извлечение неэкспортируемого контейнера секретного ключа из APDU-трафика", "Извлечение неэкспортируемого контейнера секретного ключа при помощи утилиты Antitoken", "Извлечение неэкспортируемого контейнера секретного ключа при помощи утилиты secretdump4cp".
Видео лежит на YouTube. утилита Antitoken - в GitHub-е.
Кофе можете не успеть выпить, продолжительность операции равна продолжительности видео (~ 3 минуты).
Стоп стоп стоп...
Вы что же меня за дурака держите?
Я же четко написал:
"Скажите, если я вам дам такой токен на час. Вы сможете принести мне через час распечатанный ключ?"
Вы мне четко ответили:
"Ответ: "Да"."
Никаких условий больше не было. Это вы меня обманываете?
Вы что же... хотите и сейф и ключ?
Какова же угроза для меня с этим токеном, если вы на самом то деле не можете имея токен вынуть из него именно закрытый ключ? А если у вас полный доступ к системе то он и не нужен, есть более легкие пути ;) Не так ли?
В чем по-вашему отличие токена от флешки\дискетки?
Спасибо, мне было достаточно того, что вы не смогли честно сказать НЕТ!
Перечитывал наше с вами общение и заметил, что "December 2, 2014 at 11:05 PM" написано "Ответ "Да".
В целом, если вы это воспринимаете как "НЕТ", позвольте мне вас в этом не переубеждать.
Касательно схемы, о которой рассказано в этой презентации, могу с уверенностью заявить, что ее стойкость практически эквивалентна схеме без токена, т.е. если вы ее используете у себя на предприятии - можете сэкономить на токенах немалые деньги (~1500 р. за штуку), поскольку при использование этой схемы утащить ключ с этого токена не сложнее чем из реестра Windows или простой флешки, даже при указании флага неэкспортируемости ключа при его генерации.
Надеюсь, я помог сэкономить средства на обеспечение безопасности, т.е. повысить ее эффективность :)
Спасибо за комменты!
Сергей, владея пин-кодом и устройством вам не надо тратить свои силы на экспорт ключа.
Вот было бы любопытно, если вам удалось получить доступ к закрытому ключу не владея пин-кода.
Сергей, еще один вопрос, вы какие ключи извлекайте из токенами Гост или Rsa?
Денис,
ключи ГОСТ.
Товарищи, тут все очень просто, никакой науки: токен нужен только для одной цели - неизвлекаемого хранения ключа.
Если у вас схема с токеном такова, что ключ из него извлекается - токен не нужен.
Именно поэтому токен так сложно устроен, практически эквивалентен компьютеру: там есть железо, процессор, операционная система, приложения, даже интерпретатор Java и апплеты Java.
На практике получить пин от токена несложно, а зная пин, можно _экспортировать_ ключ. Фактически, раз воспользовавшись таким токеном на взломанном компьютере - ваш ключ компрометируется. Поэтому такую схему можно использовать только на компьютере, который не может быть скомпрометирован. А раз мы требуем чтобы компьютер был нескомпрометирован (гарантированно не взломан), то зачем нам токен вообще - используйте хранилище Windows, при условии, что Windows не взломан (это наше условие) - ключ из хранилища Windows не может быть извлечен.
Полностью поддерживаю точку зрения Сергея. Я сам исследовал эту проблему еще года 3 назад, пришел к таким же выводам. Теперь лично для себя и своих проектов применяю только токены с неизвлекаемым ключем. Для тех, кто спорит насчет пин-кода, объясню, что в данном случае нарушается основной принцип многофакторной аутентификации (в данном случае, иметь физический токен и знать пароль). В случае извлекаемости ключа, злоумышленник будет иметь и то и дугое.
Впрочем, здесь хозяин-барин, наше дело предупредить, а ваше дело отказаться. Здесь как и с платежными картами, кто-то полагается на пин-код, а кто-то применяет только чип-карты. Однако всеравно пришли к тому, что на законодательном уровне приняли решение, что карты без чипа предлагать клиентам нельзя будет.
Давайте я еще на пальцах попробую.
У информации хранимой в электронном виде есть одно замечательное свойство - она легко копируется. То есть если кто-то получил доступ к моей инфомации (например, секретному ключу), то можно считать, что она стала доступна всем.
Чтобы изменить это свойство, придумывались разные странные технологии. Но самой эффективной считалась (читаем по слогам) хранение информации на физическом устройстве, без возможности ее извлечения оттуда.
То есть скопировать информацию нельзя. Можно только украсть устройство. В этом сила аппаратных токенов. И не важно знаете вы пароль на токен или нет.
Сергей и Михаил в своем исследовании показали, что производители не умеют корректно использовать возможности предоставляемые токенами и ключевая информация, хранимая на токене, не потеряла свойство дублирования.
Вывод: функционально, токен за 1500р или флешка за 100р с криптоконтейнером, абсолютно идентичны.
Правильно ли я понял, что если устройство позиционируется как токен с неизвлекаемыми ключами, из этого не следует, что в процессе работы с приложением ключи всегда остаются в токене.
Я возможно не так глубоко знаю/понимаю процесс, но у меня всегда возникал вопрос насчет работы системы банк-клиент, используемой у нас. Есть система банк-клиент, система криптозащиты (ПБЗИ), устанавливаемая на клиентское место, и Etoken ГОСТ, в состав поддерживаемых криптопровайдеров которого не входит это ПБЗИ. Получается, что Etoken ГОСТ служит только для хранения ключа, который извлекается в процессе подписи/шифрования сообщения?
Сергей, я не знаю что такое "ПБЗИ", к сожалению, это надо проверять.
Но, если используемый вами токен по спецификации аппаратно (на уровне ОС токена, или приложения токена) не поддерживает ГОСТ (как в случае, рассказанном в презентации), то ключ для обработки передается в приложение. А раз он передается из приложения (вообще покидает токен), то он гарантированно может быть перехвачен как с уровня Windows (хук на winscard.dll - первая демо), так и с уровня приложения (третья демо) или просто имитацией работы приложения (Приложение как-то говорит токену "дай мне ключ" и токен его отдает, соответственно, можно написать свою программу, которая будет просить токен "отдать ключ" - это и делает утилита antitoken.exe, - вторая демо).
Итого: берите спецификацию на используемый вами токен. Если там, в токене, не реализован ГОСТ, то 100% токен используется как флешка, а следовательно, все описанные в презентации атаки там работают. Если токен по спецификации ГОСТ поддерживает (и все вычисления с ключом могут производиться в токене), то задача сложнее - надо разбираться, что приложение использует эти сервисы токена по работе с ГОСТовым ключом.
Добрый день. Вы рекомендуете использовать токен с ГОСТ-ом. Но ведь эта рекомендация исходит из того, что эта тема еще просто не исследована независимыми экспертами?
А на самом деле "не извлекаемый" ключ вполне просачивается в память компьютера при работе с приложениями.
Добрый день, подскажите пожалуйте пожалуйста нужно размножить Rutoken lite, при попітке сделать єто используя antitoken выскакует ERROR: Failed SCardConnect: -2146435063
inserted token has ATR: 00:00:00... (и т.д. много нулей)
Я так понимаю в программе записані настройки под другой вид токенов, подскажите как перенастроять для Rutoken lit
Добрый день!
Насколько я помню, в Rutoken вычисления с секретным ключом производятся непосредственно в токене, а, поскольку ключ не покидает токен, его не получится экспортировать.
Показанные в докладе уязвимости относятся к тем схемам, когда вычисления с секретным ключом производятся в оперативной памяти ПК и, следовательно, могут быть перехвачены через драйвер Windows на своем пути из токена в приложение, работающее с ключом.
Post a Comment