Плохо ли хранить сертификаты на внешней памяти?

Мы работаем над AWS-IoT, используя микроконтроллер STM32.

До сегодняшнего дня мы записывали сертификаты на флэш-память и блокировали флэш-память от внешнего чтения. Поскольку код приложения увеличивается, мы получаем все меньше места на флэш-памяти, поэтому мы планировали перемещать сертификат извне на SD-карту / EEPROM и считывать всякий раз, когда это было необходимо, перед подключением к AWS-IoT.

Заметки:

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

• Разрешено публиковать только 2 канала (это имя и канал подачи данных), который подключен к процессору данных, который будет игнорировать любые мошеннические пакеты, поступающие на него.

• Если объект публикует / подписывается на какую-либо другую тему, AWS немедленно отключит его.

Если я обнаружу, что устройство украдено / мошенническое, мы деактивируем ключ с сервера.

Что может сделать эксплойтер с сертификатами (RootCA, ключ сервера, ключ клиента)?

Является ли плохой практикой хранение сертификатов для такого варианта использования на внешнем хранилище, доступ к которому может получить эксплуататор?

Вы упоминаете «сертификаты», но из контекста, я думаю, вы имеете в виду две разные вещи.

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

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

  Этот закрытый ключ лучше не разглашать.

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

  • Нажмите обновление прошивки для устройства.
  • Нажмите на обновление конфигурации устройства.
  • Заставьте устройство загрузить свои данные в другое место.

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

Если у вас есть как минимум 128 бит хранилища, которые вы можете записать хотя бы один раз, что у вас есть, и даже больше, вы можете реализовать решение для безопасного удаленного хранилища. Используйте ограниченное пространство на устройстве для хранения секретного ключа. Этот секретный ключ должен быть уникальным для каждого устройства; STM32 имеет аппаратный RNG, поэтому вы можете сгенерировать его на устройстве во время первой загрузки. Если на вашем устройстве нет аппаратного RNG, вы можете сгенерировать ключ в безопасном месте вне устройства и вставить его на устройство.

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

Шифрования с проверкой подлинности достаточно, чтобы гарантировать конфиденциальность и подлинность данных, но это не совсем гарантирует их целостность .

• Если имеется более одного фрагмента данных, то, когда устройство считывает фрагмент данных, оно не может быть уверенным, что это правильный фрагмент. Решение включает в себя уникальный идентификатор в содержании каждого блока (например , начинать каждый кусок с одной из "AWS-IoT private key.", "configuration CA certificate.", "publishing server CA certificate.", "user personal data.", ...).
• Если вы обновляете данные в какой-то момент, то, когда вы читаете их обратно, вы не можете быть уверены, что получаете последнюю версию этих данных. Если кто-то может изменить внешнее хранилище, он не может поместить поддельные данные, потому что это не пройдет проверку подлинности, но он может восстановить старые данные, потому что то, что раньше было подлинным, все еще является подлинным. Решение: в каждый блок данных, который хранится извне, включите счетчик, который вы увеличиваете каждый раз, когда пишете новую версию этого блока. Когда вы читаете чанк обратно, убедитесь, что это ожидаемая версия.

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

Немного контекста

Поскольку вы используете MQTT с AWS IoT, вы должны использовать сертификаты X.509 для аутентификации и безопасности. У Amazon есть небольшое руководство о том, как вы должны защищать свои сертификаты, поэтому я процитирую это здесь:

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

Поскольку вы в настоящее время используете защиту от чтения STM32 (RDP), у всех, кроме самых решительных злоумышленников, будут проблемы с доступом к вашим сертификатам в вашей текущей схеме:

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

• Уровень 0 - Без защиты (по умолчанию)
• Уровень 1 - флэш-память защищена от чтения путем отладки или сброса кода с помощью загруженного в ОЗУ кода
• Уровень 2 - Все функции отладки отключены

Будет ли внешнее хранилище безопасным?

Это, вероятно, не так безопасно . Если секретный ключ вашего клиента украден, злоумышленник может отправить данные, которые, как представляется, с вашего устройства, а на самом деле это не так. Хотя неясно, какие данные вы отправляете, любые ненадежные данные могут представлять угрозу безопасности.

Какие биты мне нужно держать в секрете?

При создании сертификата устройства в AWS IoT вы должны увидеть изображение, подобное этому:

^{Изображение со страницы « Создание и активация сертификата устройства» документации по IoT AWS.}

Закрытый ключ - это то, что вам действительно нужно сохранить ... в секрете , и его следует обязательно хранить в защищенной от чтения памяти, если это возможно. Открытый ключ и сертификат предназначены для совместного использования, поэтому, если вам не хватает места, вы можете безопасно переместить их во внешнее хранилище. Вы можете получить немного больше контекста на странице. Как работает SSL / TLS? на бирже стека информационной безопасности и криптографии с открытым ключом в Википедии. Я думаю, что оказал бы вам медвежью услугу, если бы я не включил это изображение, чтобы объяснить, почему закрытый ключ должен быть секретным:

,

^{Изображение из Википедии , опубликовано в открытом доступе.}

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

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

Вы также спросили, что произойдет, если злоумышленник украл сертификат RootCA. Если кто-то похитит закрытый ключ AWS IoT , это будет иметь катастрофические последствия, но сертификат RootCA на вашем устройстве не таков . То, RootCA.crtчто Amazon дает вам, является полностью публичным , и его цель состоит в том, чтобы вы могли убедиться, что на вас никто не атакует (скорее всего, человек посередине, притворяющийся сервером AWS IoT).

Какой ущерб может нанести взломанное устройство?

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

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

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

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

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

Если отдельный ключ извлекается из одного устройства и начинает злоупотреблять или обнаруживаться в объеме трафика, который должен быть из нескольких неавторизованных клонов, то вы можете запретить этот ключ на стороне сервера.

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

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

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

Исходя из этого, единственным ключом, который безопасно открыть во внешнем запоминающем устройстве, является открытый ключ сервера. Изменение этого параметра (3) позволит принудительно подключить ваше устройство к мошеннической службе AWS, доступ к которой, предположительно, затруднен. Даже утечка только этого ключа может позволить кому-то отслеживать или подделывать некоторые передачи (например, если уровень TLS может быть каким-то образом понижен).

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