Чи погана практика зберігати сертифікати на зовнішній пам'яті?

Ми працюємо над 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, ви повинні побачити таке зображення:

^{Зображення зі сторінки Створення та активація сертифіката пристрою документації AWS IoT.}

Приватний ключ - це те, що вам справді потрібно зберегти ... приватним , і він, безумовно, повинен зберігатися в пам'яті, захищеній від читання. Публічний ключ та сертифікат призначені для спільного доступу, тому якщо у вас не вистачає місця, ви можете безпечно перемістити їх у зовнішній сховище. Ви можете отримати трохи більше контексту на сторінці Як працює SSL / TLS? на інформаційній стеці інформаційного забезпечення та криптографії відкритого ключа у Вікіпедії. Думаю, я зробив би вам послугу, якби я не включив це зображення, щоб пояснити, чому приватний ключ повинен бути секретним:

.

^{Зображення з Вікіпедії , оприлюднене у загальнодоступне надбання.}

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

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

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

Яку шкоду може зламати пристрій?

Викрадений пристрій може виконувати лише ті дії, які вказані в політиці . Намагайтеся слідувати принципу найменшої пільги ; надайте вашому пристрою лише ті привілеї, які йому абсолютно потрібні , тому якщо найгірше трапиться, він не може занадто сильно загрожувати. Для вашого конкретного випадку:

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

Добре. Будь-яка атака повинна бути виділена лише на дві теми MQTT, які пристрій може опублікувати, щоб не завдати великої шкоди.

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

Особливо, якщо ви зберігаєте ключі в окремій пам'яті, щоб вони перетинали стандартний електричний інтерфейс між мікросхемами, то вони повинні бути лише ключами, які вже безпечно публікувати, або унікальними для конкретного фізичного примірника пристрою.

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

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

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

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

Виходячи з цього міркування, єдиним ключем, який можна безпечно викрити у зовнішньому пристрої пам'яті, є відкритий ключ сервера. Зміна цього (3) дозволить примусити ваш пристрій підключитися до шахрайської служби AWS, до якої, ймовірно, важко отримати доступ інженеру. Навіть протікання лише цього ключа може дозволити комусь прослуховувати або підробляти деякі передачі (наприклад, якщо рівень TLS можна якось знизити).

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