Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

Опции
К последнему сообщению К первому непрочитанному
Offline OneLastgoodbye  
#1 Оставлено : 24 мая 2021 г. 16:02:58(UTC)
OneLastgoodbye

Статус: Новичок

Группы: Участники
Зарегистрирован: 24.05.2021(UTC)
Сообщений: 5
Российская Федерация
Откуда: Москва

Сказал(а) «Спасибо»: 3 раз
Добрый день!
Подскажите пожалуйста, возможно ли, перед импортом в систему ключевой пары, в виде рег файла, привести данные в читаемый вид средствами крипто про 4.0 или каким либо еще способом, не импортируя рег файл в реестр?

Конкретно задача выглядит следующим образом:
до импорта рег файла в систему, мне нужно вытащить поле "субъект" из сертификата, который содержится в рег файле.

Отредактировано пользователем 24 мая 2021 г. 18:40:53(UTC)  | Причина: Не указана

Offline two_oceans  
#2 Оставлено : 1 июня 2021 г. 7:20:20(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,602
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Добрый день.
Если имеется в виду контейнер, хранящийся в рег-файле, то теоретически возможно программно, но штатного способа нет.
Примерно так:
1) раскодирование данных регфайла (шестнадцатиричная запись байтов) в сами байты (параметр header.key);
2) в ASN1 структуре найти место, где хранится сертификат и скопировать содержимое сертификата. Точного описания не опубликовано, но подобрать место возможно;
3) в CryptoApi создать контекст сертификата из содержимого сертификата и запросить строку субъекта (смотря в какой среде программирования - возможны вариации).

Если просто для визуального оповещения, то наверно можно рег-файл преобразовать в контейнер на съемном диске (или считывателе "Директория") и приспособить csptest для вывода информации о контейнере, в том числе о сертификате.
thanks 1 пользователь поблагодарил two_oceans за этот пост.
OneLastgoodbye оставлено 05.08.2021(UTC)
Offline OneLastgoodbye  
#3 Оставлено : 5 августа 2021 г. 15:18:05(UTC)
OneLastgoodbye

Статус: Новичок

Группы: Участники
Зарегистрирован: 24.05.2021(UTC)
Сообщений: 5
Российская Федерация
Откуда: Москва

Сказал(а) «Спасибо»: 3 раз
Автор: two_oceans Перейти к цитате
Добрый день.
Если имеется в виду контейнер, хранящийся в рег-файле, то теоретически возможно программно, но штатного способа нет.
Примерно так:
1) раскодирование данных регфайла (шестнадцатиричная запись байтов) в сами байты (параметр header.key);
2) в ASN1 структуре найти место, где хранится сертификат и скопировать содержимое сертификата. Точного описания не опубликовано, но подобрать место возможно;
3) в CryptoApi создать контекст сертификата из содержимого сертификата и запросить строку субъекта (смотря в какой среде программирования - возможны вариации).

Если просто для визуального оповещения, то наверно можно рег-файл преобразовать в контейнер на съемном диске (или считывателе "Директория") и приспособить csptest для вывода информации о контейнере, в том числе о сертификате.



Спасибо за ответ, попробую покопать в этом направлении.
Среда программирования Powershell. Это необходимо для работы с большим объемом ЭЦП, автоматизации установки\хранения.
Offline Андрей *  
#4 Оставлено : 5 августа 2021 г. 15:23:04(UTC)
Андрей *

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 26.07.2011(UTC)
Сообщений: 12,625
Мужчина
Российская Федерация

Сказал «Спасибо»: 492 раз
Поблагодарили: 2034 раз в 1578 постах
Snimok ehkrana ot 2021-08-05 16-22-40.png (48kb) загружен 19 раз(а).
Техническую поддержку оказываем тут
Наша база знаний
thanks 1 пользователь поблагодарил Андрей * за этот пост.
OneLastgoodbye оставлено 05.08.2021(UTC)
Offline Анатолий Колкочев  
#5 Оставлено : 6 августа 2021 г. 23:29:05(UTC)
TolikTipaTut1

Статус: Активный участник

Группы: Участники
Зарегистрирован: 05.07.2018(UTC)
Сообщений: 467

