Компания
28,83
рейтинг
2 октября 2012 в 14:11

Разработка → Code Signing сертификаты или сертификаты разработчика. Виды, как выбрать

В прошлый раз мы рассматривали цифровые SSL сертификаты, в этот раз рассмотрим еще один вариант цифровых сертификатов.
Code Signing сертификаты — это сертификат, которым подписывается программное обеспечение или скрипты, который подтверждает автора программы и гарантирует, что код не был изменен, после того, как была наложена цифровая подпись. Также их еще называют сертификаты разработчика.

Итак сертификаты разработчика предоставляют нам несколько возможностей. Во-первых это механизм цифровой подписи, которая подтверждает, что программа, которой вы пользуетесь действительно выпущена той или иной компанией, то есть гарантирует подлинность источника. А во вторых гарантирует целостность содержимого, то есть, что с момента подписания программный продукт не был поврежден или изменен.


Во всех современных версиях Windows, начиная с Windows XP SP2, при установке программного обеспечения без такой цифровой подписи вы получите предупреждение. То же самое кстати касается и установки драйверов, которые не имеют соответствующей цифровой подписи.

В случае, если цифровая подпись не найдена, Windows выдаст предупреждение, что у этой программы «Неизвестный издатель» и запускать её не рекомендуется.


В случае, если программа имеет цифровую подпись, то окошко будет выглядеть иначе и вы также сможете посмотреть информацию о сертификате.



Какие бывают виды Code signing сертификатов, и чем отличаются?


Прежде всего рассмотрим сертификаты, по центрам сертификации, которые их выпускают.

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

Платформа \ Центр сертификации Symantec Thawte Comodo Digicert Globalsign Trustwave Startcom
Microsoft Authenticode Signing + + + + + + +
Code Signing for Apple + + + + + +
Microsoft Vba Signing + + + + + + +
Java Code Signing + + + + + + +
Adobe Air Signing + + + + + + +
Kernel Mode Signing + + + +
Android +
Windows Phone +
Qualcomm BREW +
Стоимость, от 500$ 250$ 90$ 220$ 220$ 330$ 200$

стоит уточнить, что не все центры сертификации дают полную информацию о платформах, на которых работают их сертификаты, поэтому плюсом отмечены только те платформы, поддержка которых в явном виде заявлена центром сертификации.

Microsoft Authenticode

Для подписи 32 и 64 битных файлов (.exe, .cab, .dll, .ocx, .msi, .xpi и .xap файлы). Также позволяет подписывать код для Microsoft® Office, Microsoft VBA, Netscape Object Signing и Marimba Channel Signing.
Поддерживает приложения на Silverlight 4

Code Signing for Apple

Позволяет разработчикам подписывать программы для Mac OS, а также обновления для программного обеспечения

Microsoft Office Vba Signing

Подписывает VBA объекты, скрипты и макросы для файлов Microsoft Office .doc, .xls, и.ppt
Для Microsoft Office и дополнений, которые используют VBA

Java Code Signing

Для подписи Java апплетов. Позволяет подписывать .jar файлы и Java приложения для настольных и мобильных устройств.
Распознается Java Runtime Environment (JRE)

Adobe Air Signing

Для подписи файлов .air
Требуется для всех приложений, основанных на AIR

Kernel Mode Signing

Сертификаты разработчика Kernel-Mode позволяют подписывать, так называемые kernel-mode приложения и драйвера устройств. 64 битная версия Windows Vista и Windows 7 требуют, чтобы все kernel-mode приложения были подписаны сертификатом и доверенного центра сертификации.

Android

Для подписи и оптимизации .apk файлов для платформы Android

Microsoft Windows Phone

Для цифровой подписи приложений для Windows Phone и Xbox 360. Требуется для сервиса Microsoft App Hub

Qualcomm BREW

Для тех, кто разрабатывает приложения под платформу BREW (Binary Runtime Environment for Wireless)

Как работает Code Signing сертификат:


Процесс подписи кода.


  1. Издатель (разработчик) запрашивает Code Signing сертификат у центра сертификации
  2. Используя SIGNCODE.EXE или другую утилиту для подписи кода издатель, cоздает хеш кода, используя алгоритмы MD5 или SHA
  3. Кодирует хеш, с помощью приватного ключа
  4. Создает пакет, который включает в себя: код, зашифрованный хеш и сертификат издателя

