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

Подпись исполняемого кода помогает решить сразу несколько задач. Так как она генерируется на этапе создания исполняемых файлов, в некоторых случаях она может быть использована для предотвращения конфликтов пространств имён. Похожим образом в файлы может встраиваться информация о системе сборки, использованной при его создании, организации-создателе или авторе. Кроме того, в прикреплённую подпись может быть добавлена информация, заключающая в себе дополнительные метаданные, такие как атрибуты, торговые марки, версии используемых компонентов.CA/Browser Forum, "Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates" C. 41-43.

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

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

Особенно полезна подпись исполняемого кода в тех случаях, когда в процессе исполнения не доступна полная информация о том, откуда получен конкретный исполняемый файл, или отсутствует исчерпывающая информация о контексте, в котором производится запуск. Примером таких случаев может служить распространение обновлений через доступные, не контролируемые разработчиком каналы (интернет, прочие электронные носители информации). Так, например, Windows, Mac OS и некоторые дистрибутивы Linux внедряют в файлы своих обновлений и патчей дополнительный код, позволяющий принимающей операционной системе убедиться как в их целостности в целом, так и для идентификации изменений в них третьими лицами в процессе передачи.

В операционной системе Windows аналогичным образом применяется подпись драйверов.

Использование центров сертификации В процессе создания исполняемого файла разработчик вправе сам выбирать, каким конкретно образом осуществлять подпись. Наиболее распространённым является получение сертификата в центре сертификации. Наличие в файле такой подписи способно только подтвердить неизменность файла после прохождения сертификации по пути до места использования. Пользователь может как доверять полученной информации от конкретного центра, так и считать его небезопасным. Кроме того, большинство вредоносных программ оказывается подписанным. Большинство операционных систем предоставляет встроенные центры сертификации (DigSig, Microsoft Authenticode), однако, они не являются обязательными. В действительности, существует самостоятельный рынок сертификации с богатым набором расценок и условий предоставления услуги.

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

Проблемы Основной проблемой сертификации исполняемых файлов является тот факт, что сама по себе подпись файла, свидетельствующая о неизменности файла, не гарантирует его безопасности. Подпись показывает лишь, что файл никем не был изменён после прохождения процедуры подписи. Авторитетность автора же центром сертификации каким-либо образом не проверяется. Более того, примерно 90 % потенциально небезопасных программ и 10 % вредоносных программ оказываются подписанными и успешно проходят проверки сертификатов.

Реализации

Windows Основным средством сертификации в Windows является специализированный центр сертификации - Microsoft Authenticode. Он может применяться для подписывания как исполняемых файлов, так и драйверов. Так как драйверы чаще всего тесно взаимодействуют с ядром операционной системы, их проверка и сертификация проводится совместно с аппаратным обеспечением с использованием WHQL. До 64-битной версии Vista драйверы устройств обрабатывались различным образом в зависимости от разрядности системы и от типа драйвера (пользовательский, режим работы с ядром). Однако, после её выпуска стало необходимо подписывать для загрузки драйверы обоих типов. Кроме того, драйвер, работающий с ядром, должен заключать в себе цепочку родительских сертификатов, непременно ведущую к корневому сертификату Microsoft.

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

iOS В случае приложений для iOS все приложения распространяются и сертифицируются полностью под контролем Apple. Сам процесс написания приложения требует регистрации учётной записи разработчика в App Store, после чего становится доступным загрузка SDK. Готовое приложение также проходит проверку и оценку безопасности кода перед помещением его в App Store. Однако, существует метод запуска неподписанных приложений в обход Apple - так называемый Jailbreak.

Android В отличие от iOS, размещение приложения в Android Maket требует от автора только имени разработчика, email-адреса, адреса веб-сайта и контактного номера. Никаких дополнительных проверок не требуется. SDK также является открытым, предоставляет возможность самостоятельной подписи приложений и находится в свободном доступе. Google удаляет приложения из Android Market только при нарушении условий использования или при подтверждении их вредоносности, но они по-прежнему могут запускаться и распространяться другими способами, вне Android Market. С другой стороны, все требуемые небезопасные операции должны быть перечислены в подписи - файле manifest. Конечный пользователь всегда уведомляется о них перед установкой приложения и может отказаться от продолжения.

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

Аппаратная проверка цифровой подписи производится, например, в игровой приставке Xbox. Главной целью такой подписи является защита лицензионного контента от свободного копирования и распространения с использованием нелицензированных носителей.

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

Примечания

Ссылки

Apple Code Signing Guide Microsoft Introduction to Code Signing Debian Security Infrastructure Strong Distribution HOWTO How to Verify if Your Code Signing Certificate is Installed? Категория:Электронная подпись