Сказал(а) «Спасибо»: 43 раз
Поблагодарили: 69 раз в 61 постах
Я делал такую штуку на powershell в свое время.
Использовал Asn1Net.Reader ( ccылка: https://github.com/Asn1Net/Asn1Net.Reader ).

Вот код (именно тот кусок, который сертификат извлекает (в этом куске отсутствует проверка на то, есть ли в контейнере вообще сертификат)
Код:
 <...>
$b = [System.IO.File]::ReadAllBytes((gci .\header.key).FullName)
$m = [System.IO.MemoryStream]::new($b)
$berReader = [Net.Asn1.Reader.BerReader]::new($m, $true)
$headerKey = $berReader.ReadToEnd($true)
$certRawBytes = $headerKey.ChildNodes[0].ChildNodes[0].ChildNodes[3].RawValue #Именно тут сертификат расположен)
$cert = [X509Certificate]::new($certRawBytes)
$SN = $cert.Subject
<...>
thanks 2 пользователей поблагодарили TolikTipaTut1 за этот пост.
Андрей * оставлено 06.08.2021(UTC), OneLastgoodbye оставлено 10.08.2021(UTC)
Offline two_oceans  
#6 Оставлено : 13 августа 2021 г. 8:31:03(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,602
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Дополню. Пока меня не было видно на форуме я как раз задался вопросом извлечения сертификата из контейнера, кодировки ASN.1, безопасности хранения папок на диске NTFS, а также тестом совместимости считывателя съемных дисков с разными технологиями отображения папок (о тесте в другой раз, пока про ASN).

Сделал считывание дерева ASN "по слоям" - то есть для каждого тега сначала разделил содержимое между потомками. Если у тега есть установленный бит конструктивного кодирования 0x20 или тип OCTET STRING, то деление производится, иначе нет. Это правда дает много ошибок в случае, когда OCTET STRING на самом деле неделимый.

По такому принципу я пропускаю 2 слоя SEQUENCE (да как выше написали $headerKey.ChildNodes[0].ChildNodes[0]) далее ищу тег-потомок с длиной более 100 байт. 100 байт выбрано условно - из попадавшихся мне сертификатов самый маленький (и неквалифицированный!) был примерно 600 байт. С другой стороны, другие теги в header.key имеют длину явно меньше 100 байт (кроме расширений контейнера).

В данном случае, для сертификатов гост-2012 256 с dwKeySpec=KEYEXCHANGE тип тега мне везде попадался 0x85 (отмечу что бита конструктивного кодирования нет, сертификат включен как неделимый элемент). В только что сгенерированном контейнере - элемент отсутствует (то есть необязательный).

Тут нужно добавить, что формат header.key официально не опубликован, тем не менее по правилам номера из класса CONTEXT (0x85 = CONTEXT 5) присваиваются в описании типа последовательно и с учетом, что есть расширения сертификата CONTEXT 12, это наводит на мысль о существовании необязательных элементов со всем пропущенными номерами. По крайней мере, известно, что один контейнер теоретически может содержать 2 закрытых ключа (что очевидно как 2 пары primary + masks) и 2 сертификата (куда еще как ни в header.key). При таком количестве пропущенных элементов и необязательности сертификата - я бы не стал полагаться на выбор именно ChildNodes[3]. Более перспективно проверять код тега на соответствие 0x85 (но надо еще добавить номер для dwKeySpec=SIGNATURE) или на размер данных плюс неделимость элемента.

Еще хочу отметить, что при удалении расширений утилитой csptest - размер header.key не меняется, так что чтобы декодер не ругался на данные в конце файла не плохо после чтения установить размер данных по корневому элементу SEQUENCE.

P.S. Известно, что файлики составляющий контейнер без сертификата очень маленькие и (сюрпрайз! сюрпрайз!) файлы менее 1 Кб на самом деле хранятся NTFS без выделения кластеров на диске - прямо в записи о файле в файлах файловой системы $MFT и $MFTMirr. Получается, что контейнер как бы один, но хранится фактически в 2 местах на диске, что делает контроль непрозрачным. С другой стороны, так файлики не растянутся по всему диску плановой дефрагментацией и меньше риск их повредить при перезаписи. Файл header.key немного выбивается из шаблона - с сертификатом он более 1Кб и хранится в отдельном кластере, но там и так открытая информация.

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

В свете такой перспективы мне уже хочется перетащить все контейнеры на маленькие VHD, и затирать целиком весь VHD вместе с файловой системой. Жаль что букв дисков так мало. Либо добавить какой-то заполнитель места чтобы файлы стали больше 1 Кб плюс хранить на маленьком разделе с отключенной дефрагментацией.

Отредактировано пользователем 13 августа 2021 г. 8:34:03(UTC)  | Причина: Не указана

Offline Анатолий Колкочев  
#7 Оставлено : 13 августа 2021 г. 9:01:58(UTC)
TolikTipaTut1

Статус: Активный участник

Группы: Участники
Зарегистрирован: 05.07.2018(UTC)
Сообщений: 467

Сказал(а) «Спасибо»: 43 раз
Поблагодарили: 69 раз в 61 постах
Я просто все $headerKey.ChildNodes[0].ChildNodes[0].ChildNodes (вроде их там минимум 5, при условии, что сертификат добавлен) загонял в [X509Certificate]::new() и вылавливал exception-ы. Скорее всего это не очень красиво, но вроде пока работало ...

Отредактировано пользователем 13 августа 2021 г. 9:19:19(UTC)  | Причина: Не указана

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