Процесс проверки подписанного кода.


  1. Пользователь скачивает или устанавливает подписанное ПО и платформа или система пользователя проверяет сертификат издателя, который подписан корневым приватным ключем центра сертификации
  2. Система запускает код, используя тот же самый алгоритм создания хеша, как издатель и создает новый хеш
  3. Используя публичный ключ издателя, который содержится в сертификате, система расшифровывает зашифрованный хеш
  4. И сравнивает между собой 2 хеша


Центр сертификации

Когда разработчик запрашивает цифровой сертификат — центр сертификации идентифицирует его и выпускает сертификат, связанный с корневым сертификатом центра сертификации. Платформы и устройства содержат в себе корневой сертификат соответствующего центра сертификации. То есть если платформа или устройство доверяет какому-либо центру сертификации, то оно доверят и вашему сертификату, подписанному этим центром сертификации.
В случае если хеши не совпадают вы получите ошибку при запуске такого ПО — это может означать, что ПО было модифицировано вирусом или злоумышленником.

Когда ПО расшифровывает цифровую подпись, оно проверяет также корневой сертификат в системе, источник проверенной информации. В случае использования самоподписного сертификата, вы получите ошибку: «издатель не может быть проверен». Поэтому важно использовать сертификаты того центра сертификации, чьи корневые сертификаты уже установлены в системе у предполагаемого пользователя программы.

О самом процессе верификации организации рассказывать не буду, так как он такой же как и для SSL сертификатов с валидацией организации, о чем мы уже говорили в прошлой статье.

Несколько слов про timestamp.

Timestamp или временная метка используется для указания времени, когда цифровая подпись была сделана. Если такая метка присутствует, то приложение, которое проверяет подпись проверит был ли сертификат, связанный с подписью валидным на момент подписи. Если же такой метки нет, и срок сертификата уже закончился, то подпись будет считаться недействительной.

Пример:
Сертификат действителен с: 01.01. 2008
Сертификат действителен до: 31.12.2010
Подпись сделана: 04.07.2009
Подпись проверена: 30.04.2012

C временной меткой (timestamp) подпись пройдет проверку, поскольку на момент подписи сертификат был действителен. Без такой метки сертификат не пройдет проверку, поскольку на момент проверки у сертификата уже закончился срок.
То есть такая метка позволяет использовать подписанный код, даже после срок окончания сертификата.

Подведем итог

Для выбора сертификата сначала нужно выбрать центр сертификации, который выпускает сертификаты под нужную вам платформу, а дальше выбор по сути сводится к выбору по цене и по известности центра сертификации, зачастую клиенты выбирают те центры сертификации, с которым уже работали ранее.

Несколько советов.

  1. Заявку на сертификат желательно оформлять с той же машины, с которой вы потом будете выполнять подпись ПО.
  2. Большинство центров сертификации рекомендуют генерировать заявку на сертификат через Internet explorer, хотя при генерации заявок через другие браузеры у нас также не было проблем.


Буду рад ответить на вопросы по сертификатам разработчика, в рамках своей компетенции, так как сам разработчиком не являюсь.
Также буду рад дополнениям и уточнениям от тех, кто такими сертификатами пользуется.

