Збереження захищеного ключа у пам'яті вбудованого пристрою


10

Я працюю над вбудованим пристроєм, який надсилає / приймає дані та зберігає їх у режимі шифротексту (зашифрований режим). Тепер, який найкращий підхід для зберігання ключів (я використовував ARM CORTEX M серії MCU)?

1-Зберігання клавіш у пам'яті SRAM та в кожній послідовності завантаження введіть ключі до вбудованого MCU та зберігайте їх у пам'яті SRAM. Я вважаю, що це найкраще, тоді, коли проникнення сенсору MCU (за допомогою сенсора тампона або ...), воно може швидко стерти SRAM та відновлюватись. Недолік: якщо зловмисник успішно передає тампер і доступ до пристрою, наскільки безпечна пам'ять SRAM (проти виведення коду). Я не можу знайти можливості захисту цієї пам'яті в MCU.

2-Створення ключів і збереження їх у флеш-пам'яті в програмуванні MCU. Підтримка CRP-флеш-пам’яті MCU (захист від зчитування коду), яка запобігає майнінгу коду, і за допомогою його внутрішнього двигуна AES та двигуна RNG (генерація випадкових чисел) ми можемо зробити випадковий ключ та зашифрувати флеш-пам’ять і зберегти цей випадковий ключ у OTP ( одноразово програмована пам’ять - 128-бітна зашифрована пам'ять), тоді при виконанні коду ми декодуємо флеш-пам’ять за допомогою клавіші RNG та доступ до початкового ключа та кодів. Недолік: ключі, що зберігаються в енергонезалежній пам’яті, несанкціоновані роботи виявляться марними, а зловмисник матиме багато часу, щоб вимикати ключі.

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

Я вважаю LPC18S57FBD208 (кора м3 з 1 Мб флеш-пам’яті, 180 МГц, 136 КБ SRAM, 16 КБ EEPROM та TFT РК-контролер, який мені потрібен для керування 7-дюймовим РК-дисплеєм TFT та 128-бітним криптовалютою AES), чи є ще якісь кращі пропозиції?

Відповіді:


18

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

  1. SRAM - це найбезпечніше місце для зберігання ключів, але ви ніколи не повинні вводити їх із зовнішнього світу. ВИНАГО вони повинні створюватися в межах процесора під час завантаження. Робити що-небудь інше, миттєво збиває з себе інше - це автоматично небезпечно.

  2. Не зберігайте ключі в енергонезалежній пам'яті, ви в цьому правильно. Не має значення, чи захищаєте ви EEPROM або флеш-пам’ять від зчитування. Цей запобіжник, захищений від читання коду, легко повернути назад. Зловмиснику потрібно лише знезаразити (видалити або хімічно протравити чорну епоксидну упаковку, щоб викрити силіконову матрицю всередині). На цьому етапі вони можуть прикрити частину штампу, що не є енергонезалежними елементами пам’яті (ці розділи дуже регулярні, і хоча окремі осередки пам’яті набагато малі, щоб побачити, більша структура може бути) і невеликий шматочок чогось непрозорий для ультрафіолетового покриття маскується над цим розділом. Тоді зловмисник може просто світити УФ-світло на мікросхемі протягом 5-10 хвилин і скидати всі запобіжники, включаючи запобіжник CRP. Тепер пам'ять OTP може читати будь-який стандартний програміст.

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

Для надійності ключі потрібно стирати, а не приховувати.

  1. Ні, з тих же причин, зазначених вище.

Тепер, до варіанту 4:

  1. Просто використовуйте шифрування. Розподіл ключів - це вирішена проблема. Тому використовуйте це легко доступне рішення. Мікросхема повинна використовувати RNG, і слід враховувати різні міркування для забезпечення достатнього запасу ентропії, а завантажувач повинен завантажуватися безпосередньо в програму, яка генерує необхідні секретні ключі, які повинні бути загальними реєструється та переміщується безпосередньо в SRAM, де вони залишаться до стирання.

Однак існує проблема, яка полягає в тому, що нічого, крім процесора, не має поняття, що таке секретний ключ. Немає проблем: використовуйте криптографію відкритого ключа. Те, що ви зберігаєте в пам'яті OTP, є вашим відкритим ключем. Цей ключ може прочитати будь-хто, ви можете розмістити його на обміні стеками, ви можете пофарбувати його на борту танкера маслом великими 5 футами, це не має значення. Чудова річ у криптографії відкритого ключа полягає в тому, що вона асиметрична. Ключ для шифрування чогось не може його розшифрувати, для цього потрібен приватний ключ. І навпаки, ключ для розшифровки чогось зашифрованого відкритим ключем не може бути використаний для шифрування чогось. Отже, процесор генерує секретні ключі, використовує ваш збережений відкритий ключ для РЕКЛАМУВАННЯ секретних ключів і просто надсилає його через USB або RS232 або все, що вам потрібно. Для читання секретного ключа потрібен ваш приватний ключ, які не потрібно зберігати, надсилати чи взагалі взагалі брати участь у чіпі. Після того, як секретний ключ буде розшифрований за допомогою приватного ключа (в іншому місці, за межами чіпа), ви налаштовані. У вас надійно переданий секретний ключ, генерований цілком у мікросхемі, не зберігаючи нічого, крім відкритого ключа - який, як було сказано раніше, взагалі не потрібно захищати від читання.

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

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

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

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

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

Створіть ключі та зберігайте їх якомога коротше.


Дуже дякую, шановний Metacollin, що очистив мене. Але мій проект складається з багатьох читачів (містять mcu) та багатьох цільових MCU, кожен читач повинен вміти читати будь-які цілі, а будь-які цілі повинні бути в змозі прочитати будь-хто з читачів. Тому з цього я думаю, що вони повинні погодитися з унікальним ключем для транспортування даних. і виходячи з вашої відповіді, я думаю, що не так вже й багато розбіжностей, наприклад, LPC18S57 захищеної кори м3 і STM32F429 загальної кори кори 4 і навіть LPC1788 загальної кори м3 (дешевший вибір), я не роблю надто секретний проект, але я хочу це зробити це так безпечно, наскільки я можу.
Махмуд Хоссейніпур

2
Ваша заява про те, що "ключ AES легко відновити", принаймні сумнівна. Я розумію принцип роботи методики з'ясування того, що відбувається в процесорі, виходячи з його поточного споживання. Однак передбачається, що шифрування та дешифрування - це єдине, над чим працює процесор. Однак у більшості додатків є лише 1 процесор, який працює над купою завдань одночасно. Під час одного блоку шифрування AES може статися десятки або сотні переривань, що унеможливлює пошук ключа, виходячи з поточних піків.
bakcsa83

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

The wonderful thing about private key cryptography is that it is asymmetric. Хоча з вашої публікації видно, що ви це знаєте, я згадаю це для інших читачів ... s / private / public у цитаті вище.
Радіан

Можливо, ви зможете захистити канал між будь-якими двома пристроями, використовуючи метод 4, однак, не маючи певної форми загальної таємниці, ви не можете гарантувати справжність пристрою, з яким ви спілкуєтесь. Якщо ваш випадок використання вимагає автентифікації, вам краще не обмінятися ключами, ніж є, якщо ви просто зберігаєте одну загальну таємницю у спалах. Якщо вам потрібна краща безпека, слід використовувати криптовалюту.
Грег
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.