Провайдер отзыва сертификатов

Общее

Я тут не буду растекаться мыслью по древу, объяснять, что такое CRL.  Если Вы этого не понимаете, значит, Вам это не надо. Тем же несчастным ублюдкам, которые нырнули в мутное болото CryptoAPI, я посвещаю свой рассказ…

Отзыв

В PKI X509 самое узкое место – отзыв.  Работа механизма отзыва в Windows  довольно мутная тема, документация туманна.  Экспериментальным путем установлено, что на факт признания OS отзыва сертификата влияют следующие вещи:

1. Так называемый кеш отзыва – какие-то там файлы, размещенные в \Document and Settings\Username\Application Data\Microsoft\CryptnetUrlCache\Methadata
   
2. CRL, размещенный локально – в Хранилище “Промежуточные УЦ”
3. CRL, доступный по CDP – CRL Distibution Points. В сертификате указываются пути через SMB, HTTPS, LDAP и пр.
4. Активность так называемых провайдеров отзыва, например OCSP

Работает эта вся хреновина примерно так: Серт пробивается по кешу. Если в кеше ничего нет – по локально установленным СОС (CRL).  Если их нет, управление передается провайдеру отзыва по умолчанию (вставить путь в реестре и имя dll). Оный же злокачественный провайдер лезет по CDP, указанным в проверяемом сертификате, и пробует скачать свежеприготовленный CRL оттуда. Получив означенный, пробует пробить проверяемый сертификат по нему. Если CRL недоступен, и больше провайдеров нет, пишет – статус не определен. Если другие провайдеры зарегистрированы – управление передается им. Не ручаюсь за точность последовательности. Во-первых, она меняется от версии Windows и сервис-пака, во вторых, в самом MS, наверно, уже забыли, как оно работает. В этой теме секут ребята из Крипто-Про и вот я. На MSDN всего 2(!) ссылки по теме, правда, довольно дельных…

Зачем оно надо

А затем. Вы написали софт для работы с закрытой информацией. Удостоверяющий центр у Вас вообще не подключен к сети (что правильно),а  CRL таскают на флешках.  Доступа в ИНЕТ нет вообще.  В общем, CDP недоступны.  Каждый раз проставлять CRL всем абонентам или на серверную ферму из 89 стоечных единиц очень напряжно. Поэтому есть фирменные провайдеры, которые поддерживают OCSP, которые содержат собственно провайдер отзыва, регистрируемый на каждом сервере, и серверную часть.  Вы можете воспользоваться этим решением, но, господа, не бесплатно. Не бесплатно!

Протоколы

Протоколов, помимо OCSP, масса. Первый протокол был бинарный, с использованием навоза ASN1.DER. Использование ASN1 не прибавляет конструкции ни простоты, ни защищенности. Дня, наверно, не проходит, чтоб его не натянули…Крайне неудачный формат, кто ж так обкурился, что такую байду заверстал…

Короче. Наплевать какой протокол Вы там гоняете между провайдером и ответной серверной частью. Я, например, гоняю ErlTlv – протокол бинарных термов Эрланга. Non compliant? Конечно. Без разницы мне. У меня корпоративная система, что хочу, то и прикручу.

Что есть провайдер

Провайдер, дети мои, как легко догадаться, суть DLL, регистрируемая в особом разделе реестра. Означенная DLL экспортирует одну функцию.Провайдеры регистрируются по стековому принципу. Где у стека голова, я, правда, так и не понял…

Функция принимает указатель на вагон параметров. Среди них важных два – количество сертификатов, подлежащих пробитию по CRL, и массив указателей на них. В 99% случаях Windows дергает DLL по одному серту за раз. WinVerifyTrust может дернуть пачкой. Ладно. Факт тот, что Вас дернули за пипу – проверяйте!

Функция должна закончить работу, вернуть FALSE и выставить SetLastError на том серте, на котором произошел первый облом. Там еще индекс передается, причина, в общем, их тоже выставить.  Windows понимает следующие типы обломов:

CRYPT_E_REVOKED – сертификат был отозван

CRYPT_E_REVOCATION_OFFLINE – до сервера не достучаться, или внутренняя ошибка.

CRYPT_E_NO_REVOCATION_CHECK – сертификат не вашей системы, вы не хотите его проверять, вы не можете его проверять, в общем, отдать следующему в цепочке провайдеру (например – стандартному).

Там еще парочка каких-то мутных флагов, как они действуют,я не понял.

Моя реализация

Статус: в процессе тестирования. Язык реализации – плоский C. Внутренний протокол – Erl TLV. Клиент-сервер, CRL’ы загружаются тупо в папочку на сервере.  Отдам за доброе слово (обращаться по адресу : killy@newmail.ru), если захотите.

Советы разработчикам

Для успешного написания, а главное, испытания своего провайдера рекомендую:

• На период тестирования заглушить все УЦ, убрать их из сети, поджечь и выбросить
• Регулярно очищать локальные файловые кеши
• Локально установленные CRL убрать.
• В функции построения цепочки выставлять параметр – таймаут доступа к CDP. Тогда стандартный провайдер по-быстрому обломиться, и управление передадут Вам.
• Сертификаты корневых УЦ обычно не отзывают:) Проверяйте передаваемый серт на self-signed.
• Анализируйте принадлежность серта к вашей системе – по OID’ам, политике, куску имени, в общем, проявите фантазию. Если серт не ваш, скажите системе об этом.

В общем, happy coding, регарды, peter631…

З.Ы.

Ссылочки.

• Провайдеры отзыва, общее
• Флаги и их значение

Компьютерная безопасность – это обман

Компьютерная безопасность, особенно коммерческая – это сплошное надувательство.  Просто поразительно, каких здоровенных слонов господа секрьюрити-писатели умудрились проебать (извиняюсь, но другого слова нет) - http://www.securitylab.ru/analytics/386285.php

SSL вроде как призван защищать компьютеры и соединения, а не служить источником уязвимостей. Очевидно, плохие ребята знают про эту хрень давно и давно ее эксплуатируют. Защищались-защищались. Покупали сертифицированную криптохрень…На тебе…

Юзать open-source выходит не так накладно – ничего не платишь, похакали, так и не обидно…

Скоро доживем до того, что в Сеть носа будет высунуть нельзя без того, чтоб тебя кто-нибудь не отымел…

Мда. Что день грядущий нам готовит?

Испытания компьютерной безопасности

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

- Мы поставим новые PIX’ы…Новый антивирус Касперского…Нет, Zone Alarm на каждую рабочую станцию…Политикой домена, политикой домена будем давить…

- Коллеги!! – кричу – все это, поставить можно. Только надо будет все это ИСПЫТАТЬ!!!

Удивленные взгляды. Что испытать? Сертифицированные средства? Да вот же бумага, где написано: гарантия! Касперского будем испытывать?

-Нет, сцуко, коллеги !!! Мы будем испытывать, насколько криво Вы все это мы настроили.

Нач.ИТ: – Вы не доверяете нашему профессионализму? Это оскорбительно!

Я: Дорогие коллеги !(разрешите мне, мля, вас так называть).  Вашему дутому профессионализму я, конечно, ни хрена не доверяю, ибо такового не увидел. Раз уж наняли консультанта – извольте выслушать мое мнение. По пунктам:

• Вы покупаете, настраиваете все это дерьмо, о котором тут трындели;
• Мы подписываем контракт на исследования, где написано, что ко мне не будет исков в случае нанесения ущерба (каковой, очевидно, будет)
• Я взламываю вашу офигительно стойкую сеть, выпускаю учебно-тренировочные вирусы, натравливаю  безопасных сетевых червей, грохаю контроллеры доменов и поджигаю УПСы, сверлю дыры в файерволах и вообще хулиганю.
• После чего мы, совместно, разбираем полеты: какова эффективность защиты? как быстро реагирует служба безопасности (вообще нет таковой? А, охранники только…Печально…)
• Вы оплачиваете мне издержки $$$$$$$$$$$$$$$$$

Идет? Что молчите, нах?

Долгое молчание. В тишине шепот: Кто пригласил сюда этого…этого… сумашедшего…хакера…бандита…

Занавес.

Непонятный P.S.

Исследователи островов тропической части Тихого океана как-то нашли одно странное племя. Дикари как дикари. Но был у них один прикольный обычай. Главарь брал кость в руки и кричал в нее. Остальные бегали с раскинутыми руками, махали двумя палками и приседали, в общем физкультурой разной занимались. Исследователи долго охреневали, потом оказалось, что не так давно на острове стоял американский военный аэродром. А дикари просто копировали жесты диспетчеров и наземной команды…

Юридическое признание компьютерных журналов (логов)

На самом деле никакой официальной позиции на этот счет нет, поэтому я просто попытаюсь в письменном виде порассуждать на эту тему.

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

