Комментарии 23
Во-первых, есть дешевая альтернатива всей этой возни с брелками - Azure Trusted Signing. 10 долларов в месяц, 120 долларов в год - это получается на уровне дешевых электронных подписей типа ssl.com. Ограничение - 10000 подписываний в месяц, за глаза должно хватить. Из преимуществ - не нужно покупать брелок или платить за его пересылку, сертификат - аналог EV, подписание привычным signtool, хоть и новой версии с аддоном, нет привязки к физическому брелку, помесячная оплата. Из недостатков - достаточно замороченная настройка в Azure, но это нужно делать один раз, помесячная оплата и в любой момент ее могут повысить. Но если повысят, то можно быстро вернуться к привычному способу подписания.
Во-вторых, центры сертификации присылают либо свой брелок, либо клиент может использовать собственный. Но если использовать собственный, то выбор сужается только до Yubikey 5 FIPS. Свой Yubikey по-любому выходит дешевле. Никаких там рутокенов. И для Yubikey вроде бы есть возможность передать PIN-код через командную строку.
Сам еще с этими трудностями еще не сталкивался, мы умудрились оформить сертификат за два месяца до введения новых правил.
С 1.06.2023 году вступили в действие новые требования к сертификатам для подписи кода
А можно с этого места поподробнее: где они вступили, кто требует их выполнения и как проверяется, что ключ действительно хранится в соответствии с требованиями, а не в файле PFX? А то мне в уже далекие годы приходилось иметь дело с технологией (некий Alladin SecretDisk), которая как раз требовала использования такого вот брелка. И мне помнится, что там вполне можно было записать на брелок сертификат из .pfx.
Мы, как российские разработчики, оказались точно также затронуты этими нововведениями.
А в законодательстве РФ или в позаконных актах уполномоченнного органа это как-нибудь отражено? А то, при взгляде на английский текст меня терзают смутные сомнения.
Может, стоит, по русскому обычаю, забить на эти ужасы?
где они вступили, кто требует их выполнения и как проверяется, что ключ действительно хранится в соответствии с требованиями, а не в файле PFX?
Ссылка в самом начале статьи. Их выполнение обязательно для центров сертификации. Ни один публичный авторизованный ЦС не выпустит сертификат подписи кода без хранения закрытого ключа на устройстве. Им же совершенно не хочется терять авторизацию.
А в законодательстве РФ или в подзаконных актах уполномоченного органа это как-нибудь отражено?
Нет конечно, это решает не законодатель, а продавец услуги. Как в анекдоте: "Не нравится предложение? - А ты походи по базару, поищи получше".
А то мне в уже далекие годы приходилось иметь дело с технологией (некий Alladin SecretDisk), которая как раз требовала использования такого вот брелка. И мне помнится, что там вполне можно было записать на брелок сертификат из .pfx.
Требуется носитель с неизвлекаемым закрытым ключом. Сейчас на рынке вообще один ЦС остался, который официально работает с российскими клиентами: GlobalSign. Он предлагает носитель Рутокен ЭЦП 3.0, который поддерживает неизвлекаемые ключи. И я не слышал, чтобы кому-то удалось извлечь их из него.
Их выполнение обязательно для центров сертификации. Ни один публичный авторизованный ЦС не выпустит сертификат подписи кода без хранения закрытого ключа на устройстве. Им же совершенно не хочется терять авторизацию.
Вы так рассуждаете, как будто эти правила выпущены органом, имеющим властные полномчия. А по факту они - междусобойчик частных фирм, которые просто тянут с людей деньги за навязанную им услугу. Потому что технически CA - это очень простая штука, если чо, у меня на домашнем ПК в виртуалке стоит, от экспериментов остался. Вопрос тут в доверии, и я не понимаю, почему человек, как частно лицо или, к примеру, в роли руковдителя службы ИБ предприятия, должен доверять этому междусобойчику и не доверять кому-то другому. Государство, конечно, тоже заслуживает мало доверия, но корпорации заслуживают доверия ещё меньше, потому что забота об ощем благе в их интересы не входит даже декларативно.
Нет конечно, это решает не законодатель, а продавец услуги.
Нет, право решать продавца должно, исходя из интересов общего блага, быть ограничено. Если продавец теряет берега, то должно прийти государство (например, в лице антимонопольщиков), и ему эти берега указать. А в данном случае монопольный картельный сговор налицо.
Но конкретно тут государство РФ лоханулось. Ещё когда обсуждался закон о пресловутом суверенном Рунете, я тогда сразу обратил внимание на крайний непрофессионализм обсуждения, что ни одна из сторон - ни власть, ни оппозиция - не представила публики явным образом своей модели угроз, на основании которой можно было найти решение. Оппозиция заботилась лишь о своем праве вести пропаганду, а власть выступала с хорошо знакомой позицией, что "там, наверху, и без вас разберутся". А я ещё тогда, посмотрев детали предлагаемых мер, не увидел ничего про обеспечение суверенной инфраструктуры открытых ключей. Но решил забесплатно не умничать, а заниматься своими делами.
А вот после 22-го года этот провал вылез наружу - то есть, как мы видим, там, наверху, не разобрались (что, в общем-то и следовало ожидать).
Требуется носитель с неизвлекаемым закрытым ключом.
Вы, похоже, не поняли идею: пусть ключ и неизвлекаемый, но на носитель записывается сгенерированный другим способом ключ, который потом извлечь нельзя. А копия ключа остается и может использоваться нормально. Но насколько это технически осуществимо, и возможен ли такой способ обойти дурную навязанную процедуру - в этом как раз и вопрос.
Уточнение: надеюсь, ЦС не пытаются навязывать свою ключевую пару, а просто подписывают сертификат с открытм ключом, который заявитель сгенерировал сам? А то это было бы полнейшим безобразием - позволять какому-то мутному ЦС (не важно, частному или государственному) доступ к своему закрытому ключу.
Сейчас на рынке вообще один ЦС остался, который официально работает с российскими клиентами: GlobalSign.
Это, конечно, безобразие, но это уже зона ответственности государства. А, как я писал выше, российское государство этот момент откровенно зевнуло, когда соответствующий закон принимало.
Короче, есть технические вопросы, как жить в существующих условиях - и относительно их статья вполне удовлетворительна. Разве что, неплохо было бы подробнее объяснить контекст тем, кто не в теме: я, например, не понял, каких продуктов это касается.
И есть вопросы человеческие - как относиться к существующим условиям. И выраженная в статье позиция - как будто все происходит так, как должно , своего рода "политика выполнения", если брать исторический аналог - в этом отношении мне не нравится. Впрочем на ценность статьи как технической это практически не влияет.
Вас понесло в абстрактные рассуждения. В реальности есть перечень аккредитованных публичных ЦС. У них есть регламент, они его придерживаются. Если он вам не нравится, то есть два пути:
Принять реальность.
Создать свой ЦС, с БДиШ (государственный, частный, домашний - без разницы). Всего-то надо добавить его корневой сертификат в список доверенных на все уже развёрнутые и будущие операционные системы, браузеры и устройства страны/мира - и дело в шляпе.
Ну, я чувствую, что до п.2. российское государство доберется, и скорее рано, чем поздно, поменяет-таки реальность - оно это умеет. И мало не покажется никому.
Но если даже без абстрактных рассуждений (хотя они про чисто конкретные проблемы), то, раз вы обозначили статью как "Туториал", стоило бы IMHO раскрыть контекст - для какого типа прложений это существенно. Хотя бы - ссылкой.
А то, гляжу, эти, типа, нормы-то вступили уж полтора года как, а на столь любимом многими (мной в том числе) бэкенде на ASP.NET Core с MVC и Minimal API они никаких заметных заморочек не вызвали.
Моя статья - туториал по решению конкретной проблемы. Если вам интересно, что такое вообще подпись кода, то это немного другая тема; можно почитать, например, здесь же на хабре.
Если кратко, для внутреннего употребления программы подписывать в большинстве случаев не обязательно. Но если вы распространяете бинарники/установочные пакеты клиентам, то уже крайне желательно их подписывать, чтобы антивирусы и операционные системы не ругались на код из недоверенных источников. Более того, корпоративные службы ИБ очень любят запрещать в своих сетях запуск непонятно чьего кода через политики SRP . И здесь электронная подпись ПО помогает идентифицировать его и пометить как доверенное.
А то, гляжу, эти, типа, нормы-то вступили уж полтора года как, а на столь любимом многими (мной в том числе) бэкенде на ASP.NET Core с MVC и Minimal API они никаких заметных заморочек не вызвали.
А почему вы вообще ожидали, что нормы для массовых десктопных виндовых приложений как-то затронут бекенд, предназначенный для работы в ограниченном числе экземпляров, да ещё и небось на линуксе?
А почему вы вообще ожидали, что нормы для массовых десктопных виндовых приложений
А я этого и не ожидал. Я ожидал, что автор укажет, для какой области применения нужно его решение, и не более того - а не начнет статью так, будто это нужно всем разработчикам под .NET. Даже если ему некогда писать много букв в статье - есть же теги. А тегах я как раз не вижу Windows Desktop, а вижу очень даже asp.net.
И, насчет "массовых виндовых десктопных приложений". Насколько я помню, подписывание приложений нужно было только весьма специфическому их классу - UWP/Windows Store(или как он там сейчас называется), а на обычные приложения под Win32 такого требования не было: подписать было можно, но можно было обойтись и без этого. Что-то поменялось?
Подписываются исполняемые файлы, DLL и установочные пакеты. Desktop, ASP.NET, драйверы - не важно. .NET тут фигурирует как платформа для разработки сервера подписи.
Я в курсе, что можно подписать. Но меня, если смотреть с позиции администратора инфраструктуры предприятия, каковым я был некогда, интересует, во-первых, что подписывать обязательно, и где требуется подпись не от корпоративного CA, а именно от внешней сертифицирующей организации.
Теперь посмотрите с точки зрения поставщика ПО. Ему неведомо, какой там внутренний ЦС у каждого потенциального клиента. Зато ему нужно, чтобы ПО без проблем работало у всех. Поэтому дорога одна: в публичный аккредитованный ЦС.
Говорят, дорог всегда, минимум, две - даже если вас проглотили.
Внутренний ЦС - это область ответственности админа (или ИБ) предприятия
И админ предприятия, например, вполне может самостоятельно воспользоваться тем же самым SignTool. Да и обычных пользователей не надо недооценивать: к примеру, рутовать телефоны для установки нужных им приложений у них вполне получается. А, с другой стороны, у "публичных аккредитованных ЦС" есть свои недостатки, вполне заметные, особенно - в специфических российских условиях.
Так что выбор есть, и это хорошо. Но, наверное, обсуждать этот вопрос дальше - это для вас слишком абстрактно будет.
Вы хоть раз видели как на винде SmartScreen работает? Тот самый, который всплывает при запуске скачанных из интернета программ?
Вот если программа не подписана, то в этом диалоге пишется "неизвестный издатель", а если подписана - то имя того, кто подписывал. Для того подпись и нужна.
Вы хоть раз видели как на винде SmartScreen работает? Тот самый, который всплывает при запуске скачанных из интернета программ?
Зачем Вы мне объясняете менторским тоном, где я могу посмотреть подпись кода исполняемого файла? Я это знаю, как минимум, не хуже вас.
Я выше писал про другое: SmartScreen и пр. не блокируют в Windows наглухо запуск исполняемого файла без надлежащей подписи: в диалоге можно выбрать таки запустить исполняемый файл. А можно этот диалог вообще не показывать, это натраивается через политику. Хотите возразить?
PS Про прочие связанные с этим "абстрактные" вопросы я писать, с вашего позволения не буду.
Ну, я чувствую, что до п.2. российское государство доберется, и скорее рано, чем поздно, поменяет-таки реальность - оно это умеет. И мало не покажется никому.
Они уже несколько лет пытаются пропихнуть свой корневой сертификат Минцифры на все устройства. Правда, пока плохо получается.
Как-то так https://www.ssl.com/how-to/key-generation-and-attestation-with-yubikey/#attestation
Проверяются ключи, вшитые в конкретный брелок (с привязкой к сформированному в памяти брелка закрытому ключу). Выполнения требуют центры сертификации, которые и выдают сертификаты. В российских законах, разумеется этого нет и вы можете спокойно забить на все эти правила. Правда, вы не получите подписанный бинарник для windows. Только если у вас есть старый многолетний сертификат, полученный по старым правилам.
Благодарю. Техническая сторона проверки мне теперь понятна.
Неизвлекаемость ключа должна гарантировать как раз сертификация FIPS 140-2/140-3, которую проводит NIST. При прохождении сертификации проверяют как саму железку, так и ее прошивку. И это занимает основательно времени (полтора года в среднем, зафиксированный минимум год). Плюс стоимость сертификации. Собственно поэтому Yubikey 5 FIPS дороже обычных раза в полтора. И их сложно достать, потому что они мало кому нужны и их, в основном, закупают корпорации централизованно.
CodeSigning для разработчиков под Windows по новым правилам