Привет хабр! Периодически обращаются ко мне разнообразные люди, причем, иногда с такими вещами, что даже как-то не по себе. Вот, например, вчера обратился товарищ с просьбой предоставить экспертное заключение о последней дате изменения файла.
Я, конечно, экспертное заключение сделал :) Прошито — пронумеровано, все в печатях — в судах такой подход любят. Но пока готовил это заключение встал в тупик — а как действительно доказать?
У любого файла есть как минимум 3 даты — время создания фйла, время последнего изменения и время последнего доступа. Эти даты никакой критики не выносят — используя обычный touch можно мгновенно поменять дату файла хоть на из далекого будущего.
Открыл файл HEX редактором, в разных файлах по разному, но как правило там есть запись хотя бы о дате создания файла. Но и в данном случае можно изменить эту запись, правда это чуть сложнее чем с touch :)
Есть еще, конечно, логи, но логи те же файлы, имея доступ к системе, можно делать все что угодно.
В общем сейчас думаю, что по идее никак не доказать время изменения файла, если это не специальный криптоформат или еще что-то в этом духе. Сегодня даже по ходу придумал идею — добавлять в файл метку, у которой были бы такие же функции, как примерно у полураспада углерода. То есть при создании создается метка с значением 100, которая уменьшается или увеличивается, в общем, не важно.
В общем, суть вопроса — как доказать время последнего изменения файла, причем чтобы доказательства принял разумный It-шник? Спасибо!
Подписанный файл автоматически будет содержать дату последнего изменения — т.к. чтобы изменить такой файл — его надо подписать. Если над подписанным файлом изменения проводились без подписи, то изначальная подпись теряется. Не знаю, правда, относится ли это к атрибутам ФС.
Атрибуты фала — вотчина файловой системы. Это раз.
Второе — Почти все DLP системы умеют мониторить объекты ФС и ведут историю состояний этих объектов. Если DLP сертифицирована — доказательство у вас есть на основании журнала изменений объекта. То же самое касается и вопроса о копиях файла. Первая копия = оригинал. С него начался отсчет версий — остальные = копии.
Но хочу заметить, что все это происходит без отрыва от ФС. Без фаловой системы, сам файл — информация, которая, чисто логически, не имеет ни каких атрибутов (возраста, цвета, темы, назначения, владельца и т.д.), эти атрибуты появляются тольок в рамках чего-то. Поэтому «привязка на местности» обязательна.
Любая временная метка упирается в достоверность часов по которой она сделана. Как определить что системные часы не были переведены?
Я лично приму только свидетельство третьей независимой стороны — вложение в мейл или архив.
Если пофантазировать, то при записи намагничивается определенный сектор, со временем он естественно немного размагничивается, как-нибудь замерить текущее намагничивание сектора и прикинуть сколько времени прошло с момента записи.
при записи намагничивается определенный сектор, со временем он естественно немного размагничивается, как-нибудь замерить текущее намагничивание сектора и прикинуть сколько времени прошло с момента записи
Бред, честно говоря. Как вы себе представляете подобные измерения?
Совпадение с версией файла сохраненной на внешнем незаинтересованном и доверенном источнике.
Например вложение в письмо на гмейле с отметкой о дате получения сервером.
подвариант с 3-ей стороной, + заранее — это понятно. Просто довольно не очевидная вещь открылась мне — я и не думал, что в этом плане настолько все не продумано. Хотя с другой стороны, кому это надо? Точное время файлов.
Пост-фактум и не рассчитывая на будущую необходимость доказательства — никак в общем случае.
Все остальное, кроме третьей стороны (допустим, доверенной) можно подделать. В некоторой степени можно доверять меткам времени на «внезапно изъятом» носителе.
Как вариант, условный сертифицированный сетевой сервис цифровой подписи с меткой времени. Который не имеет другой функции, кроме третьей стороны в спорах о возрасте файла.
Ну если ежедневно логи со списком файлов и их данными будут записываться на dvd-r, думаю это можно считать неплохим доказательством. Только если известно, что заранее никто не знал, какой именно файл и когда заинтересует следствие, и не менял у него дату специально для логов или в самих логах.
Журналируемая ФС, каждый элемент журнала подписывается цифровой подписью пользователя. Так можно исключить подделку времени третьими лицами. Чтобы исключить подделку времени самим пользователем, отправлять хеш файла на сервер, который будет удостоверять модификацию файла своей подписью: «ID системы такой-то, файл такой-то, хэш изменений (или хэши файла до/после) такой-то, дата, время, цифровая подпись».
Без привлечения третьей стороны и использования физических методов (радиоактивные метки, саморазмагничивающиеся HDD...) — боюсь, что никак.
Задним числом, по уже существующим файлам — точно никак.
А кто сказал, что будет легко? За возможность сбора доказательной базы платим сложностью и скоростью работы. И потом, мне кажется, такую систему надо не к ФС прикручивать, а к базам данных или VCS. Не удивлюсь, если готовые решения уже есть.
По большому счёту это зависит от типа файла и окружения, в котором он был найден. Где-то можно найти дополнительные метаданные, где-то — ссылки, примерно подтверждающие, что файл был создан в определённой программе в течение какого-то промежутка времени. Не стоит также забывать про временные и удалённые файлы (особенно это касается различных документальных форматов).
В файловой системе NTFS временные атрибуты файлов содержатся в файловой записи для каждого файла в главной файловой таблице (MFT). И как ни странно у файла их ровно 8!, а не 3 как мы привыкли. За временные атрибуты отвечает две структуры $STANDARD_INFORMATION и $FILE_NAME, каждая из которых содержит: дату и время создания файла, последнего изменения файла, последнего доступа к файлу, а также дату и время последнего изменения сведений в файловой записи. Правильная оценка временных атрибутов из структур $STANDARD_INFORMATION и $FILE_NAME дает возможность правильно восстановить хронологию событий и понять когда и как менялись параметры
