надежное хранение и использование ключей во встроенной системе

Я использую микропроцессор - PIC32MZ2048efm144 MCU, который получает команды, зашифрованные с определенным ключом , расшифровывает их и выполняет команду. Зашифрованные команды хранятся в автономном режиме , поэтому я не могу просто изменить ключ, когда захочу. Ключ ИСПРАВЛЕН . Команды зашифрованы сервером и загружены по телефону . Телефон отправляет зашифрованные команды на MCU позже, когда он не в сети . Команды шифруются до того, как телефон сообщит их MCU, поэтому сеансовый ключ невозможен.

Мне разрешено подключать внешний модуль шифрования / дешифрования к PIC, но тогда данные будут проходить расшифрованные как минимум в одном направлении.

Предлагаемое решение: хранение защищенного ключа в памяти встроенного устройства

использует одноразовые ключи для шифрования, но мне нужно хранить один суперсекретный ключ

Мой работодатель требует, чтобы ключи были недоступны, поэтому физическая защита, помимо защиты, предоставляемой защищенными модулями памяти и MCU, не рассматривается.

Предполагая, что военное оборудование не используется, есть ли какие-нибудь известные решения, которые вы, ребята, знаете и можете порекомендовать?

Заранее спасибо!

— Sonja
источник

Можете ли вы объяснить больше о том, что вы пытаетесь предотвратить? Что делает микропроцессор? Как вы думаете, использование открытого / закрытого ключа может работать? Если вы сохранили закрытый ключ на микропроцессоре? Затем устройства, отправляющие команды, будут создавать сеансовый ключ, шифровать его с помощью открытого ключа и отправлять вам. После этого обе стороны используют сеансовый ключ. Что произойдет, если у злоумышленника будет открытый ключ (который, хотя он и называется «открытым», на самом деле не обязательно должен быть открытым)?

— Mkeith

@mkeith Я обновил вопрос, надеюсь, это поможет :)

— Соня

Поскольку вы выбрали этот PIC, почему бы не использовать «Программно защищенное хранилище ключей», которое он предоставляет? Он имеет свой собственный встроенный криптомодуль!

— pjc50

Я не думаю, что вы четко оценили ценность своего секрета. Кажется, вы хотите дешевый и надежный метод (который я думаю, неизвестно). Спросите уточнить, что должно быть возможно после обнаружения уязвимости в этом первом решении. Подписанные по воздуху обновления прошивки были бы моей первой необоротной особенностью ... Это системная проблема - всегда.

— Шон Хулихейн

Хорошо, если память PIC защищена (и даже имеет модуль хранения ключей), почему бы не использовать простое шифрование AES? Я знаю, что это симметрично, но если сервер защищен (что мы должны предположить), то здесь нет риска - или есть?

— Ян Дорняк

Ответы:

Извините, этот ответ на самом деле не решит вашу проблему. Но это слишком долго, чтобы уместиться в комментарии, и это позволит вам правильно переосмыслить вашу проблему (потому что, как я думаю, она ошибочна).

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

Например:

Вы говорите: «PIC32MZ2048efm144 (MCU) получает команды, зашифрованные с определенным ключом, расшифровывает их и выполняет команду». Я полагаю, что результатом выполнения команды является переключение некоторых GPIO для активации чего-либо.

Тогда почему вы боитесь, что, возможно, некоторые данные будут расшифрованы между MCU и модулем шифрования / дешифрования? Хакер, имеющий доступ к аппаратному обеспечению для просмотра расшифрованных команд, в любом случае сможет напрямую воздействовать на GPIO на MCU и так же легко «приводить в действие».

Второй пример:

Использование своевременных ключей является идеей. Но, как вы говорите, где вы храните главный мастер-ключ, используемый для генерации одноразовых ключей? Вы столкнетесь с теми же вопросами, что и в исходной задаче.

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

Что делает систему безопасной?

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

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

И так далее. По сути, вы должны начать с определения того, что хакер не сможет сделать, и отработать все ваше решение оттуда. Например, можно ли поместить всю вашу систему в надежную, физически защищенную коробку? В этом случае вы можете свободно иметь дешифрованные команды, проходящие через внутреннюю шину.

Вы не можете создать безопасную систему, не зная, что это не может сделать хакер. Вы не сказали нам это. Поэтому мы не можем предложить полное решение.

— тусклый
источник

Прежде всего, спасибо за продуманный ответ! Я обновил вопрос так, как мне кажется, ответит вам :)

— Соня,

Что я беру из редактирования вашего поста, так это то, что только ключи должны быть защищены. Фактические результаты команд не должны быть защищены. В этом случае поместите ключи во внешний защищенный модуль, как вы предложили, и примите, что расшифрованные команды можно увидеть в открытом виде. Если мое предложение по какой-то причине недействительно, найдите время, чтобы подробно объяснить, что приемлемо, а что нет . Нам нужно не просто еще одно предложение в вашем посте. Нам нужна полная картина вещи. В самом деле.

— тусклый

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

— тусклый

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

— hildred
источник

Расшифровка данных производится с помощью закрытого ключа (и шифрование с открытым ключом). В противном случае это означает, что каждый может расшифровать (так как каждый имеет доступ к открытому ключу), что может стать проблемой. Следовательно, вам нужен закрытый ключ, чтобы быть в устройстве. Итак, теперь, как поставить закрытый ключ в устройстве? Ну, вернемся к исходной задаче ...

— тусклый

возможность расшифровывать команды не позволяет создавать новые с нуля, поэтому наличие открытого ключа каким-либо образом не так уж и

— сложно

Обычно это то же самое, что криптографическое подписание; что имеет тот недостаток, что если у кого-то есть открытый ключ (на самом деле он не должен быть открытым, он может храниться так же надежно, как и симметричный ключ), он может расшифровать все; но, как говорит masterX244, вы обычно не можете создавать / подписывать новые команды. Я думаю, что это хорошее решение.

— CoderTao

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

Если первое, вы сталкиваетесь с почти невозможной задачей: ваше устройство должно расшифровать команды для их выполнения - владение устройством PIC означает владение ключом дешифрования. Злоумышленник может либо извлечь ключ (хранящийся в устройстве PIC, которым он обладает), либо просто подождать, пока ваша прошивка не расшифрует команды, а затем перехватить их из памяти.

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

— Стивен С. Сталь
источник