Компании Red Hat и Canonical совместно подготовили документ (PDF) с рекомендациями для производителей оборудования, в котором подробно описали особенности технологии безопасной загрузки в UEFI и обозначили возможные проблемы, которые могут затруднить использование альтернативных операционных систем на новых платформах. В документе представлено несколько рекомендаций, которые помогут обеспечить производителям совместимость с установкой Linux-дистрибутивов, без нарушения требований сертификации совместимости с Windows 8, которая требует обязательного включения по умолчанию данного режима, но не настаивает на возможности его отключения.

Из возможностей, которые Red Hat и Canonical предлагают реализовать производителям оборудования называется реализация опции, предоставляющей пользователю выбор включать или нет режим безопасной загрузки. Отдельно отмечается, что такая опция должна быть легкодоступна и проста в использовании, чтобы ей мог воспользоваться любой непросвещённый пользователь. Также должны быть сведены на нет все усложнения с организацией загрузки с внешних накопителей, таких как USB Flash или CD/DVD.

Для обеспечения работы сторонних ОС одновременно с Windows 8 предлагается добавить поддержку переконфигурирования и добавления своих ключей в прошивку, т.е. возможность использования не только ключей Microsoft и OEM-производителей, но и собственных ключей, поставляемых со сторонними ОС или сгенерированными пользователем. При этом механизм управления ключами должны быть стандартизирован, един для всех платформ и предоставлять простой метод загрузки собственных систем, включая загрузку с внешних накопителей. При подключении внешнего накопителя предлагается автоматически проверять наличие на нём соответствующих ключей и выводить предложение по их установке, или предусмотреть специальный режим настройки, позволяющий управлять установленными ключами.

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

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

Среди достоинств технологии безопасной загрузки называется:

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

Недостатки режима безопасной загрузки:

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

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

• При включенной опции безопасной загрузки можно использовать только операционные системы загрузчик которых имеет валидную цифровую подпись. Так как не существует централизованного органа формирования подобных подписей, производителям операционных систем следует самим заботиться о включении открытого ключа в системные прошивки, контактируя с OEM-производителями или использовать механизмы добавления новых ключей в текущую прошивку. Даже если OEM-производители предусмотрят возможность отключения режима безопасной загрузки, изначально поставляемые с Windows 8 системы будут представлять заметный барьер для установки Linux, так как будет требоваться ручное изменение настроек по умолчанию. Реализация возможности установки собственных ключей может свести на нет защиту от вредоносного ПО, так как тогда и вредоносные программы смогут легко установить собственные ключи. Но отсутствие возможности установки своих ключей в сочетании с подходом "свой ключ для каждой ОС" потребует дополнительных издержек, которые были описаны в предыдущем пункте.
• Проблемы с юзабилити при использовании альтернативных систем. Для загрузки ОС, отличной от предустановленной по умолчанию, пользователю придется перенастраивать параметры прошивки, что по плечу только продвинутым пользователям с соответствующими техническими навыками. В конфигурациях с двумя операционными системами, пользователю придется каждый раз отключать или включать режим безопасной загрузки при переходе от основной ОС к альтернативной и наоборот;
• Проблемы с установкой обновлений операционной системы. Если обновление затрагивает компоненты, участвующие в загрузке, то они обязательно должны иметь цифровые подписи, которые не могут быть сгенерированы динамически для заданного оборудования. Обновления должны быть созданы и подписаны до предоставления пользователю, что не вписывается в текущую архитектуру загрузчика GRUB2, который генерирует специфичный для системы образ загрузчика во время установки.
• В случае утечки закрытого ключа, он с успехом может быть использован для формирования валидных цифровых подписей для вредоносного ПО. В этом случае украденный ключ должен быть заблокирован и отозван, что автоматически приведёт к неработоспособности всех драйверов и ОС, подписанных этим ключом. Т.е. связанные с данным ключом операционные системы и оборудование, после блокировки ключа, также перестанут работать.
• Необходимость формирования большой и сложной сопровождающей инфраструктуры, включая процесс поддержки ключей, авторизации ключей, формирования подписей для загрузочных образов. Поддержание подобной инфраструктуры будет не по плечу небольшим Linux-дистрибутивам.
• Появление дополнительного стимула не уведомлять разработчиков операционных систем о наличии уязвимостей, так как эти уязвимости могут быть использованы для обхода защиты и установки альтернативных редакций или модифицированных версий системы. Подобную ситуацию можно воочию наблюдать на примере распространения альтернативных прошивок для Apple iOS и Sony Playstation 3, которые базируются на эксплуатации уязвимостей, которыми не спешат делиться с производителем.

Дополнение: Организация Linux Foundation опубликовала от своего лица похожий набор рекомендаций.

Источник: http://www.opennet.ru/opennews/art.shtml?num=32162