Защита личных ключей от нападений грубой силы на мобильные устройства

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

В идеале это должно быть достаточно безопасным для атаки грубой силы; однако есть два предельных фактора:

Поскольку закрытый ключ должен соответствовать определенному формату, процесс дешифрования может проверить результат процесса, чтобы убедиться, что он действителен или нет. Например, если закрытый ключ должен быть закрытым ключом RSA, злоумышленник будет пытаться использовать различные комбинации кодовой фразы и теста, чтобы проверить, может ли он использовать полученный текст как действительный закрытый ключ RSA. Поскольку закрытый ключ RSA должен определенным образом кодировать определенную информацию, если дешифрование не удалось, механизм RSA сигнализирует, что ключ недействителен. Это дает злоумышленнику абсолютно автономный способ проверки его атак. Предпочтительно злоумышленник должен не быть в состоянии сказать, не связываясь с сервером, если его попытка дешифрования была успешной или нет.
Поскольку приложение работает на мобильном устройстве, повышенная сложность Key Derivation Function не помогает с "Укрепление ключей" , поскольку автономная атака, которая имеет полный доступ к мобильному устройству, предположительно будет осуществляться на более способном устройстве с более богатыми ресурсами. В ближайшее время любое увеличение числа раундов вычисления функции деривации ключей замедлит работу пользователя (что приемлемо для определенного предела), но будет немедленно сорвано, если атака должна выполняться на настольном компьютере.

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

Ответ 1

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

Это просто невозможно.

Вот что может сделать злоумышленник:

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

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

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

Добро пожаловать в мир DRM.

Ответ 2

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

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

Косвенные атаки гораздо более вероятны.

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

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

Ответ 3

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