Как стать автором
Обновить

Комментарии 21

> Secure Boot: корнем доверия является ROM-код, который проверяет подпись следующего загрузчика, загрузчик может проверить подпись ядра обратившись к Secure Monitor.

Есть ли какой-то тайный смысл загрузчику обращаться к Secure Monitor ради проверки подписи ядра? Если ключ прошит в загрузчик и не меняется, можно не обращаться ни за кодом, ни за ключами.
Да, можно и так. Но обычно стараются сделать проверку подписей централизовано. Так, например, проще менять ключи
К тому же, если бы загрузчик сам проверял подпись, то в него нужно было бы встроить кучу криптографии. А так он делает ровно один secure monitor call, где передает указатель на буфер и размер. А монитор сам парсит контейнер с образом, находит нужный ключ и проверяет подпись. При чем монитор может воспользоваться аппаратным ускорителем криптографии.
Из Secure Monitor сложнее спереть ключ. У него своя память. Он может иметь(или не иметь) функцию «Загрузить дамп» и не иметь функции «скачать дамп». Хотя в итоге, конечно, всё равно сломают…
Зачем красть public key, тут криптография с открытым ключом.
Возможно, вы хотели сказать «подменить ключ», а не «спереть».
Но и в загрузчике подменить ключ не получится, изменённый загрузчик не верифицируется через Secure Monitor
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Насколько я знаю — нет. В армовской TRM'ке явно сказано что L1 instruction cache дропается при смене режима процессора.

Судя по описанию атаки, они генерируют запись в те физические регионы памяти, где хранится код SMM. Интеловская архитектура просто опускает такие операции. ARM же сгенерит Data Abort и на это всё закончится.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
С EDK2 не работал, поэтому сказать не могу. Честно говоря даже не слышал о платформах где он используется.

Вообще на гитхабе ARM'а лежит совершенно открытый код secure monitor. OP-TEE тоже открыта. Там же на армовском гитхабе лежит и EDK2. При желании наверное можно собрать всё в кучу. Вообще, было бы круто, если бы все ARM-вендоры перешли на EFI, но пока предпосылок к этому я не вижу.
НЛО прилетело и опубликовало эту надпись здесь
Прерывание сгенерировать теоретически можно. Но надо что бы secure world настроил контроллер прерываний подходящим образом. Правильный способ попасть в secure monitor — это smc.
Инструкция SMC (Secure Monitor Call) кидает в EL3 из EL1/EL2. Попытка вызвать её из EL0 приведет Undefined Instruction Exception. Гипервизор может трапнуть SMC и таким образом виртуализировать secure monitor.
НЛО прилетело и опубликовало эту надпись здесь
Ну если вы сможете исполнять произвольный код в S-EL1 (или в EL3), то да, вся система у вас в руках. Так же как и в случае Intel SMM.
Контроллер памяти висит на шине (так же как и контроллер DMA). Шина просто не даст ему работать с защищенными регионами.

Самые злые девайсы что я знаю — это SoCи от Texas Instruments. Но они забили на мобильные чипы и теперь ориентируются на automotive. Можно взять TI DRA7xxx. Вам нужна будет HS (High Security) версия, которую купить тяжеловато. Вообще, всё что связанно с безопасностью и криптографией очень тяжело добыть.

Можно взять тот же самый Renesas, но там всё куда проще. Насколько я знаю, secure boot там не построить.
А вообще на поиграться — хватит и RPI и даже Qemu. Ещё можно глянуть список поддерживаемых платформ в доках OP-TEE. Функциональность (в этом плане) у них всех приблизительно одинакова.
НЛО прилетело и опубликовало эту надпись здесь
Тут, к сожалению, сложно.
Я сталкивался с двумя реализациями secure boot которые реально используются в продакшене — одна от TI (точнее от TrustedLogic), вторая от Qualcomm. Но и у тех и у других всё так покрыто NDA, что даже получить документацию на обычный чип нелегко. А уж на secure-версию — так вообще.
При чем, дело не только в NDA, но ещё и в экспортных ограничениях на криптографию.
НЛО прилетело и опубликовало эту надпись здесь
Точно то же самое. Четыре здоровых ARM ядра, пара маленьких, которые управляют разной мультимедией (камера, ускорение видео), плюс DSP (который к счастью никто не использует), плюс отдельная прошивка для Audio Backend. Ну и GPU тоже со своей прошивкой, куда ж без него. И просто дичайше навороченная система power management. Хорошо, что на automotive чипах это не столь актуально.
Но всё равно мне TI как то милее квалкома. Они всё-таки повернуты лицом к комьюнити.
Тут был вопрос от аккаунта read&comment по поводу обновления прошивки и образов tz, sbl1, sbl2.
К сожалению кнопка «отклонить» очень похожа на «ответить». И я случайно отклонил этот комментарий. Прошу прощения. Можете повторить его ещё раз, если хотите.

По сути вопроса — да, эти образы представляют собой цепочку загрузчиков. Но это не значит на 100% что активен secure boot. Загрузчики могут проверять, а могут и не проверять подпись следующего в цепочке. Всё зависит от производителя прошивки.
Немного в обратной хронологии, но спасибо за ответ.

Сам вопрос для понимания был: «Наличие в обновлении прошивки образов tz, sbl1, sbl2 и т.д. говорит о наличии цепочки загрузчиков и как следствие использовании secure boot?»
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории