Вообще, я не в восторге от того, что, а точнее КАК, ведет себя ФСБ на рынке защиты информации КОММЕРЧЕСКИХ структур. Уж очень непросто выполнять все их требования. А уж про доступ к этим требованиям я вообще молчу - все документы закрытые и даже лицензиаты получают не сами документы и даже не выписки из них, а выписки из выписок. Но пост о другом. Все-таки некоторые требования ФСБ по зрелому размышлению выглядят достаточно здраво (вопрос реализации оставим в стороне).
В первую очередь речь идет о встраивании СКЗИ в какие-либо приложения, системы или устройства. Натолкнуло меня на это размышление презентация Юрия Маслова из КриптоПро на конференции в Магнитогорске. Я раньше как-то не задумывался об этом (да и не сталкивался с этим почти), но... почти все (а может и без почти) прикладные программы (в презентации речь шла о ДБО), которые сегодня заявляют об использовании сертифицированных криптопровайдеров, заставляют рисковать их пользователей. Ведь что заявляют их разработчики?.. Мол мы встроили КриптоПро CSP или Инфотекс VipNet CSP или других 6 или 7 сертифицированных криптобиблиотек, а значит вы можете спать спокойно, т.к. надежность этих СКЗИ подтверждено сертификатом ФСБ.
Да, это так. Сертификаты есть... но на криптопровайдеры, а не на решения, их использующие. Где гарантия, что они корректно используются? Где гарантия, что они вообще используются? Что мешает разработчику просто встроить их в свой софт, но не вызывать ни одной из их функций? А если вызывать, то неправильно? А если правильно, то не обеспечивать защиту от подмены вызова? На каждый из таких вопросов, ответа нет. Более того, его никто и не даст, т.к. такая гарантия должна быть подтверждена независимой стороной. Можно много спорить о сложности процесса сертификации в ФСБ (и невозможности попасть в него без связей), но он дает именно такую гарантию (пусть и не финансовую и не репутационную). Независимых аудиторов кода СКЗИ в России попросту нет. А если нет, то они малоизвестны рынку и цена их слову - грош (т.к. и они ни за что не несут ответственности).
Собственно аналогичная ситуация не только с ДБО, но и с любой СКЗИ. С теми же VPN-решениями. Даже ответ ФСБ на эту тему есть. Вот только мало кто задумывается об этой проблеме. Действительно, риски взлома систем из-за некорректного встраивания СКЗИ пока невелики (именно что пока). А раз так, то зачем тратить месяцы и тысячи долларов на такую проверку? Потребитель (банк) все равно не понимает разницы между сертифицированной системой ДБО и системой ДБО, использующей сертификацированную СКЗИ. Разработчик пользуется незнанием потребителя и уверен, что его продукцию купят и так. Клиент банка вообще почти всегда виноват. А учитывая его низкую квалификацию и доказать-то ничего не сможет. Регулятор тоже мало озабочен данной проблемой. Что в итоге? Все довольны! До начала массовых атак именно на этот механизм защиты систем ДБО и других аналогичных решений, использующих встроенную сертифицированную криптографию.
В первую очередь речь идет о встраивании СКЗИ в какие-либо приложения, системы или устройства. Натолкнуло меня на это размышление презентация Юрия Маслова из КриптоПро на конференции в Магнитогорске. Я раньше как-то не задумывался об этом (да и не сталкивался с этим почти), но... почти все (а может и без почти) прикладные программы (в презентации речь шла о ДБО), которые сегодня заявляют об использовании сертифицированных криптопровайдеров, заставляют рисковать их пользователей. Ведь что заявляют их разработчики?.. Мол мы встроили КриптоПро CSP или Инфотекс VipNet CSP или других 6 или 7 сертифицированных криптобиблиотек, а значит вы можете спать спокойно, т.к. надежность этих СКЗИ подтверждено сертификатом ФСБ.
Да, это так. Сертификаты есть... но на криптопровайдеры, а не на решения, их использующие. Где гарантия, что они корректно используются? Где гарантия, что они вообще используются? Что мешает разработчику просто встроить их в свой софт, но не вызывать ни одной из их функций? А если вызывать, то неправильно? А если правильно, то не обеспечивать защиту от подмены вызова? На каждый из таких вопросов, ответа нет. Более того, его никто и не даст, т.к. такая гарантия должна быть подтверждена независимой стороной. Можно много спорить о сложности процесса сертификации в ФСБ (и невозможности попасть в него без связей), но он дает именно такую гарантию (пусть и не финансовую и не репутационную). Независимых аудиторов кода СКЗИ в России попросту нет. А если нет, то они малоизвестны рынку и цена их слову - грош (т.к. и они ни за что не несут ответственности).
Собственно аналогичная ситуация не только с ДБО, но и с любой СКЗИ. С теми же VPN-решениями. Даже ответ ФСБ на эту тему есть. Вот только мало кто задумывается об этой проблеме. Действительно, риски взлома систем из-за некорректного встраивания СКЗИ пока невелики (именно что пока). А раз так, то зачем тратить месяцы и тысячи долларов на такую проверку? Потребитель (банк) все равно не понимает разницы между сертифицированной системой ДБО и системой ДБО, использующей сертификацированную СКЗИ. Разработчик пользуется незнанием потребителя и уверен, что его продукцию купят и так. Клиент банка вообще почти всегда виноват. А учитывая его низкую квалификацию и доказать-то ничего не сможет. Регулятор тоже мало озабочен данной проблемой. Что в итоге? Все довольны! До начала массовых атак именно на этот механизм защиты систем ДБО и других аналогичных решений, использующих встроенную сертифицированную криптографию.
34 коммент.:
Лично я, не считаю задачу встраивания криптосредств в ПО очень уж потенциально опасной задачей:
Речь идет десятке функций CryptoAPI, применение которых достаточно элементарно...
КриптоПРО кстати в комлекте ПО для разработчика предоставляет довольно качественные примеры.
Приведите, пожалуйста, возможный пример некорректного встраивания.
to kukalo:
Чтобы увидеть примеры объявите конкурс по взлому с адекватными денежными призами. :)
Я бы вот ещё что добавил, есть методики ФСБ 2008г., так вот там для "мирных целей" говорится, что до уровня КС2 процесс встраивания выполняется без контроля государства лицензиатом ФСБ. Если конечно данное утверждение не противоречит записи в формуляре для конкретного СКЗИ или контроль корректности не вписано заказчиком в ТЗ. Работы выполняет лицензиат, его должный уровень знаний был проверен при выдачи лицензии, соответственно нет больших причин беспокоится в его некомпетентности. В противном случае можно точно также подозревать в некомпетентности и испытательные лаборатории.
kukalo: Я же написал в посте. Отсутствие вызова CSP несмотря на его наличие. Вот вам пример некорректности встраивания.
msm59: Да, верно. Но касается это только персданных. И по тому же КриптоПро в формуляре ВСЕГДА есть фраза о необходимости сертификации готового изделия.
Налажать-то можно где угодно. Тем не менее, Карфаген должен быть разрушен, а ФСБшная кормушка если не закрыта, то сильно урезана. Давайте заменим сертификацию self-assessment'ом с ощутимой ответственностью за нарушения. А ФСБ пусть вместо того, чтобы стричь деньги, подготовит РД, как его следует проводить. И всем будет лучше (кроме понятно кого). Действительно, корректно использовать десяток функций -- не ракетная физика.
kukalo: да простейший пример, вместо CryptDeriveKey вызвать CryptImportKey, подсунув пароль в качестве ключа. Шифрование будет даже выглядеть как настоящее, только половина бит в ключе - заведомо нулевые.
2 blaze:
Ок, пример понял, а как данные будут расшифрованы?
На другой стороне passkey никто не знает, там есть криптопрошный контейнер с закрытым ключом...
2 Алексей Лукацкий:
Рассмотрим типовую схему ДБО:
1) Генерирация закрытого ключа (Запускаеся КриптоПРО)
2) Генерация запроса на сертификат
3) Издание сертификата
4) Использование сертификата+закрытого ключа для функций ЭЦП/шифрования
Как провернуть эту схему без вызова CSP?
Алексей, вопрос с подвохом - допустим я поставил на Windows Server КриптоПро CSP и организую некий защищенный web узел с помощью встроенного в Windows Server web-сервера IIS.
Чью корректность встраивания и куда в таком случае надо проверять?
А подобные вопросы возникают и когда люди организуют VPN соединения средствами Windows Server или используют защиту терминальных сессий с помощью SSL и КриптоПрошных алгоритмов.
Во всех этих случаях корректность встраивания - некоторый абсурд. Это Microsoft нам подтвердил корректность встраивания сертифицировав КриптоПро как CSP.
doom:
"Во всех этих случаях корректность встраивания - некоторый абсурд. Это Microsoft нам подтвердил корректность встраивания сертифицировав КриптоПро как CSP."
А кто подтвердит корректность Microsoft? Ну не может производитель быть контролером. По логике вещей не может. Нужно третье лицо, которое при случае рискует лицом.
2 Permyakov:
Вообще-то, в отличие от ФСБ, производитель лицом как раз рискует :)
На западе популярна именно внутренняя сертификация производителями (см. например, программа сертификации драйверов Windows или RMS совместимых приложений).
Неужели какой-то ФСТЭК сможет гарантировать корректную реализацию RMS клиента лучше Microsoft?
Так MS и "сертифицировал" КриптоПро. Мол сделано все правильно... на стыке "MS - КриптоПро". А вот за стык "КриптоПро - прикладуха" MS отвечать не может и это правильно. А вдруг у меня КриптоПро есть, а я его не вызываю ни на стороне клиента, ни на стороне сервера?.. У меня все ходит в открытом, неподписанном и незашифрованным виде. Ведь это никто не проверяет. Об этом и речь... Тоже самое с VPN. Никто не гарантирует, что тот же Чекпойнт использует шифрование по ГОСТ, а не обычный XOR, названный ГОСТом.
MS "сертифицировал" КриптоПро.
MS же должен сертифицировать корректность работы прикладного приложения с CryptoAPI - причем тут КриптоПро или ФСБ совершенно непонятно.
Я же не просто так привел IIS, RRAS или терминальный сервер - они с тем же успехом используют Microsoft Enchanced Crypto Provider, какой-нибудь RSA Security crypto Provider и еще бог знает что - это технология такая: отделить криптографию от прикладного уровня. Поэтому единственная корректность о которой может идти речь - это корректность реализации "CSP клиента" (назовем это так) и авторы конкретных провайдеров к этому отношения не имеют и иметь не должны.
А я про это и говорю ;-) И Юрий Маслов про это говорил. Не дело разработчику CSP отвечать за прикладуху и ее разработчиков. А вот последние и плюют на проверку корректности встраивания.
2 Алексей Лукацкий:
Наконец-то конкретный пример:
"А вдруг у меня КриптоПро есть, а я его не вызываю ни на стороне клиента, ни на стороне сервера?..
У меня все ходит в открытом, неподписанном и незашифрованным виде. Ведь это никто не ПРОВЕРЯЕТ."
Эту схему достатоно легко ПРОВЕРИТЬ - "защищенный" канал связи будет устанавливаться на любых ключах по обеим сторонам обмена...
Все обозначенные выше проблемы можно решить логированием основных действий CSP, если уж такая боязнь есть по поводу их встаивания....
Всякие там дополнительные орг. меры только "удушат" и без того слабенький рынок стартапов, использующих криптографию...
kukalo: какой криптопрошный контейнер? Это генерация ключа по паролю для обычного симметричного шифрования.
И это, кстати, косяк в использовании CryptoAPI. А можно и корректно его использовать, правильно создать симметричный ключ, вот только включить режим гаммирования и зафиксировать синхропосылку. Fail.
"Cross the bridge when you come to it". Когда появится реальная потребность в сертификации всей системы, тогда появится и сертификация - всё по законам рынка. Как с ПДн: когда понадобилась защита, появились и средства, и законы...
2 Алексей Лукацкий:
Хорошо. Теперь вернемся к стандартному аргументу про встраивание отечественной криптографии в западные VPN решения.
Пусть есть некоторое программное средство - например, тот же Direct Access в ОС Windows. Он, вроде как, корректно работает с технологией криптопровайдеров - скорее всего, есть даже и сертификация (международная), если поискать (и уж точно никто лучше MS не оценить корректность использования библиотек CNG). Теперь мы заменили криптопровайдер, который логически отделен от реализации Direct Access - почему тут-то вдруг появляется какая-то необходимость оценивать корректность встраивания? Чего и куда встраивания? Если КриптоПро корректно реализует CryptoAPI, а Direct Access корректно использует CryptoAPI - то вся эта корректность встраивания получается автоматически - по транзитивности. В этом и цель, в общем-то, в создании всяких CryptoAPI. На западе с самых 60-ых годов стараются всегда уменьшать ту самую TCB, которую надо сертифицировать - а у нас наоборот.
Ключевое слово "вроде как" ;-) А если никак?
Если никак, то моя вера в MS будет сильно подорвана :)
А если серьезно - кто это сможет проверить? У того же Oracle (да и у MS) такие вопросы решаются путем внутренней сертификации - весь мир это устраивает. Может и нас уж когда-нибудь будет устраивать?
Для doom
Я как то разговаривал с одни генералом на тему корректности встраивания, так вот они прекрасно понимают что это такое и их более интересует чтобы была Модель угроз и прописана правильная политика безопасности для конкретной системы в конкретных условиях эксплуатации, а не вопрос корректности реализации КриптоАПИ.
2 msm59
Ну вот тем более - влияет ли используемый криптоалгоритм на модель угроз и политику безопасности системы?
Разве что, на максимально допустимое время жизни ключа это может влиять - больше ничего особо в голову не приходит...
Поэтому, если есть некоторая система X гражданского применения и для которой есть адекватные документы по ее безопасной эксплуатации, то какой глубокий смысл все на свете пересматривать на уровне ФСБ как только нам потребуется использовать альтернативный криптопровайдер?
doom
Я что то не понял вы о чём написали, если вы позиционируете свою систему как защищённую средствами СКЗИ, то напишите Модельку это как минимум, оттуда поймётся класс защищенности и адекватное ему средство и т.п.
Если же у вас гражданское (что это такое мне не понятно, видимо слабо защищённое) используйте NSS или CSP и на любом алгоритме не подпадающим под действие ПП 957.
Если все зависит от модели, то почему нельзя рарешить использовать в системах гражданского применения AES и 3DES? Чем они мешают?
2 msm59
Во-первых, я говорю не о своей системе. Я говорю об эффективных существующих решениях, которые ВНЕЗАПНО становятся "вне закона" из-за непонятных требований наших органов.
Во-вторых, класс защищенности (который ФСБшный) вряд ли поймется по причинам, о которых Алексей написал в исходном посте.
В-третьих, как верно замечено, моя модель угроз тут же покажет, что AES понадежнее ГОСТ 28147 будет...
Для Алексея.
На сейчас существует ПП 957 и там написано что требует регуляции, а что - нет. Не я придумал это ПП, но оно вот такое есть. И в нём видимо ответ на тему использования AES - ключик длинный наверное. Всё что короткое и не подпадает по ПП 957 пользуйте как вам нравится.
Для doom
1. Не понял, почему ВНЕЗАПНО ? Правила игры известны давно.
2. В Моделе среди прочего обосновывается класс защищенности, если вы этого не делаете в этом документе , то это уже не Модель а какой то другой документ.
3. А я вам могу прокинуть исследования китаёзов в котором говорится что 28147 - весьма крут для определённых задач. Так что ваше утверждение не убеждает.
Чтобы использовать еще ввезти надо ;-) Там тоже не все так просто. Но дело не в этом ;-) Я тоже считаю, что действующее регулирование криптографии никуда не годится и что вопрос оценки корректности встраивания правильный. Только реализация подкачала.
Может я что-то не понял
1. Работа CryptoAPI проверяется элементарным отладчиком (какие методы какой библиотеки вызываются)
2. При встраивании в ДБО некоторые производители криптографии сами делают библиотеки заточенные под ДБО
3. Библиотеки СКЗИ получают сертификат на использование во вполне конкретном окружении и по определенным регламентам (от окружения зависит и КС1 или КС2, например)
ИМХО: достаточно контроля криптопровайдера со стороны ФСБ.
А кто-нибудь читал формуляр на КриптоПро? Там черным по белому написано - при встраивании КриптоПро куда-либо будь добр проверить корректность по ТЗ, согласованному с восьмеркой...
2 Алексей:
Читал. Но там написано хитрее и мутнее:
1.5. Должна проводиться проверка корректности встраивания СКЗИ ЖТЯИ.00050-01 в прикладные системы в случаях:
• если информация, обрабатываемая СКЗИ, подлежит защите в соответствии с законодательством Российской Федерации;
• при организации криптографической защиты информации конфиденциального характера в федеральных органах исполнительной власти, органах исполнительной власти субъектов Российской Федерации;
• при организации криптографической защиты информации конфиденциального характера в организациях независимо от их организационно-правовой формы и формы собственности при выполнении ими заказов на поставку товаров, выполнение работ или оказание услуг для государственных нужд.
Вывод номер 1: при защите КТ аттестация не обязательна (правда обмен клиент ДБО-банк, как я понимаю, содержит банковскую тайну)
Вывод номер 2: аттестация должна быть только при встраивании в прикладные системы.
Подвывод 2.1: установка КриптоПро в ОС Windows не является встраиванием, корректность которого надо аттестовывать.
Подвывод 2.2: все компоненты ОС Windows заведомо "корректно встроены".
Вывод 3: использование связок IIS+КриптоПро, Terminal Services GateWay + КриптоПро и т.п. реализует криптрографически защищенный канал связи, удовлетворяющий требованиям ФСБ РФ.
А если эта цепочка не верна, то тогда получается, что клиент банка не может просто произвести установку ПО клиента ДБО - он (ну или банк) должен провести оценку корректности встраивания, что, очевидно, нереализуемо.
И тогда опять возникает вопрос - дак что же считать встраиванием? В ФСБ есть (опять же закрытая) классификация АС по степени защиты информации, которые применяют СКЗИ для защиты информации (всякие АК5 и т.п.) - вот если ввести требование по сертификации системы по требованиям этих классов, то звучало бы, наверное, разумнее (но опять же - при текущей реализации сертификации в ФСБ это было бы совершенно невозможно выполнить)
Вывод 1 неверен - БТ - это охраняемая по закону информация. Как и еще 49 видов тайн.
Вывод 2 - да, мы и говорим про ДБО. Про VPN ФСБ четко ответило в письме по ссылке - нужна сертификация изделия целиком.
Подвывод 2.1 - согласен. Только вот на серверной стороне этого уже недостаточно ;-(
Подвывод 2.2 - где логика? Есть А, есть Б, но нет доказуемой связки ;-)
Вывод 3 - согласен, но к ДБО отношения не имеет ;-)
Иногда у меня возникает подозрение, что вся сертификация криптографии на фоне запрета на "сильные" западные алгоритмы нужна только для облегчения работы ФСБ при расшифровке данных. Что вендоры и обеспечивают. Проблемы клиента мало интересны ФСБ(хотя должны бы, некоторые виды тайны охраняются законом) и вендорам.
PS. Очень сильно раздражает навязывание морально устаревшего алгоритма.
2 ZW:
про морально устаревшие алгоритмы - это сильно!
Зачем рассуждать о том, о чем нет представления? я имею ввиду систему сертификации, гос. тайну, всякие там модели 2020 и т.д.
Отправить комментарий