Главная
Подпись исполняемого кода — это процесс, при котором в непосредственно исполняемые файлы или скрипты встраиваются дополнительно электронные подписи, позволяющие произвести проверку их авторства или целостность, часто с использованием хеш-сумм.
Подпись исполняемого кода помогает решить сразу несколько задач. Так как она генерируется на этапе создания исполняемых файлов, в некоторых случаях она может быть использована для предотвращения конфликтов пространств имён. Похожим образом в файлы может встраиваться информация о системе сборки, использованной при его создании, организации-создателе или авторе. Кроме того, в прикреплённую подпись может быть добавлена информация, заключающая в себе дополнительные мета-данные, такие как атрибуты, торговые марки, версии используемых компонентов.
Надёжность электронной подписи программ, как и любой другой электронной подписи, напрямую зависит от ключей положенных в основу механизма вычисления этой подписи. В случае использования инфраструктуры открытых ключей для обеспечения должной персонализированности и целостности подписи закрытый ключ целесообразно хранить в недоступном широкому кругу лиц хранилище. Компьютеры общего назначения, в общем случае, не удовлетворяют необходимым требованиям безопасности, и, как следствие, для этих целей используются специализированные аппаратные модули безопасности.
Принципы обеспечения безопасности
Часто подпись исполняемого кода производится при помощи модели с открытым-закрытым ключом. Так, например, при использовании .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 - специальном интерфейсе между операционной системой и аппаратным обеспечением. Подпись опять же проверяется для защиты аппаратуры от запуска программного обеспечения из неизвестных источников для предохранения аппаратных ресурсов от нежелательного использования.