UPD: добавил важную информацию про timestamp (временную метку), спасибо TolTol и crea7or
Автор: @s0laris
TutHost
рейтинг 28,83
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Комментарии (57)

  • –1
    Довольно познавательно!
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Лично я не в курсе этой опции, сейчас ознакомлюсь. Правильно ли я понимаю, что она доступна только для Microsoft Authenticode?
      • +3
        Без таймстампа приложение подписанное при валидном сертификате перестаёт таковым быть после истечения срока сертификата. Что вообще-то не очень хорошо и смысл подписи (под windows) теряется.
        • 0
          Спасибо за полезное дополнение, добавил эту информацию в статью.
        • 0
          Интересные эффекты начинаются, когда кончается срок сертификата, подтверждающего валидность timestamp-а. Тогда система признает подпись валидной или не валидной в зависимости от того, с какой ноги встала.
          • 0
            никогда не было проблем с сертификатами. пользуюсь с 2007 года. это наверно что-то конкретно у вас.
            • 0
              Временная метка — это точно такая же подпись сертификатом, только со стороны сервера времени. У него точно так же есть срок действия. Когда он кончается, что должна сделать система? Ведь срок действия делают не просто так, а в расчете на повышающуюся с каждым днем вероятность влома или кражи. Был реальный прецедент. Не у меня. Я просто констатирую факт.
              • 0
                Мы точно про signing time говорим?
                • 0
                  Да, а есть варианты? Дать ссылку на разбор прецедента?
                  • 0
                    давно пора уже ссылку дать!
                    • 0
                      Чтоб ее дать, нужно сначала ее найти: вот оно
                      • +1
                        Там таймстампинг есть только у самого дорогого сертификата, сомневаюсь. что использовался именно он:
                        www.startssl.com/?app=40

                        Вот у меня файлик 2007 года — всё ок:
                        image
                      • 0
                        • 0
                          Походу виноват таки его основной сертификат. Странно то, что валидность потерялась в день потери валидности сертификата таймстампа. И не понятно, чем технически сертификаты с поддержкой таймстампа отличаются от сертификатов без поддержки, кроме цены.
                        • 0
                          Есть там таймстамп и в тех что за 60$
                          • 0
                            Ну и что тогда не сработало у него?
                          • 0
                            Склоняюсь к мысли, что где-то в атрибутах сертификата прописан параметр, который определяет действия системы по окончании срока валидности сертификата времени. Т.е. разрешает таймстампом подписывать(верисайновским или комодовским, потому что на родной его таки не пускает), но не влияет на валидность после окончания срока действия. Информации о том, что StartSSL имеют ввиду под минусом в графе «Time-Stamping extendable» я не нашел.
                            • 0
                              Вдруг вам будет интересно, тут как раз про это:
                              www.rsdn.ru/forum/shareware/5040014
                              • 0
                                Спасибо, я как раз там тоже участвовал ;)
                                • 0
                                  Действительно, ну может кого-нибудь ещё заинтересует.
                                  А вам случайно не удалось выяснить, как реализован запрет на timestamping с технической стороны? Насколько я понимаю, его разрешает стандартный OID для подписывания кода, которые присутствует в Class 2 от StartSSL.
          • 0
            С подписью с timestamp есть такой нехороший фактор, что такой сервис предоставляет кажется только verysign, по крайней мере Thawte не предоставлял своего, а направлял использовать verysign. Проблема с verysign в том что сервис работает настабильно, а так как подписывание было прикручено к билд машине, то при ошибке билд падал, пришлось делять танцы с бубном и повторные запросы при ошибке.
      • 0
        Не знаю как для iOS приложений, но для Mac приложений исспользуется тот-же Microsoft Authenticode и кстати ещё Firefox Addons им можно подписывать.
  • 0
    Сертификат Symantec как-то странно избыточен, учитывая, что сертификаты под Android, iOS, Brew разработчик может бесплатно получить.
    • +1
      А можете дать ссылку на информацию, как разработчики под эти платформы могут получить бесплатные сертификаты?
      • 0
        Сертификаты получают официальные разработчки автоматически когда выставляют свои приложения. То есть, сертификат входит в стоимость подписки разработчиков.
        Видимо, речь была про это.
      • 0
        Под Android ты сам себе генерируешь и подписываешь его =)
        Под iOS получаешь вместе с подпиской разработчика.
  • 0
    Спасибо, годная табличка.

    Подскажите, а есть ли где-нибудь в открытом доступе информация о структуре подписанного .exe файла? Я в целом представляю как с помощью CryptoAPI подписать .exe и проверить цифровую подпись — но что при этом происходит с самим .exe фалом (сертификат в секцию ресурсов записывается, как отдельная секция, просто в конец, еще как-то, где хэш подписанный лежит...) я в гугле беглым поиском не нашел :(.
    • –2
      Вот это увы не подскажу, знаю только что можно, например через PE Explorer просмотреть в ресурсах подпись.
      • 0
        Довольно странно для человека пишущего статьи о code signing.
        • 0
          В случае с code signing я больше занимаюсь их продажей, чем реальным использованием, наша компания ПО не выпускает.
    • +2
      • 0
        Благодарствую, то что нужно.
  • 0
    Год назад мучались с сертификатом от Thawte для подписи jar-ки, т.к. у нас и не стало отображаться в браузере наш алерт нормально. А вот с предыдущим сертификатом от Comodo все работает и по сей день. Вспоминаю эти извращения с разнообразными сайнтулзами как страшный сон.
  • 0
    4 года назад получал сертификат Microsoft Authenticode Signing у VeriSign (сейчас называется Symantec). Получился целый квест с пересылкой нотариально заверенного перевода с описанием компании и объяснением, почему нет описания компании в желтых страницах интернета. Для американцев желтые страницы очень серьезный аргумент. Теперь каждый год продляю сертификат, это уже намного проще.
    • 0
      Сертификаты удобнее заказывать сразу на максимально возможный срок, если бюджет позволяет. Так и цена минимальная и мороки каждый год с продлением нету. А на счет желтых страниц — сейчас на них уже меньше обращают внимание. К примеру Thawte запрашивают верификацию у какой-то сторонней компании, которая только этим и занимается, а они уже проверяют по своим базам, подозреваю, что по открытым базам официально зарегистрированных фирм.
      • +1
        Thawte уже 12 лет как куплена verisign'ом. Так что тараканы там одинаковые.
      • 0
        Как то жалко отдавать сразу и много. В принципе, оплата за год вполне адекватная.
    • +1
      Может DUNS, а не жёлтые страницы?
      • 0
        Нет, именно в yellow pages раньше проверяли, особенно Thawte.
      • 0
        В желтых именно, я у них в чате спрашивал, на кой им сдались русские желтые страницы, на что получил ответ, что у них за бугром это серьезный каталог, где проверяются данные перед выкладкой, а не как у нас «рекламная песочница» (особенно была раньше).
        • 0
          А объяснений про «большую русскоязычную мусорку» они упорно не поняли?
  • 0
    Кстати, а на сайте Comodo другой список того, что можно сертификатом подписать:
    Sign multiple types of code files, including .exe, .msi, .cab, VBA, Java, Adobe AIR, .ocx and .dll files

    www.comodo.com/e-commerce/code-signing/code-signing-certificate.php

    И кстати вопрос: есть ли корневой сертификат Comodo в Windows XP? Т.е. будет ли корректно работать подпись на старых ОС без обновлений и сервиспаков?
    • 0
      И еще в догонку вопрос. Учитывают ли как-то антивирусы, что программа подписана сертификатом?
      • 0
        Такими сведениями не обладаем. Думаю логично было бы учитывать.
    • 0
      Список для comodo в табличке поправили, спасибо.

      Проверили на последнем компе с win xp, который у нас остался, сертификаты выданные comodo видит нормально.
  • 0
    Хороший цикл статей, жду продолжения :)
    Хотелось бы узнать: можно ли, имея CSR, узнать какой тип сертификата я получу? SSL, SMIME или Code Sign сертификат?
    • 0
      Статьи по каким темам вам были бы интересны?
      Ваш вопрос несколько некорректен, так как тип сертификаты выбирается в зависимости от потребностей, а не от CSR подписи.
      • 0
        Интересно по S/MIME сертификатам :)

        Да, сертификат выбирается в зависимости от потребностей. Но просто интересно можно ли определить тип сертификата основываясь на CSR? Есть ли какие-то признаки явно указывающие, что этот CSR для выписки SSL сертификата, а вот этот CSR для выписки S/MIME.
  • 0
    Интересно какой сертификат нужен для настройки радиус-сервера, который будет аутентифицировать абонентов подключающихся к Wi-Fi точке доступа (протокол EAP-TLS). Как его сгенерировать и у кого подписать?
    • 0
      support.microsoft.com/kb/814394
      В доменной среде все делается весьма просто — достаточно типовых сертификатов User на пользователя, Computer — на клиентские компьютеры и серверы RADIUS.
      При наличии AD Cerificate Services и Network Policy Server все делается достаточно просто

      Перед всей свистопляской очень рекоммендую прочитать Windows Server 2008 PKI and certificate security от Brian Komar. Купить ее почти нереально, но есть в PDF.

      Если вкратце — то нужен сертификат с EKU OID Client Authentication И Server Authentication.
      Для WIndows 8008 R2 потребуется переделать шаблон, так как «по-умолчанию» там шаблоны сертификатов User и Computer версии 1, которые не поддерживают AutoEnrollment (автообновление \ авторазвертывание)
    • 0
      А про «у кого подписать» — при развертывании ADCS вам просто нужно распространить сертификат своего CA (он скорее всего будет самоподписанный) на компьютеры клиентов политикой.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка