Ни один из этих вариантов не является особенно лучше или хуже, чем другие, потому что все они очень небезопасны. Я собираюсь с вариантом 4.
SRAM - самое безопасное место для хранения ключей, но вы никогда не должны вводить их из внешнего мира. Они должны ВСЕГДА генерироваться внутри процессора во время загрузки. Любые другие действия мгновенно лишают законной силы все остальное - это автоматически небезопасно.
Не храните ключи в энергонезависимой памяти, вы правы в этом. Не имеет значения, защищаете ли вы EEPROM или флэш-память от чтения. Этот предохранитель защиты от чтения кода легко перевернуть. Злоумышленнику нужно только снять крышку (удалить или химически вытравить черную эпоксидную упаковку, чтобы обнажить кремниевый кристалл внутри). На этом этапе они могут покрывать часть матрицы, которая является энергонезависимыми ячейками памяти (эти секции очень регулярны, и хотя отдельные ячейки памяти можно увидеть очень маленькими, большая структура может быть) и небольшой кусочек чего-либо непрозрачный для УФ маскируется над этим разделом. Затем злоумышленник может в течение 5-10 минут светить на чип ультрафиолетовым излучением и сбрасывать все предохранители, включая предохранитель CRP. Память OTP теперь может быть прочитана любым стандартным программистом.
Или, если они хорошо финансируются (скажем, получение этих ключей для кого-то более чем на 1000 долларов), они могут просто читать ячейки памяти напрямую с помощью нескольких типов электронных микроскопов.
Чтобы быть в безопасности, ключи должны быть стерты, а не скрыты.
- Нет, по тем же причинам, что и выше.
Теперь перейдем к варианту 4:
- Просто используйте шифрование. Распределение ключей - это решенная проблема. Так что используйте это легкодоступное решение. Микросхема должна использовать свой ГСЧ, и для обеспечения достаточного количества энтропии должен быть сделан ряд других соображений, а загрузчик должен загружаться непосредственно в программу, которая генерирует необходимый секретный ключ (ключи), который должен быть общего назначения. регистрируется и перемещается непосредственно в SRAM, где они остаются до тех пор, пока не будут стерты.
Однако существует проблема, заключающаяся в том, что ничто, кроме процессора, не имеет никакого представления о том, что такое секретный ключ. Нет проблем: используйте криптографию с открытым ключом. То, что вы храните в памяти OTP, является вашим открытым ключом. Этот ключ может быть прочитан кем угодно, вы можете разместить его на стеке, вы можете нарисовать его на боковой части нефтяного танкера буквами высотой 5 футов, это не имеет значения. Замечательная вещь в криптографии с открытым ключом состоит в том, что она асимметрична. Ключ для шифрования чего-либо не может расшифровать его, для чего требуется закрытый ключ. И наоборот, ключ для расшифровки чего-либо, зашифрованного открытым ключом, не может быть использован для шифрования чего-либо. Таким образом, процессор генерирует секретные ключи, использует ваш сохраненный открытый ключ для шифрования секретных ключей и просто отправляет их через USB или RS232 или что-либо еще. Чтение секретного ключа требует вашего личного ключа, которые не должны быть сохранены, отправлены или когда-либо связаны с чипом. Как только вы расшифруете секретный ключ своим закрытым ключом (в другом месте, за пределами чипа), все готово. У вас есть надежно переданный секретный ключ, который был ПОЛНОСТЬЮ СОЗДАН внутри чипа, без необходимости хранить что-либо, кроме открытого ключа - который, как было указано ранее, вообще не нуждается в защите от чтения.
Этот процесс формально называется согласованием ключей, и все его используют. Вы использовали это несколько раз сегодня. Есть много ресурсов и библиотек, доступных для обработки. Пожалуйста, никогда не вводите ключи во что-либо.
Одна последняя вещь, чтобы упомянуть: Все это спорно, поскольку ключ AES может быть легко восстановлены с помощью атаки со стороны канала, которые сидят на минуту изменения питания и измерить в нынешнем розыгрыше и времени между этими изменениями, вызванные битами листать в CPU в качестве регистров. Это, в сочетании со знанием того, как работает AES (или какой-либо один из очень небольшого набора возможных алгоритмов шифрования, который может использоваться), позволяет относительно легко и недорого восстановить ключ. Он не позволит прочитать ключ, но он может сузить пространство ключа до чего-то смехотворно маленького, например, 255 возможных ключей. Чип также не может обнаружить его, так как он находится в восходящем направлении.
Это побеждает зашифрованные загрузчики AES-256 на «безопасных» криптопроцессорах, и это не так сложно. Насколько я знаю, нет реальных аппаратных мер противодействия этой атаке. Тем не менее, именно эти алгоритмы шифрования и то, как они требуют, чтобы процессор переворачивал биты, являются причиной этой уязвимости. Я подозреваю, что алгоритмы, устойчивые к боковым каналам или защищенные от боковых каналов, должны быть (и, надеюсь, находятся в стадии разработки).
Таким образом, в настоящее время реальный ответ на то, как надежно хранить ключ (или даже просто использовать временный ключ) на встроенном устройстве: вы не можете.
Но, по крайней мере, если вы генерируете новый ключ каждый раз, используя согласование ключей в варианте 4, тогда атака по побочному каналу может поставить под угрозу только ключ используемого канала, и только если у них есть время для мониторинга питания, пока он шифрует данные , Если вы часто договариваетесь о новых ключах, сгенерированных внутри, это может обеспечить полезную степень безопасности.
Создайте ключи и храните их как можно более короткое время.