•  Логи, как электронный документ, не могут быть юридически признаны без ЭЦП;
•  ЭЦП действительна при наличии доказательств факта ее наложения
•  ЭЦП предполагает наличие криптосредств, более того – сертифицированных криптосредств. Программное обеспечение, содержащее сертифицированные криптосредства, должно проходить аттестацию и исследование на корректность встраивания СКЗИ.
•  Криптосредства (СКЗИ) должны работать в доверенной среде – на защищенном по требованиям органов компьютере, со специальным ПО (и хардом), контролирующим целостность криптосредств и пр. (Минимально – электронный замок)
•  Закрытые ключи должны находиться на отчуждаемом носителе.
•  Запись лога должна содержать высокоточную отметку времени, полученную из внешнего источника, недоступную для модификации. В идеале на запись лога накладывается криптографическая отметка времени (см. TSA, RFC такой-то).
•  Помимо указанных мер, доступ к ключу должен иметь ограниченный круг лиц.
•  Внутри системы, доступ к ключу должен регулироваться матрицей доступа.
•  Лог-файл (файлы) должны быть объектом матрицы доступа.
•  Машина (компьютер) с логом должны стоять в охраняемом помещении.
•  Формат данных лога должен допускать проведение экспертизы (проверки отметки времени, подписи данных, проверки сертификатов подписи и пр.)

 После этого мы можем говорить, что да, наверно, этим логам можно доверять, поскольку маловероятно, чтобы владельцы системы и нарушитель вступили в преступный сговор. Если факты свидетельствуют о возможном сговоре, то при соблюдении вышеуказанных условий круг подозреваемых сужается. Также, в указанном случае имеет место корректность изъятия логов – эксперт не сможет изменить данные, поскольку не обладает доступом к секретному ключу.

Юридические аспекты применения электронно-цифровой подписи

Слабость современных законов об ЭЦП

 Несмотря на очевидную необходимость применения электронно-цифровой подписи в современном мире, дело продвигается с большим трудом. В США электронно-цифровая подпись признается только в некоторых штатах, да и то с оговорками. В России закон об ЭЦП откровенно слаб (и в техническом и в юридическом аспектах) и не может быть применен. Я читал драфт (модельный закон) об ЭЦП, выпущенный в 2007 году, но он ничем не лучше действующего. Европейская директива CADES существенно лучше, но она тоже ничего не раскрывает по существу дела. Хотя если ее принять у нас, то, конечно, это  улучшит положение. Как практикующий специалист в области практической криптографии я остановлюсь на ряде моментов, которые представляются мне важными и которые либо не отражены, либо слабо отражены в российском законодательстве.

 Апостиль

 Несмотря на кажущиеся различия между законодательствами разных стран, юридическая практика, унаследованная нами от римского права, везде схожа. Людям всегда требуется одно и то тоже: регистрация сделок, признание и расторжение брака, наследство, права собственности и прочее. В современном мире, для которого характерна массовая и постоянная миграция людей, глобализация всех процессов, требуются универсальные механизмы признания  юридических документов, оформленных в одной стране, на территории другой страны. Поскольку документы на иностранном языке ничтожны (не действительны), так как официально Вы не можете их прочесть и соответственно принять решение, требуется особая юридическая процедура признания документа. Для некоторых типов документов, например для доверенностей, на территории стран-участниц Конвенции, документы, оформленные на территории других стран признаются при наличии специального защищенного от подделки штампа и документа к нему, называемого апостиль. Апостиль и заверяемый им документ могут быть официально переведены и имеют юридическую силу.

В юридическом смысле аналогичная ситуация имеет место и с ЭЦП. Самый спорный момент – это момент наложения пользователем ЭЦП на документ, представленный в электронном виде. Бинарный (машинный) формат документа не может быть понятен пользователю. Соответственно, подпись, наложенная на бинарный документ – ipso facto – юридически незначима! Следовательно, ЭПЦ должна быть наложена на текстовое представление документа, которое безусловно необходимо показать пользователю перед моментом подписания. После подписания документ не может быть изменен. Как вариант, бинарный формат документа должен быть сертифицирован и должен существовать также сертифицированный экземпляр конвертера этого формата в текстовую форму и обратно. XML и соответствующий стандарт подписания неплохой кандидат на юридически признаваемую форму документа.

 Свидетельства

 Когда мы подписываем серьезный юридический документ, нам нужна гарантия признания его государством, чтобы иметь страховку на случай дальнейших споров и судебного разбирательства. Суд обязательно спросит: действительно ли имело место подписание этого документа? Был ли подписан именно этот документ именно этим лицом и в указанное время? Для доказательства этих фактов мы и отправляется к независимому свидетелю – нотариусу. Нотариус убеждается в подлинности лиц, подписей, непротиворечивости и законности договора и заверяет документ своей подписью и печатью (если предполагается перевод документа на другой язык – накладывает апостиль).

