… все будет работать, имхо, через openssl+токен напрямую
А в чем координальное отличие? Вместо CSP будет требоваться OpenSSL, один cliet-side софт меняется на другой.
Утверждать что OpenSSL более безопасный чем тот же КриптоПРО CSP считаю не корректным. Надо сравнивать по моделям угроз и ТЗ систем для которых применяется СКЗИ.
В тоже время если вопрос в деньгах, то можно использовать бесплатный криптопровайдер VIPNET CSP или бесплатную версию КриптоПРО CSP (она становится таковой, когда заканчивается триал) правда у нее нет возможности формировать ЭП, можно только проверять.
Цель статьи как раз и было показать, что то ПО которое обычно продает УЦ не позволяет достичь тех характеристик, которые работники УЦ заявляют при продаже.
Отмечу, что рассматривается ситуация, когда нарушителю известны пароли и другая аутентификационная информация (например, брелки 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. Кроме это по мимо ключей УЦ вы наверняка еще пользутесь услугами дистанционного банковского обслуживания Интернет Клиент-Банк, а это отдельная песня.
Скопировать ключи можно не с любых токенов, но довольно с многих.
Галкой «неизвлекамый» — вы наварено называете «не экспортируемый». Стоит отметить, что наличие данной галки — обрабатывается только СКЗИ. А это значит, что если ключевая информация доступна в обход СКЗИ (например, ключ хранятся на флешке или в реестре), то она может быть успешно скопирована не смотря на галку.
Таким образом, ответить на ваш вопрос о возможности копирования ключей, для которых стоит галка «не экспортируемый» можно следующим образом:
— Если к ключевой информации можно обратится в обход СКЗИ, то не смотря на эту галку их скопировать можно.
Применительно к токенам обходные маневры расписаны в статье
УЦ по распределенной схеме галки не ставит вообще никакие, так ключевую пару генерирует пользователь.
А по централизованной схеме, кто во что горазд.
У меня лично был опыт, когда при генерации ключа для ДБО ИКБ меня пустили за компьютер офицера безопасности Банка, ответственного за генерацию ключей, хотя в Банке я был впервые. Поэтому утверждать, что там делает УЦ по централизованной схеме это более чем смело.
А по поводу извлечения ключей — предлагаю просто попробовать. Возьмите (если у вас есть к ним доступ) ключи в вашей организации и попробуйте их скопировать :)
Я думаю после этого вы посмотрите на проблему под другим углом.
Уважаемый коллега, из КРИПТО-ПРО, согласен что аббревиатура ФКН это «ваше изобретение» (в хорошем смысле)
Когда писал статью, долго думал как назвать «токены с не извлекаемым ключом» по науке. Вы в своих статьях упоминаете термины «активный вычислитель» и др., на мой взгляд предлагаемые термины немного сложны для понимания не криптографам.
С другой стороны Функциональный ключевой носитель (ФКН) — сообщает базовые характеристики устройства:
— выполнение функций,
— хранение ключа.
Другое дело в том, что ваша реализации ФКН, возможно более продвинутая по сравнению с другими (ФКН от КРИПТО-ПРО, обеспечивает защиту канала связи между токеном и ЭВМ).
Таким образом термин ФКН на мой взгляд наиболее удачен в данном случае.
Давайте еще раз разберемся в чем разница между «не экспортируемым» ключом и «неизвлекаемым».
Например вы сгененрировали ключ и поставили галку что ключ неэкспортируемый. Что это значит? А значит это, то что средствами СКЗИ его скопировать не получиться. Но когда выполняется подпись документа, ключ с токена копируется в память ЭВМ, где обрабатывается криптопровайдером, Основной баг этой схемы в том, что ключ может быть похищен из ОЗУ.
Галочку что ключ «не экспортирумый» можно поставить и при генерации ключа на обычном токене, для этого необязательно покупть более дорогой токен с «неивзлекамым ключом».
Теперь рассмотрим неизвлекаемые ключи. В этой схеме ключи, хранящиеся на токенах никогда не подают в память ЭВМ все криптографические операции связанные с использованием ключа выполняются сугубо на токене. Таким образом ключ скоприровать невозможно.
В этом принципиальное отличие.
Суть статьи в том, что вы берете устройство — токен, заходите на сайт производителя, там везде токен с неизвлекаемым ключом это очень круто, безопасно и т.д. (с чем я согласен :)
Берете свое СКЗИ используете этот токен — СКЗИ работает, файлы подписываются, и у вас может сложится ложное мнение о том, что ваша схема — это схема с ФКН, но на самом деле нет.
На примере JaCarta — http://aladdin-rd.ru/catalog/jacarta/gost/specification. В ней исползуется чип — http://pdf1.alldatasheet.com/datasheet-pdf/view/255626/ATMEL/AT90SC25672RCT.html
Автор, подскажите… какой именно функционал содержит апплет в аппаратной части?
Про функционал не подскажу, этот вопрос лучше адресовать производителям токенов. Неплохая документация по токенам — http://dev.rutoken.ru/
Точнее: можно ли с помощью него реализовать шифрование ГОСТ без установки ГОСТ-криптобиблиотек непосредственно на рабочую станцию.
В общем случае так сделать нельзя. Прикладное ПО (например, MS outlook) обращается к крипторафическим библиотека по какому либо стандартному интерфейсу, например MS CryptoAPI. Для того чтобы этот интерфейс был доступен и нужны криптопровайдеры. НО. Можно пойти по пути как сделал КриптоАРМ. Они умеют самостоятельно общаться с токеном, фактически реализуя встроенную криптобиблиотеку.
УЦ — обычно применяют распределенную схему генерации ключей. В данной схеме они ожидают от нас запрос на сертификат + подписанные бумажки, после получения которых они выпускают сертификат. Генерацию ключей и размещение их на носителях осуществляет пользователь.
Но когда вы «покупаете подпись», то вам скорее всего понадобятся СКЗИ и токены, вот здесь и проявляют себя продавцы в полную силу и начинают продавать то, что вам не надо.
Вбить в конфиг и сохранить в файл или построить работающую сеть, использующую оборудование и операционные системы реализующие стандартные сетевые технологии?
Как кратко записать маску 255.0.255.0? Например, 255.255.255.0 получаем маску /24, а в вашем случае какая краткая маска получится?
Те ваш бэк коннект фактически эквивалентен пробросу порта на фаере и фильтрации подключений на конечных хостах?
С точки зрения функционала — да.
С точки зрения безопасности, вариант с межсетевым экраном шлюзового типа (железка то есть) проигрывает, потому как для описания правил фильтрации используются IP-адреса, а они могут быть подменены с помощью IP-spoofing. В тоже время применение локального межестевого экрана в технологии back connect лишено указной проблемы, поскольку он настраивается на фильтрацию в криптографически защищенном соединении (туннеле), в котором не возможна подмена данных.
На практике, back connect следует применять, только там где передается информация особой важности, например передача трафика содержащего аутентификационную информацию, или сведения о переводах денежных средств или управляющие воздействия автоматизированных систем управления технологическими процессами (АСУ ТП).
Более приземленным вариантом может быть защита взаимодействия RO DC c полнофункциональными контролерами домена. В некоторых схема high-security все пользователи авторизуются всегда через RO DC, а администрирование происходит на глубоко спрятанных полнофункциональных контролерах.
Те сам по себе EOL, без известных проблем, не проблема?
Проблема. И заключается она в том, что уязвимости в нем не публикуются, хотя это вовсе не значит что их нет. Пример Windows XP.
А вот это хороший вопрос. Проблема в том, что сетевая служба ожидающая подключение по порту может содержать уязвимости в коде и быть атакована Нарушителем.
Это можно проиллюстрировать на примере с Heartbleed уязвимостью и Web — приложением проводящим авторизацию на примере форм (Web выбран в только в качестве примера, аналогичная схемы может быть актуальна и для других сервисов).
Здесь неуполномоченные пользователи «отсекаются» авторизацией Web-приложения и вроде бы сервис защищен, но Нарушители могут атаковать непосредственно саму сетевую службу (в данном случае ее компонент — OpenSSL). Дабы не бороться с каждой подобной уязвимостью технология back connect позволяет закрыть сам канал атаки.
Почему вы считаете что EOL сетевого оборудование сам по себе проблема?
Наиболее понятным примером будут ошибки в BMC серверов, для которых нет патчей (не в природе, а для данной модели сервера) и из-за которого приходится этот функционал отключать.
Мы с вами рассуждаем о межсетевых экранов разного типа (поколения).
То что вы говорите — это пакетный фильтр, который принимает решение о транзите трафика только на основании данных заголовков.
В статье и моих коментах я оперирую правилами межсетевых экранов работающих с анализом состояния (stateful firewall) В них правила фильтрации помимо адресов учитывают состояния например new, established, invalid,… примером межсетевого экрана подобного класса является iptables. Поэтому при описании правил и применялась фраза — «разрешить инициацию соединений из внутренней сети в DMZ».
Оба типа межсетевых экранов применяются на практике. Пакетные фильтры используются на магистралях, где важна скорость. Statefull применяются на уровне сегментов корпоративных сетей, где важна защита от обхода с помощью фрагментации
В случае заражения АРМ внутри сети он всё равно сможет долбить сервер в локалке, поскольку ему разрешено с ним работать, либо не сможет потому что у него туда доступа нет, тут туннели вообще не причём.
Back connect — технология защиты межсерверных связей. Пример ее использования — связь с сервера приложений (того, что обслуживает клиентов) с сервером баз данных. Сервер БД в данном случае будет инициатором построения туннелей и соответственно не будет иметь открытых портов by design. Почему это важно?
На практике, случаются случаи когда на защиту с помощью сетевых устройств нельзя положится на 100%. Это могут быть случаи когда:
сетевые устройства не находится на поддержке производителя и не обновляются,
сетевые устройства управляются на аутсорсинге
квалификация администраторов недостаточна высока.
Другим примером ее использования обеспечение второго контура безопасности для защиты особо важных данных. Про актуальность этих задач можно посмотреть тут.
А в чем координальное отличие? Вместо CSP будет требоваться OpenSSL, один cliet-side софт меняется на другой.
Утверждать что OpenSSL более безопасный чем тот же КриптоПРО CSP считаю не корректным. Надо сравнивать по моделям угроз и ТЗ систем для которых применяется СКЗИ.
В тоже время если вопрос в деньгах, то можно использовать бесплатный криптопровайдер VIPNET CSP или бесплатную версию КриптоПРО CSP (она становится таковой, когда заканчивается триал) правда у нее нет возможности формировать ЭП, можно только проверять.
Цель статьи как раз и было показать, что то ПО которое обычно продает УЦ не позволяет достичь тех характеристик, которые работники УЦ заявляют при продаже.
Отмечу, что рассматривается ситуация, когда нарушителю известны пароли и другая аутентификационная информация (например, брелки 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. Кроме это по мимо ключей УЦ вы наверняка еще пользутесь услугами дистанционного банковского обслуживания Интернет Клиент-Банк, а это отдельная песня.
Галкой «неизвлекамый» — вы наварено называете «не экспортируемый». Стоит отметить, что наличие данной галки — обрабатывается только СКЗИ. А это значит, что если ключевая информация доступна в обход СКЗИ (например, ключ хранятся на флешке или в реестре), то она может быть успешно скопирована не смотря на галку.
Таким образом, ответить на ваш вопрос о возможности копирования ключей, для которых стоит галка «не экспортируемый» можно следующим образом:
— Если к ключевой информации можно обратится в обход СКЗИ, то не смотря на эту галку их скопировать можно.
Применительно к токенам обходные маневры расписаны в статье
А по централизованной схеме, кто во что горазд.
У меня лично был опыт, когда при генерации ключа для ДБО ИКБ меня пустили за компьютер офицера безопасности Банка, ответственного за генерацию ключей, хотя в Банке я был впервые. Поэтому утверждать, что там делает УЦ по централизованной схеме это более чем смело.
А по поводу извлечения ключей — предлагаю просто попробовать. Возьмите (если у вас есть к ним доступ) ключи в вашей организации и попробуйте их скопировать :)
Я думаю после этого вы посмотрите на проблему под другим углом.
Когда писал статью, долго думал как назвать «токены с не извлекаемым ключом» по науке. Вы в своих статьях упоминаете термины «активный вычислитель» и др., на мой взгляд предлагаемые термины немного сложны для понимания не криптографам.
С другой стороны Функциональный ключевой носитель (ФКН) — сообщает базовые характеристики устройства:
— выполнение функций,
— хранение ключа.
Другое дело в том, что ваша реализации ФКН, возможно более продвинутая по сравнению с другими (ФКН от КРИПТО-ПРО, обеспечивает защиту канала связи между токеном и ЭВМ).
Таким образом термин ФКН на мой взгляд наиболее удачен в данном случае.
Давайте еще раз разберемся в чем разница между «не экспортируемым» ключом и «неизвлекаемым».
Например вы сгененрировали ключ и поставили галку что ключ неэкспортируемый. Что это значит? А значит это, то что средствами СКЗИ его скопировать не получиться. Но когда выполняется подпись документа, ключ с токена копируется в память ЭВМ, где обрабатывается криптопровайдером, Основной баг этой схемы в том, что ключ может быть похищен из ОЗУ.
Галочку что ключ «не экспортирумый» можно поставить и при генерации ключа на обычном токене, для этого необязательно покупть более дорогой токен с «неивзлекамым ключом».
Теперь рассмотрим неизвлекаемые ключи. В этой схеме ключи, хранящиеся на токенах никогда не подают в память ЭВМ все криптографические операции связанные с использованием ключа выполняются сугубо на токене. Таким образом ключ скоприровать невозможно.
В этом принципиальное отличие.
Суть статьи в том, что вы берете устройство — токен, заходите на сайт производителя, там везде токен с неизвлекаемым ключом это очень круто, безопасно и т.д. (с чем я согласен :)
Берете свое СКЗИ используете этот токен — СКЗИ работает, файлы подписываются, и у вас может сложится ложное мнение о том, что ваша схема — это схема с ФКН, но на самом деле нет.
Проблема в том, что описываемый в статье случай, это что-то из разряда ввода потребителя в заблуждение.
На примере JaCarta — http://aladdin-rd.ru/catalog/jacarta/gost/specification. В ней исползуется чип — http://pdf1.alldatasheet.com/datasheet-pdf/view/255626/ATMEL/AT90SC25672RCT.html
Про функционал не подскажу, этот вопрос лучше адресовать производителям токенов. Неплохая документация по токенам — http://dev.rutoken.ru/
В общем случае так сделать нельзя. Прикладное ПО (например, MS outlook) обращается к крипторафическим библиотека по какому либо стандартному интерфейсу, например MS CryptoAPI. Для того чтобы этот интерфейс был доступен и нужны криптопровайдеры. НО. Можно пойти по пути как сделал КриптоАРМ. Они умеют самостоятельно общаться с токеном, фактически реализуя встроенную криптобиблиотеку.
УЦ — обычно применяют распределенную схему генерации ключей. В данной схеме они ожидают от нас запрос на сертификат + подписанные бумажки, после получения которых они выпускают сертификат. Генерацию ключей и размещение их на носителях осуществляет пользователь.
Но когда вы «покупаете подпись», то вам скорее всего понадобятся СКЗИ и токены, вот здесь и проявляют себя продавцы в полную силу и начинают продавать то, что вам не надо.
Каким образом броадкаст пакет из одной подсети (10.100.10.0/24) попадает в другую (10.100.11.0/24)?
Как обратится к по MAC в другую IP-подсеть?
Вбить в конфиг и сохранить в файл или построить работающую сеть, использующую оборудование и операционные системы реализующие стандартные сетевые технологии?
Как кратко записать маску 255.0.255.0? Например, 255.255.255.0 получаем маску /24, а в вашем случае какая краткая маска получится?
С точки зрения функционала — да.
С точки зрения безопасности, вариант с межсетевым экраном шлюзового типа (железка то есть) проигрывает, потому как для описания правил фильтрации используются IP-адреса, а они могут быть подменены с помощью IP-spoofing. В тоже время применение локального межестевого экрана в технологии back connect лишено указной проблемы, поскольку он настраивается на фильтрацию в криптографически защищенном соединении (туннеле), в котором не возможна подмена данных.
На практике, back connect следует применять, только там где передается информация особой важности, например передача трафика содержащего аутентификационную информацию, или сведения о переводах денежных средств или управляющие воздействия автоматизированных систем управления технологическими процессами (АСУ ТП).
Более приземленным вариантом может быть защита взаимодействия RO DC c полнофункциональными контролерами домена. В некоторых схема high-security все пользователи авторизуются всегда через RO DC, а администрирование происходит на глубоко спрятанных полнофункциональных контролерах.
Проблема. И заключается она в том, что уязвимости в нем не публикуются, хотя это вовсе не значит что их нет. Пример Windows XP.
Довольно подробно описано тут.
А вот это хороший вопрос. Проблема в том, что сетевая служба ожидающая подключение по порту может содержать уязвимости в коде и быть атакована Нарушителем.
Это можно проиллюстрировать на примере с Heartbleed уязвимостью и Web — приложением проводящим авторизацию на примере форм (Web выбран в только в качестве примера, аналогичная схемы может быть актуальна и для других сервисов).
Здесь неуполномоченные пользователи «отсекаются» авторизацией Web-приложения и вроде бы сервис защищен, но Нарушители могут атаковать непосредственно саму сетевую службу (в данном случае ее компонент — OpenSSL). Дабы не бороться с каждой подобной уязвимостью технология back connect позволяет закрыть сам канал атаки.
Наиболее понятным примером будут ошибки в BMC серверов, для которых нет патчей (не в природе, а для данной модели сервера) и из-за которого приходится этот функционал отключать.
То что вы говорите — это пакетный фильтр, который принимает решение о транзите трафика только на основании данных заголовков.
В статье и моих коментах я оперирую правилами межсетевых экранов работающих с анализом состояния (stateful firewall) В них правила фильтрации помимо адресов учитывают состояния например new, established, invalid,… примером межсетевого экрана подобного класса является iptables. Поэтому при описании правил и применялась фраза — «разрешить инициацию соединений из внутренней сети в DMZ».
Оба типа межсетевых экранов применяются на практике. Пакетные фильтры используются на магистралях, где важна скорость. Statefull применяются на уровне сегментов корпоративных сетей, где важна защита от обхода с помощью фрагментации
Back connect — технология защиты межсерверных связей. Пример ее использования — связь с сервера приложений (того, что обслуживает клиентов) с сервером баз данных. Сервер БД в данном случае будет инициатором построения туннелей и соответственно не будет иметь открытых портов by design. Почему это важно?
На практике, случаются случаи когда на защиту с помощью сетевых устройств нельзя положится на 100%. Это могут быть случаи когда:
Другим примером ее использования обеспечение второго контура безопасности для защиты особо важных данных. Про актуальность этих задач можно посмотреть тут.