- Вопрос или проблема
- Ответ или решение
- 1. Основные принципы проверки цифровой подписи
- 2. Процесс проверки цифровой подписи
- Шаг 1: Создание пары ключей
- Шаг 2: Подпись установщика
- Шаг 3: Распространение публичного ключа
- Шаг 4: Проверка подписи
- 3. Управление обновлениями сертификатов
- 4. Дополнительные меры безопасности
- Заключение
Вопрос или проблема
Я работаю над программным обеспечением, которое может быть размещено на собственных серверах, и оно включает компонент, который можно скачать и установить на устройствах конечных пользователей (только Windows). Загрузка происходит с сервера, размещенного на собственных ресурсах, а не из центрального места, и это не может быть изменено. Как мы можем проверить, что .msi, который программа загружает для обновления, действителен? Я могу разобраться с кодированием, но не знаю, как подойти к этому с точки зрения безопасности.
Наши установщики всегда подписаны действительным сертификатом для кода, выданным доверенным центром сертификации, поэтому я мог бы проверить их действительность и зафиксировать хэш действительного сертификата в программном обеспечении, но что произойдет, когда нам придется обновить сертификат для подписи кода? Люди на старых версиях программного обеспечения не смогут обновиться до версии, установщик которой был подписан новым сертификатом, потому что хэш сертификата не будет совпадать.
Как правильно проверить наши установщики?
Тот аспект, в котором я не уверен, заключается в проверке того, что установщик действительно подписан нами. Установщик размещается на собственном сервере и имеет возможность автоматического обновления, поэтому возможно, что конечный пользователь может быть направлен к установщику, подписанному кем-то другим. Поэтому нам нужно проверить, что a) .msi подписан действительной подписью и b) он был подписан нами и никем другим. Вторая проблема – это то, что я пытаюсь решить.
Обычно подпись кода сопровождается временной меткой. Таким образом, подпись может быть проверена с использованием открытого ключа из доверенного сертификата – даже если сертификат сейчас истек – если только сертификат был действительным на момент подписания.
Подпись создается с помощью закрытого ключа, у которого есть соответствующий открытый ключ.
При проверке подписи проверяются две вещи: совпадает ли содержимое с тем, что было проверено? Было ли содержимое подписано конкретным закрытым ключом?
Первая характеристика, также известная как Целостность, может быть достигнута с помощью хэш-функции. Вторая характеристика, также известная как Аутентичность, – это то, что приносит криптография с открытым ключом.
Как я могу проверить, что установщик был подписан нами, а не третьей стороной?
- Создайте пару закрытый/открытый ключ
- Распределите открытый ключ вместе с клиентом
- Подпишите установщик закрытым ключом
- Проверьте, что установщик был подписан закрытым ключом с использованием открытого ключа
Конечно, этот подход можно и нужно расширить, используя сертификаты вместо простых открытых ключей, используя цепочку доверия со промежуточными сертификатами и т.д. Однако все это немного выходит за рамки вопроса.
Ответ или решение
Чтобы убедиться в подлинности и целостности установщика, который ваша программа загружает и устанавливает на конечные машины пользователей, необходимо следовать точному и последовательному процессу проверки цифровой подписи. Ваша задача заключается в том, чтобы гарантировать, что установщик действительно подписан вашими собственными ключами и не был подделан третьими лицами.
1. Основные принципы проверки цифровой подписи
Процесс проверки цифровой подписи включает в себя несколько ключевых моментов:
- Целостность: Проверяем, совпадают ли содержимое установщика и вычисленная хэш-значение.
- Подлинность: Убедитесь, что установщик подписан с использованием вашего приватного ключа, соответствующего открытому ключу в сертификате.
Такой подход обеспечивает, что загружаемое программное обеспечение действительно является тем, что вы предоставили, и не было изменено.
2. Процесс проверки цифровой подписи
На высоком уровне процесс проверки может быть разбит на несколько шагов:
Шаг 1: Создание пары ключей
Необходимо создать пару ключей: приватный и публичный. Приватный ключ используется для подписи устанавливаемого файла, тогда как публичный ключ будет необходим для его проверки.
Шаг 2: Подпись установщика
Используйте ваш приватный ключ для подписи .msi файла. Это может быть выполнено с использованием инструментов, таких как signtool, который предоставляет Windows SDK. Убедитесь, что используемый сертификат действующий и подписан доверенным центром сертификации.
Шаг 3: Распространение публичного ключа
Публичный ключ должен быть безопасно включен в вашу клиентскую программу или доступен по безопасному каналу. Это позволит программе проверять подлинность цифровой подписи.
Шаг 4: Проверка подписи
Когда ваш клиент загружает .msi файл, программа должна выполнить следующие действия:
- Сначала проверить, что файл подписан.
- Затем извлечь из подписи сертификат и проверить его действительность и цепочку доверия.
- наконец, использовав публичный ключ, подтвердить, что файл был подписан вашим приватным ключом.
Следует помнить, что для проверки сертификата может быть важно учитывать срок действия и наличие временной метки. Сертификаты, даже если они истекли, могут быть валидными для проверки подписи, если подпись была сделана в момент действия сертификата.
3. Управление обновлениями сертификатов
Когда наступает время обновления вашего сертификата, необходимо учитывать несколько моментов:
- Возможно, вам придется параллельно поддерживать оба сертификата (старый и новый) в течение переходного периода, чтобы пользователи могли обновлять свои версии программного обеспечения.
- Убедитесь, что ваше приложение может принимать подписание обеими версиями сертификатов для обеспечения непрерывности работы и повышения удобства для пользователя.
4. Дополнительные меры безопасности
Чтобы повысить уровень безопасности, рассмотрите возможность добавления:
- Хеширования установщика перед его подписью для обеспечения безопасности файлов.
- Использования проверки с помощью механизма отзыва сертификатов (CRL или OCSP), чтобы удостовериться, что сертификат не был отозван.
- Реализации более сложной цепочки доверия с использованием промежуточных сертификатов для большей устойчивости к компрометации главного ключа.
Заключение
Этот подход к проверки цифровой подписи поможет вам безопасно и надежно подтверждать подлинность вашего программного обеспечения. Следуя описанному процессу, вы сможете не только поддерживать целостность и подлинность вашего установщика, но и предотвратить возможность злоупотребления со стороны третьих лиц, что критически важно в условиях самостоятельного хостинга и автоматического обновления.