Подпись исполняемого кода: различия между версиями
Shishpan (обсуждение | вклад) Внесена основная информация. Чуть позже планируется улучшение внешнего вида и завершение незаконченных разделов, возможно, иллюстраций. |
(нет различий)
|
Версия от 18:40, 21 октября 2016
 | Это заготовка статьи. Помогите Википедии, дополнив её. |
Подпись исполняемого кода — это процесс, при котором в непосредственно исполняемые файлы или скрипты встраиваются дополнительно электронные подписи, позволяющие произвести проверку их авторства или целостность, часто с использованием хэш-сумм[1].[2]
Подпись исполняемого кода помогает решить сразу несколько задач. Так как она генерируется на этапе создания исполняемых файлов, в некоторых случаях она может быть использована для предотвращения конфликтов пространств имён. Похожим образом в файлы может встраиваться информация о системе сборки, использованной при его создании, организации-создателе или авторе. Кроме того, в прикреплённую подпись может быть добавлена информация, заключающая в себе дополнительные мета-данные, такие как атрибуты, торговые марки, версии используемых компонентов.[3]
Надёжность электронной подписи программ, как и любой другой электронной подписи, напрямую зависит от ключей положенных в основу механизма вычисления этой подписи. В случае использования инфраструктуры открытых ключей для обеспечения должной персонализированности и целостности подписи закрытый ключ целесообразно хранить в недоступном широкому кругу лиц хранилище. Компьютеры общего назначения, в общем случае, не удовлетворяют необходимым требованиям безопасности, и, как следствие, для этих целей используются специализированные аппаратные модули безопасности.[4]
Безопасность
Часто подпись исполняемого кода производится при помощи модели с открытым-закрытым ключом. Так, например, при использовании .NET Framework разработчик может либо использовать сгенерированный, уникальный для него или для конкретного файла, закрытый ключ, либо использовать свой механизм для его вычисления, используя в свою очередь для этого какой-либо центр сертификации.[1]
Особенно полезна подпись исполняемого кода в тех случаях, когда в процессе исполнения не доступна полная информация о том, откуда получен конкретный исполняемый файл, или отсутствует исчерпывающая информация о контексте, в котором производится запуск. Примером таких случаев может служить распространение обновлений через доступные, не контролируемые разработчиком каналы (интернет, прочие электронные носители информации). Так,например, Windows, Mac OS и некоторые дистрибутивы Linux внедряют в файлы своих обновлений и патчей дополнительный код, позволяющий принимающей операционной системе убедиться как в их целостности в целом, так и для идентификации изменений в них третьими лицами в процессе передачи.[5][6]
В операционной системе Windows аналогичным образом применяется подпись драйверов.
Использование центров сертификации
В процессе создания исполняемого файла разработчик в праве сам выбирать, каким конкретно образом осуществлять подпись. Наиболее распространённым является получение сертификата в CA. Само по себе наличие в файле такой подписи не гарантирует безопасности, оно способно только подтвердить неизменность файла после прохождения сертификации по пути до места использования. Пользователь может, как доверять полученной информации от конкретного CA, так и считать его небезопасным. Кроме того, большинство вредоносных программ оказываются подписанными. Большинство операционных систем предоставляет встроенные центры сертификации (DigSig, Microsoft Authenticode), однако, они не являются обязательными. В действительности, существует самостоятельный рынок сертификации с богатым набором расценок и условий предоставления услуги. [2]
Time-stamping
Timestamp является своего рода проставлением временных отметок доверенными организациями в момент изменения данных в файле. Особенно полезными эти отметки становятся, когда сертификат безопасности у некоторого файла отзывается. Так, например, если последняя отметка об изменении была произведена раньше, чем сертификат был отозван, валидация файла может проходить успешно. Благодаря этому около 70% подписанных вредоносных файлов с отозванным сертификатом успешно используются, проходя соответствующие проверки. Оставшаяся часть файлов оказывается подписанной с использованием уже недействительных сертификатов.[2]
Проблемы
Основной проблемой сертификации исполняемых файлов является тот факт, что сама по себе подпись файла, свидетельствующая о неизменности файла, не гарантирует его безопасности. Подпись показывает лишь, что файл не был никем изменён после прохождения процедуры подписи. Авторитетность автора же центром сертификации каким-либо образом не проверяется. Более того, примерно 90% потенциально небезопасных программ и 10% вредоносных программ оказываются подписанными и успешно проходят проверки сертификатов.[2]
Реализации
Windows
Основным средством сертификации в Windows является специализированный центр сертификации - Microsoft Authenticode. Он может применяться для подписывания как исполняемых файлов, так и драйверов. Так как драйверы чаще всего тесно взаимодействуют с ядром операционной системы, их проверка и сертификация проводится совместно с аппаратным обеспечением с использованием WHQL. До 64-х битной версии Vista драйверы устройств обрабатывались различным образом в зависимости от разрядности системы и от типа драйвера (пользовательский, режим работы с ядром). Однако, после её выпуска стало необходимо подписывать для загрузки драйверы обоих типов. Кроме того, драйвер, работающий с ядром, должен заключать в себе цепочку родительских сертификатов, непременно ведущую к корневому сертификату Microsoft.[2]
Symbian
Для получения специализированных возможностей API проверка приложений происходит через доверенную организацию, подконтрольную непосредственно Symbian. Однако, разработчик может сам подписывать сертификат в обход доверенной организации для увеличения скорости распространения приложения. Такой способ не является достаточно безопасным, так как всегда существует вероятность распространения вредоносного кода с самоподписанным сертификатом.[7] Кроме того операционная система предоставляет конечному пользователю возможность решать, доверять ли опасные операции сертифицированному приложению, запрашивать подтверждение каждой из них или запрещать их вовсе.[8]
iOS
В случае приложений для iOS все приложения распространяются и сертифицируются полностью под контролем Apple. Сам процесс написания приложения требует регистрации учётной записи разработчика в App Store, после чего становится доступным загрузка SDK. Готовое приложение также проходит проверку и оценку безопасности кода перед помещением его в App Store. Однако, существует метод запуска неподписанных приложений в обход Apple - так называемый Jailbreak.[7]
Android
В отличие от iOS, размещение приложения в Android Maket требует от автора только имени разработчика, email адреса, адреса веб-сайта и контактного номера. Никаких дополнительных проверок не требуется. SDK также является открытым, предоставляет возможность самостоятельной подписи приложений и находится в свободном доступе.[7] Google удаляет приложения из Android Market только при нарушении условий использования или при подтверждении их вредоносности, но они по-прежнему могут запускаться и распространяться другими способами, вне Android Market. С другой стороны, все требуемые небезопасные операции должны быть перечислены в подписи - файле manifest. Конечный пользователь всегда уведомляется о них перед установкой приложения и может отказаться от продолжения. [8]
Использование в аппаратной части
 | Этот раздел не завершён. |
