Подпись исполняемого кода

Перейти к навигацииПерейти к поиску

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

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

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

Принципы обеспечения безопасности

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

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

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

Использование центров сертификации

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

Временные метки

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

Проблемы

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

Реализации

Windows

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

Symbian

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

iOS

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

Android

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

Использование в аппаратной части

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

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

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

Примечания

  1. ↑ 1 2 Introduction to Code Signing (Windows). msdn.microsoft.com. Дата обращения: 16 октября 2016. Архивировано 3 августа 2017 года.
  2. ↑ 1 2 3 4 5 6 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.
  3. ↑ CA/Browser Forum, "Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates" Архивная копия от 2 декабря 2016 на Wayback Machine C. 41-43.
  4. ↑ Yee B. Using secure coprocessors. // дис. – IBM. — 1994. — С. 2. Архивировано 15 мая 2013 года.
  5. ↑ Digital Signatures and Windows Installer (Windows). msdn.microsoft.com. Дата обращения: 17 октября 2016. Архивировано 30 августа 2017 года.
  6. ↑ FAQ о подписывании пакетов. getfedora.org. Дата обращения: 17 октября 2016. (недоступная ссылка)
  7. ↑ Ted Hudek. Driver Signing Policy. msdn.microsoft.com. Дата обращения: 6 декабря 2016. Архивировано 20 декабря 2016 года.
  8. ↑ 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.
  9. ↑ 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.
  10. ↑ Andrew Huang. Keeping Secrets in Hardware: The Microsoft XboxTM Case Study (англ.) // Cryptographic Hardware and Embedded Systems - CHES 2002. — Springer Berlin Heidelberg, 2002-08-13. — P. 213–227. — ISBN 3540364005. — doi:10.1007/3-540-36400-5_17. Архивировано 1 октября 2017 года.
  11. ↑ Wilkins R., Richardson B. UEFI Secure Boot in Modern Computer Security Solutions. – Tech. rep. // UEFI Forum. — 2013. — С. 7. Архивировано 2 декабря 2016 года.

Ссылки