Файловые подписи: как я могу убедиться, что Windows DLL не изменен?

Question

Я однажды задал вопрос here, если Windows DLL подписаны Microsoft. Я понял, что они были, и хороший друг сказал мне, что утилита SigCheck может предоставить информацию о сигнатуре файлов; но остался вопрос:

Пока SigCheck сообщает мне, подписан ли файл, я должен быть уверен, что Microsoft подписала этот файл, и никто позже его не изменил. Я имею в виду, что, если кто-то замял файл, а затем снова запишет файл (с именем Microsoft на подпись, конечно)?

Как я могу быть абсолютно уверен, что файл является подлинным?

Answer 1

«Я имею в виду, что, если кто-то саботаж файл , а затем подписывает файл снова (с именем Microsoft на подписи, конечно)?»

Это невозможно из-за природы цифровых подписей. Чтобы сгенерировать цифровую подпись, Microsoft хэширует файл, а затем зашифровывает этот хеш своим личным ключом (известный только им). Насколько я понимаю, другие поставщики будут использовать закрытые ключи от other Certificate Authorities, которые Windows настроена на доверие по умолчанию.

Когда Windows проверяет файл, он расшифровывает подпись, используя соответствующий открытый ключ. Затем эта подпись сравнивается с текущей подписью. Если они совпадают, файл находится в Microsoft. Если они не совпадают, файл был изменен.

Таким образом, единственный способ заставить файл выглядеть так, как будто он был «подписан» Microsoft, - это украсть их секретный ключ. Прочтите digital signature article on Wikipedia.

Для получения более подробной информации о том, как работает процесс, прочитайте "Signing and Checking Code with Authenticode" и "Introduction to Code Signing" на MSDN.

Answer 2

Из памяти в процессе подписи используется public key cryptography.

This diagram из wikipedia объясняет процесс лучше всего.

В заключение,

«сообщение подписал с закрытым ключом отправителя может быть проверена любым , кто имеет доступ к публичной ключа отправителя, тем самым доказав, что отправитель имел доступ к частному ключ (и , поэтому, вероятно, будет лицо , связанное с используемым открытым ключом), и часть сообщения, которое имеет , не было подделано ».

ie. Sigcheck выполняет проверку с использованием открытого ключа Microsoft в файлах, которые ранее были подписаны с использованием закрытого ключа Microsoft (и, конечно, только Microsoft имеет доступ к закрытому ключу).

Answer 3

Чтобы построить на то, что другие уже размещены:

Отказ от ответственности: использование MS государственных/частных ключевых терминов w.r.t цифровой подписи, используемые, чтобы запутать меня много. У меня только что был «Ага!» момент. Я постараюсь поделиться своими мыслями, если это поможет кому-то.

Введите ППК

---

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

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

Почему разные DigSigs?

---

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

Выше было то, что MS делает со своими DLL.

стороне клиента проверка

---

Теперь, для части проверки. Сертификат, созданный MS, не подходит, пока Центр сертификации не говорит, что это хорошо. Это справедливо для всех. Если вы хотите безопасно вести бизнес, вам необходимо получить сертификат от центра сертификации. После того как ваш клиент установит ваше приложение, программа проверки работоспособности ОС вырвет ваш сертификат и проверит его, проверив что-то вроде цепочкой доверия. Он проверит, кто сертифицировал вашу подпись. Это родительский сертификат. Если система может идентифицировать родителя, они будут выполнены, и вы будете приняты. Если, однако, родительский элемент не может быть проверен, вызывается родительский родительский элемент. И цепочка продолжается, пока не найдется узел, который можно проверить. Если ни один узел не найден, они сообщают об этом как unsigned, unsafe.

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