Если это то о чем я думаю (критерий по которому определяется целостность контейнера), то значение хэш-функции включает в себя только header.key и меняется, например, при установке сертификата (и сертификатов УЦ) в контейнер, при удалении даты действия и т.д. Таким образом, записывать его в журнал немного проблематично, что-то изменится и уже не докажем что это был именно тот контейнер.

В принципе больше бы подошло поле "Идентификатор ключа субъекта" из сертификата (это хэш от блоба открытого ключа если не ошибаюсь). Если на тот же открытый ключ выпустить еще один сертификат, то идентификатор будет такой же, но номер сертификата другой. Поэтому наверно более корректно использовать идентификатор чем серийный номер сертификата. Минусы: 1) это хэш SHA-1, не гост; 2) длина хэша 20 байт, многовато.

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

Начинал журнал по рекомендациям УЦ ФК и сайта sedkazna, там рекомендовали просто записать номер сертификата. В те времена старый УЦ ФК выдавал номера сертификатов из трех байт (вроде 22 33 44) и это правда было проще. Причем если номер длинный, то рекомендовали записать несколько (4-6) шестнадцатиричных цифр из начала номера, многоточие, несколько (6-4) цифр из конца номера. Сейчас все номера сертификатов аккредитованных УЦ стали длинными и преимущества в длине у номера нет: длина идентификатора 20 байт, попадавшаяся длина номера в сертификатах разных УЦ от 16 до 28 байт.

Не спорю, идея хорошая в теории, но не все так просто, как хотелось бы.К сожалению, у меня нет уверенности, что значение header.key не изменится в дальнейшем (даже если все действия провести сразу). Причина - криптопровайдер требует доступа на запись к контейнеру, это касается как реестра, так и флешек и жестких дисков. По факту, если сразу установить сертификат в контейнер, сделать копию папки Проводником, а через некоторое время посмотреть даты файлов на "рабочей" флешке у пользователя и на резервной флешке, то на рабочей флешке даты некоторых файлов будут позднее. Честно говоря, не вижу почему name.key может измениться, все же нет штатного способа переименовать контейнер, можно только скопировать с новым именем. Возможно только пользователь откроет его в редакторе и поменяет. В сравнении выше, обычно дата name.key не меняется, а вот primary-mask меняются. Предположу, что закрытый ключ время от времени перешифровывается с другим случайным числом.

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

Отредактировано пользователем 26 ноября 2019 г. 10:03:28(UTC)  | Причина: Не указана