Для юридического признания ЭЦП нам, к сожалению, тоже нужен независимый свидетель. Иначе лицо, наложившее ЭЦП, может впоследствии отрицать факт подписания, сославшись на компьютерные вирусы, несовершенство системы измерения времени и прочие обстоятельства. В законе есть упоминание об этом, но по существу вопроса ничего не сказано.

Таким образом, необходимы технические средства, которые заверяют подпись документа с наложенной на него заверяемой ЭЦП. Это может быть сетевой сервер независимой компании или государственного учреждения, который накладывает поверх заверяемого документа свою ЭЦП, присоединив высокоточную отметку времени. Оригинальная подпись, разумеется, должна быть проверена. Технически это самый тяжело реализуемый момент. Ни в одной из существующих систем он не реализован целиком.

 Экспертиза

 Предположим, что конфликт все-таки произошел и лицо, наложившее подпись, официально, с суде, отрицает факт подписания документа, или, к примеру, отрицает время подписания. В этой ситуации суд обязан назначить проведение экспертизы технических средств и электронного документа. Производитель системы подписи обязан предоставить инструменты для такой экспертизы. Кроме того, документ должен иметь достаточно реквизитов, чтобы эта экспертиза была возможной. Минимально необходимый набор таков:

• 1. Сертификат открытого ключа лица, подписавшего документ и цепочка сертификатов, вплоть до корня, соотв. системы подписи;
• 2. Список отзыва, действительный на момент подписания документа;
• 3. Наложенная на подпись заверенная ЭЦП отметка времени и ее сертификат (и корень, если отличен от пункта 1)

 В ходе экспертизы эксперты должны предоставить суду доказательства того, что:

1. Сертификат подписавшего не был отозван на момент подписания и принадлежит подписавшему
2. Сертификат подписавшего действительно выпущен указанным центром (проверка цепочки)
3. Подпись документа верна
4. ЭЦП отметки времени верна. ЭЦП отметки времени содержит корректный сертификат, не был отозван на момент подписания и был выпущен указанным УЦ.

 Только при соблюдении указанных условий у нас появляется косвенное доказательство того, что документ был подписан, и причем в указанное время. Тем не менее, возможно, лицо подписавшее документ, действовало под принуждением. Также не исключен вариант, что лицо пало жертвой компьютерного вируса или программы-закладки, или программы удаленного управления, тайно внедренной на компьютер подписавшего. Ряд зарубежных систем ЭЦП имеют в своем техническом арсенале средство сигнализации “работаю под принуждением”, которое позволяет выявить этот факт при проверке. К сожалению, вопрос с вирусами остается открытым.

 Идентификационные данные

 Какого рода личные данные надо включить в сертификат, чтобы надежно удостовериться, что данный сертификат действительно принадлежит указанному лицу? Разумеется, никакие паспортные данные не могут быть гарантией. Надежную гарантию может предоставить только биометрические данные – отпечатки пальцев, фрагмент ДНК и пр. В настоящее время такие системы только начинают создаваться, и их успехи весьма скромны. Минимум такие системы являются дорогостоящими.

 Заключение

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

Режим секретности

Введение

Ровным счетом ничего секретного не сообщаю, излагаю самые банальные вещи. Но с практической точки зрения:)

Мандарторная модель безопасности, упрощенно

 Лениво мне описывать всю модель, идите на wikipedию и читайте про модель Бела-ЛаПадулы, мандаторный способ защиты  и прочее. Я изложу практический аспект.  Самые неприятности при построении информационной системы начинаются, когда некоторый тип данных является секретным. Никто не может его ни прочесть, ни исказить, не распечатать, ни переслать по каким-либо каналам. В общем, вот есть комната, охраняемая автоматчиками, и там терминал. Даже принтера нет. А если и есть, то выносить распечатки нельзя – дальше определенной зоны. И язык следует держать за зубами, или пуля в лоб. Вот так. Сложные условия.

Как делается.  Ряд определений. Контейнер. Это все, что содержит информацию – терминал (в том плане, что физическое устройство, с которого можно глазами данные считать), принтер, канал связи, носитель (а хоть бы и флешка). Данные – все, что эти сведения содержит. Субъект – разумное существо (и программа, выступающая от лица субъекта). И данным, и контейнерам, и субъектам приписываются так называемые метки безопасности. В простом случае – это просто число, характеризующее благонадежность субъекта, секретность данных или уровень доступа контейнера.  Метки сортируются по возрастанию (собственно, необязательно).  Правила просты:

1. Данные нельзя записать в контейнер, если уровень его метки ниже метки данных
2. Субъект может записывать (но не может читать) данные на более высокий уровень секретности.
3. Субъект может читать (но не записывать) на более низкий уровень секретности.

