Хранение безопасного ключа в памяти встроенного устройства


10

Я работаю на встроенном устройстве, которое отправляет / получает данные и хранит их в режиме шифрованного текста (режим шифрования). Каков наилучший подход для хранения ключей (я использовал микроконтроллер ARM CORTEX серии M)?

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

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

3-х запоминаемый ключ в памяти EEPROM, комбинация из 2 описанных выше подходов, ключ хранится в энергонезависимой памяти, но при обнаружении несанкционированного доступа EEPROM стирается.

Я рассматриваю LPC18S57FBD208 (кортекс m3 с 1 МБ флэш-памяти, 180 МГц, 136 КБ SRAM, 16 КБ EEPROM и контроллер TFT LCD, который мне нужен для управления 7-дюймовым TFT LCD и 128-битным криптографическим двигателем AES), для этого есть какие-либо другие лучшие предложения?

Ответы:


18

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

  1. SRAM - самое безопасное место для хранения ключей, но вы никогда не должны вводить их из внешнего мира. Они должны ВСЕГДА генерироваться внутри процессора во время загрузки. Любые другие действия мгновенно лишают законной силы все остальное - это автоматически небезопасно.

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

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

Чтобы быть в безопасности, ключи должны быть стерты, а не скрыты.

  1. Нет, по тем же причинам, что и выше.

Теперь перейдем к варианту 4:

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

Однако существует проблема, заключающаяся в том, что ничто, кроме процессора, не имеет никакого представления о том, что такое секретный ключ. Нет проблем: используйте криптографию с открытым ключом. То, что вы храните в памяти OTP, является вашим открытым ключом. Этот ключ может быть прочитан кем угодно, вы можете разместить его на стеке, вы можете нарисовать его на боковой части нефтяного танкера буквами высотой 5 футов, это не имеет значения. Замечательная вещь в криптографии с открытым ключом состоит в том, что она асимметрична. Ключ для шифрования чего-либо не может расшифровать его, для чего требуется закрытый ключ. И наоборот, ключ для расшифровки чего-либо, зашифрованного открытым ключом, не может быть использован для шифрования чего-либо. Таким образом, процессор генерирует секретные ключи, использует ваш сохраненный открытый ключ для шифрования секретных ключей и просто отправляет их через USB или RS232 или что-либо еще. Чтение секретного ключа требует вашего личного ключа, которые не должны быть сохранены, отправлены или когда-либо связаны с чипом. Как только вы расшифруете секретный ключ своим закрытым ключом (в другом месте, за пределами чипа), все готово. У вас есть надежно переданный секретный ключ, который был ПОЛНОСТЬЮ СОЗДАН внутри чипа, без необходимости хранить что-либо, кроме открытого ключа - который, как было указано ранее, вообще не нуждается в защите от чтения.

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

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

Это побеждает зашифрованные загрузчики AES-256 на «безопасных» криптопроцессорах, и это не так сложно. Насколько я знаю, нет реальных аппаратных мер противодействия этой атаке. Тем не менее, именно эти алгоритмы шифрования и то, как они требуют, чтобы процессор переворачивал биты, являются причиной этой уязвимости. Я подозреваю, что алгоритмы, устойчивые к боковым каналам или защищенные от боковых каналов, должны быть (и, надеюсь, находятся в стадии разработки).

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

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

Создайте ключи и храните их как можно более короткое время.


Действительно, дорогой Метаколлин, за то, что очистили меня. Но мой проект состоит из множества читателей (содержат mcu) и множества целевых MCU. Каждый читатель должен иметь возможность прочитать любую из целей, а любая из целей должна быть в состоянии прочитать любой из читателей. Потому что из этого я думаю, что они должны согласиться с уникальным ключом для передачи данных. и, основываясь на вашем ответе, я думаю, что тогда не так много различий между, например, защищенной кортой m3 LPC18S57 и общей кортексом m4 STM32F429 и даже общей кортексом m3 LPC1788 (более дешевый выбор), я не делаю совершенно секретный проект, но хочу сделать это так безопасно, как я могу.
Махмуд Хоссейнипур

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.