Примечания
- ↑ 1 2 Introduction to Code Signing (Windows). msdn.microsoft.com. Дата обращения: 16 октября 2016.
- ↑ 1 2 3 4 5 Platon Kotzias, Srdjan Matic, Richard Rivera, Juan Caballero. Certified PUP: Abuse in Authenticode Code Signing // Proceedings of the 22Nd ACM SIGSAC Conference on Computer and Communications Security. — New York, NY, USA: ACM, 2015-01-01. — С. 465–478. — ISBN 9781450338325. — doi:10.1145/2810103.2813665.
- ↑ Hendric, William (2015). "A Complete overview of Trusted Certificates - CABForum"
- ↑ Larry Seltzer, Securing Your Private Keys as Best Practice for Code Signing Certificates
- ↑ Digital Signatures and Windows Installer (Windows). msdn.microsoft.com. Дата обращения: 17 октября 2016.
- ↑ FAQ о подписывании пакетов. getfedora.org. Дата обращения: 17 октября 2016.
- ↑ 1 2 3 Inkyung Jeun, Kwangwoo Lee, Dongho Won. Enhanced Code-Signing Scheme for Smartphone Applications (англ.) // Future Generation Information Technology / Tai-hoon Kim, Hojjat Adeli, Dominik Slezak, Frode Eika Sandnes, Xiaofeng Song, Kyo-il Chung, Kirk P. Arnett. — Springer Berlin Heidelberg, 2011-12-08. — P. 353–360. — ISBN 9783642271410, 9783642271427. — doi:10.1007/978-3-642-27142-7_41.
- ↑ 1 2 David Barrera, Paul Van Oorschot. Secure Software Installation on Smartphones (англ.) // IEEE Security & Privacy Magazine. — 2010-12-15. — Т. 9, вып. 3. — С. 42–48. — ISSN 1540-7993. — doi:10.1109/msp.2010.202.