Таким образом, информация течет только в одном направлении – в сторону большой секретности. Рассекретить ее можно, но если с помощью специальных процедур. В теории это все ужасно просто выглядит. На практике за такую систему возмется штук от силы 5 контор на планете.

 Контейнеры – терминал

Как раз с ними самый большой проблем. Вот, скажем, терминал. Это необязательно старый СМ-овский или ЕС-вский терминал а в смысле клиентская программа, и выполняющий ее компьютер. Там где гриды, кнопочки и менюшки. Вопросы тут возникают такие:

1. Каков уровень доверия к данному терминалу? Какого уровня секретности материалы можно на нем показывать? И кому?
2. Как убедиться в том, что терминал не был физически перемещен? Злой предатель может подключить свой ноутбук к сети WiFi и используя свой легитимный логин, свистнуть секретные данные. Например, терминал уровня 0 стоит в охраняемой комнате. Пропускная система. Программа как-то должна определить, что имеет место с таким-то набором железа, а не с другим. Железо можно подмахнуть. Сами знаете как.
3. Вначале работы все терминалы нужно разметить. Какой какого уровня. Занести в базу данных (секретную) вместе с хардверным неизменяемым ID.
4. Также надо убедиться, что с этого терминала нельзя украсть данные. Нельзя подключить внешние накопители (неучтенные и неразмеченные), флешки там, и пр. Также надо убедиться, что по сети с этого терминала никуда, кроме сервера, нельзя попасть.

Контейнеры – принтер

С этим гемора еще больше. Как убедиться что принтер тот, за кого он себя выдает. Как обеспечить его ID ( и его безопасную передачу)? Вообще говоря, компания HP производит такие принтеры, но вывоз их за пределы США запрещен под страхом пожизненного заключения. Что делать-то? Паяем сами железку и вкрячиваем туда. Опять же, принтера надо разметить. Учесть, кто где стоит и какой уровень доступа может печатать.

Печатать просто так мы не можем. Этож секретные документы. Мы баннер должны сверху присобачить. Так и написать. под двумя Сережами. И еще баркод сверху, чтобы охранник на выходе, чирикнув по нему сканнером, убедился, что это документ правильный и распечатан легитимно. И в базе безопасности отметить. Такой-то тогда-то документик получил.

Контейнеры – носители

Тут вообще один сплошной ахтунг. Носители надо учитывать, но как? Как HardID неизменяемый на флешку запихать? Опять же данные шифровать надо, причем на каком-то общем для всего уровня безопасности ключе. Опять же (как в любом другом случае)  все это надо проверять…

 Контейнеры  – каналы передачи данных

Опять таки приятного мало. Но полегче. Там аутентификация, сертификаты, их кому попало выдавать не будем, будем HardID в оконечной железки в них записывать и пр. Полегче.

  А теперь – данные!

Вот тут, похоже, начинаются главные трудности. Как отбеспечить “неотрываемость” метки от данных, которые она отмечает? Вычислить совместный хеш? Хеш с секретом? Подпись? Кто будет менять эту метку? И как эту софтину (назовем ее Ядром Безопасности) контролировать? Чтобы не упала? Не отключилась? И через нее не свистнули данные?

Побочные каналы

Вот тут теория и дает сбой. Даже с высокого уровня секретности данные можно тихонечко украсть. И никто не заметит. В этот как раз и состоит главная трудность реализации мандаторной модели. Предположим – я плохой. У меня высокий уровень доступа и моим сообщникам потребовалась копия секретных данных. Мне надо ее выкрасть. Физически это сделать нельзя – все предусмотрено. Ладно. Обзаводимся помошником, пусть даже программным. Запускаем программного помощника на низком уровне хоть бы даже с какого-нибудь удаленного терминала. Помошник следит за 2 двумя файлами – файлом A и файлов B. И определяет, имеет ли к ним доступ кто-нибудь в данных момент. И регистрирует эти факты. Отлично. Я, сверху, тоже имею доступ к этим файлам. Сначала я читаю файл A. Потом B. Потом снова B. Сопоставим чтение файла A двоичной единице, а чтение B – двоичному нулю. Таким образом я кодирую всю секретную информациюю Потом мне остается только забрать данные у программы – помошника.

Побочные каналы могут быть крайне разнообразными.  Я могу включать и выключать мотор принтера, мигать лампочкой на низкоприоритетном терминале, в общем, надо проявить фантазию !!! А самое главное, что никакая теория меня не остановит.

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

Такие дела. Если попадется такой проект – знайте, я завидую Вам. Have fun.