что если между двумя проверками бинарное содержимое файла не изменилось
Оно должно изменяться всегда. В кусте SYSTEM, например, при каждой загрузке создается ссылка на выбранную конфигурацию в виде непостоянного ключа, информация о котором записывается в постоянный ключ и обновляется на диске. И так происходит со времен Windows NT 3.1.
У кого-то не проверяется правильность сортировки ключей реестра в записях li/lf/lh/ri. Это значит, что список ключей, «видимый» АМДЗ, может отличаться от списка ключей после монтирования куста в Windows (Windows удалит все ключи, нарушающие порядок сортировки). Еще могут не проверяться ссылки на родительские ключи, что может привести к тому, что Windows удалит деревья ключей с неправильными ссылками при подключении куста (а в АМДЗ такие деревья будут считаться корректными). И так далее, список большой.
и даже контролирует журнал транзакций NTFS (это тоже файл)
$LogFile или TxF? Если что-то одно, то не годится :-)
— АМДЗ применительно к СКЗИ это, конечно, бред. но в связке с СЗИ от НСД тот же SecretNet (да, да в котором дыру нашли, и за обновление формуляров которого на патченую версию, разрабы попросили 25% от стоимости) вроде как работает неплохо. т.к. работает драйвер на уровне системы уже и все нюансы ФС должен нормально учитывать…
Перед передачей управления программному СЗИ надо бы проверить целостность этого СЗИ и целостность его конфигурации, что уже создает проблемы.
— по поводу UEFI мне тоже кажется что с его(?) приходом все эти АМДЗ стали очень сильно неактуальны, при этом в банке угроз ФСТЭК угроз с изменение кода BIOS достаточно много и как от этого защищаться (на бумаге есс-но) кроме как установкой АМДЗ не очень ясно.
Тут можно многое написать, но это уже не совсем по теме обсуждения будет :-)
До недавнего времени и я занимался разработкой АПМДЗ (писал как раз OptionROM для UEFI)… И тоже могу с уверенностью сказать, что коллизии контроля целостности возникают из-за выбранных алгоритмов (в интернете достаточно статей про коллизии CRC16/32).
Речь не об ошибках в алгоритмах расчета контрольных сумм в частности и не о стойкости хеш-функций вообще. АМДЗ, в случае с Windows, должен поддерживать NTFS и реестр (это самый минимум). Вот только никто досконально изучать драйвер NTFS и ядро Windows для реализации такой поддержки не будет, а значит могут существовать (и существуют) случаи, когда собственная реализация NTFS и реестра «видит» одни данные, а Windows – другие. Потому что формат данных закрыт и представление о нем было неполным или ошибочным.
Поэтому не стоит нас с вами (видимо обладающих специальными знаниями и опыт в соответствующей области) и описанные Вами способы компрометации АПМДЗ приравнивать к знаниям и возможностям «нарушителя Н2».
Не буду спорить :-) Но тогда встает вопрос об адекватности выбора модели нарушителя.
В современных операционных системах данные могут быть в довольно сложной форме представления, нет никакой гарантии, что предзагрузочный контроль целостности АМДЗ «увидит» то же самое, что «увидит» и сама операционная система после передачи ей управления. Где гарантии, что в АМДЗ такой же, с позиции алгоритмов обработки данных, драйвер файловой системы, что и в Windows? Я занимался обратной разработкой ПО для контроля целостности в Аккорд-АМДЗ (на базе ACDOS и на базе Linux: AMDZ-NG) и могу смело сказать: можно изменить данные так, что контроль их целостности пройдет, но для операционной системы это будут другие данные, потому что «кривой парсер» закрытого формата в АМДЗ не учитывает некоторые состояния данных, которые учитывает операционная система.
А уж с приходом UEFI возможности по контролю расширились)
Наоборот. Например, в некоторых реализациях UEFI возможна загрузка с USB-накопителя после того, как управление будет передано менеджеру загрузки Windows. А вот еще доклад ОКБ САПР.
Так что, чтобы оспорить качество сертифицированных продуктов, необходимо еще соответствующие условия создать.
Одним из требований к средствам УЦ для класса КС2 является контроль целостности программных средств. Собственно, аппаратные модули доверенной загрузки могут контролировать целостность данных только в операционных системах не сложнее DOS.
Токены с неизвлекаемыми ключами позиционируются именно как защищенные от извлечения ключа вредоносной программой. Атаки на аппаратную часть (например, ПЭМИН) здесь на заднем плане. Но утечки через оперативную память тут в самый раз.
Граждане Российской Федерации и постоянно проживающие в Российской Федерации лица без гражданства, совершившие вне пределов Российской Федерации преступление против интересов, охраняемых настоящим Кодексом, подлежат уголовной ответственности в соответствии с настоящим Кодексом, если в отношении этих лиц по данному преступлению не имеется решения суда иностранного государства.
И еще часть 3, на всякий случай:
Иностранные граждане и лица без гражданства, не проживающие постоянно в Российской Федерации, совершившие преступление вне пределов Российской Федерации, подлежат уголовной ответственности по настоящему Кодексу в случаях, если преступление направлено против интересов Российской Федерации либо гражданина Российской Федерации или постоянно проживающего в Российской Федерации лица без гражданства, а также в случаях, предусмотренных международным договором Российской Федерации, если иностранные граждане и лица без гражданства, не проживающие постоянно в Российской Федерации, не были осуждены в иностранном государстве и привлекаются к уголовной ответственности на территории Российской Федерации.
Там обязанность предоставить доступ обращена к человеку, чьи данные им же и зашифрованы. В нашем случае обязанность обращена к лицу, которое шифрует сообщение другого лица.
Для оценки эффективности средства защиты информации нужно выбрать модель угроз. Или хотя бы определиться с тем, от кого мы защищаемся. И если мы защищаемся от злобного регулятора, то и оценивать нужно те свойства средства защиты информации, которые позволяют прикрыть пятую точку, то есть наличие сертификатов, формуляров и так далее. В противном случае, если модель угроз не была выбрана правильно, то, скорее всего, будут неверными и критерии оценки средства защиты информации. Вот какое отношение к защите от злобного регулятора имеет отсутствие контроля за чтением потоков NTFS? Никакого!
А как же поддержка журналирования? Ее в ntfs-3g нет вообще. Восстановление «грязной» файловой системы из журнала в ntfs-3g заключается в стирании журнала и в выводе сообщения о том, что все стало хорошо.
Другой проблемой является то, что все «свободные лицензии» разработаны за рубежом и, соответственно, составлены на английском языке. Договор, составленный на английском языке, по сделке, совершённой на территории Российской Федерации, скорее всего, будет признан недействительным. Однако если этот договор является международным, лицензиар является иностранным физическим или юридическим лицом, а лицензиат — российским, вступают в действие нормы ст. 1211 ГК РФ, в соответствие с которыми, к такому договору применяется право страны, «где находится место жительства или основное место деятельности» лицензиара.
Есть среди юристов и другие, более «свободные» точки зрения.
Под переработкой (модификацией) программы для ЭВМ или базы данных понимаются любые их изменения, в том числе перевод такой программы или такой базы данных с одного языка на другой язык, за исключением адаптации, то есть внесения изменений, осуществляемых исключительно в целях функционирования программы для ЭВМ или базы данных на конкретных технических средствах пользователя или под управлением конкретных программ пользователя
А в статье 1280 ГК РФ есть такой текст:
внесение в программу для ЭВМ или базу данных изменений исключительно в целях их функционирования на технических средствах пользователя
То есть в статье 1280 ГК РФ есть фраза, полностью соответствующая определению адаптации из статьи 1270 ГК РФ.
А смысл? Там вы не привели ни одной соответствующей цитаты из кодекса.
В примере мало технических деталей, имеющих юридическое значение. Например, если пользователь загружает интернет-страницу, то это не является юридическим использованием веб-сервера, который эту веб-страницу обслуживает, а потому возможны ситуации, когда сервер-«черный ящик», предоставленный заказчику исполнителем, используется заказчиком, но при этом заказчик никак не использует программное обеспечение этого сервера (а использует это программное обеспечение исполнитель, в частности, во время конфигурации сервера). Вот тут эта тема затрагивалась.
Оно должно изменяться всегда. В кусте SYSTEM, например, при каждой загрузке создается ссылка на выбранную конфигурацию в виде непостоянного ключа, информация о котором записывается в постоянный ключ и обновляется на диске. И так происходит со времен Windows NT 3.1.
У кого-то не проверяется правильность сортировки ключей реестра в записях li/lf/lh/ri. Это значит, что список ключей, «видимый» АМДЗ, может отличаться от списка ключей после монтирования куста в Windows (Windows удалит все ключи, нарушающие порядок сортировки). Еще могут не проверяться ссылки на родительские ключи, что может привести к тому, что Windows удалит деревья ключей с неправильными ссылками при подключении куста (а в АМДЗ такие деревья будут считаться корректными). И так далее, список большой.
$LogFile или TxF? Если что-то одно, то не годится :-)
Перед передачей управления программному СЗИ надо бы проверить целостность этого СЗИ и целостность его конфигурации, что уже создает проблемы.
Тут можно многое написать, но это уже не совсем по теме обсуждения будет :-)
Речь не об ошибках в алгоритмах расчета контрольных сумм в частности и не о стойкости хеш-функций вообще. АМДЗ, в случае с Windows, должен поддерживать NTFS и реестр (это самый минимум). Вот только никто досконально изучать драйвер NTFS и ядро Windows для реализации такой поддержки не будет, а значит могут существовать (и существуют) случаи, когда собственная реализация NTFS и реестра «видит» одни данные, а Windows – другие. Потому что формат данных закрыт и представление о нем было неполным или ошибочным.
Не буду спорить :-) Но тогда встает вопрос об адекватности выбора модели нарушителя.
В современных операционных системах данные могут быть в довольно сложной форме представления, нет никакой гарантии, что предзагрузочный контроль целостности АМДЗ «увидит» то же самое, что «увидит» и сама операционная система после передачи ей управления. Где гарантии, что в АМДЗ такой же, с позиции алгоритмов обработки данных, драйвер файловой системы, что и в Windows? Я занимался обратной разработкой ПО для контроля целостности в Аккорд-АМДЗ (на базе ACDOS и на базе Linux: AMDZ-NG) и могу смело сказать: можно изменить данные так, что контроль их целостности пройдет, но для операционной системы это будут другие данные, потому что «кривой парсер» закрытого формата в АМДЗ не учитывает некоторые состояния данных, которые учитывает операционная система.
Наоборот. Например, в некоторых реализациях UEFI возможна загрузка с USB-накопителя после того, как управление будет передано менеджеру загрузки Windows. А вот еще доклад ОКБ САПР.
Одним из требований к средствам УЦ для класса КС2 является контроль целостности программных средств. Собственно, аппаратные модули доверенной загрузки могут контролировать целостность данных только в операционных системах не сложнее DOS.
Я так понимаю, что часть защитных мер осталась родом из мира DOS.
И еще часть 3, на всякий случай:
Сделать поддержку журналируемой файловой системы без поддержки журналирования при записи – это не очень хорошо.
А вот, что пишет Середа С. А.:
Есть среди юристов и другие, более «свободные» точки зрения.
А в статье 1280 ГК РФ есть такой текст:
То есть в статье 1280 ГК РФ есть фраза, полностью соответствующая определению адаптации из статьи 1270 ГК РФ.
Все необходимые ссылки я приводил и не один раз.
В статье 1280 ГК РФ написано иначе, а закон имеет приоритет перед лицензионным договором.
Адаптация не является модификацией (переработкой).
Перечитайте, пожалуйста, предыдущие сообщения.
На этом все.