Обеспечение закрытых ключей против атак перебором мобильных устройств

Я должен работать с XSLT здесь, потому что кто-то думал, что это - хорошая идея решить данную проблему: Мы должны извлечь некоторые данные из нескольких XML-файлов и присоединиться к ним вместе к различным выходным форматам для различных инструментов, которые делают последующую обработку.

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

, Но: Это - настоящая кривая обучения шага, как это не процедурное. Если Вы привыкли к процедурному программированию (C, Java, Perl, PHP, и т.д.) Вы собираетесь пропустить много общих структур, или Вы будете задаваться вопросом о вещах что просто удача cubersome и иногда не действительно читаемые нетренированным глазом. Например, запись "resuseable" кода: Если бы необходимо сделать что-то много раз в различных местах в процедурном программировании, Вы определили бы функцию, чтобы сделать так. Вы можете achive такие вещи в XSLT также, но для большего количества кода для записи и не так читаем/понятен, как нормальная функция была бы.

основная проблема, которую я имею, то, что многие люди, происходящие из процедурного фона, работали над XSLT-файлами к настоящему времени, и почти все просто "эмулировали" то, в чем он нуждался.

Поэтому как заключение: Я не рассматриваю XSLT как "окончательное" решение больше. На самом деле это - боль, чтобы считать или записать некоторые конструкции в XSLT. Для большинства случаев необходимо будет думать о приложении: Для простого преобразования я буду, вероятно, использовать XSLT снова. Но для более сложного программного обеспечения я не буду использовать его снова.

10
задан paracycle 11 December 2009 в 15:53
поделиться

3 ответа

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

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

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

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

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

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

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

5
ответ дан 4 December 2019 в 02:26
поделиться

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

1
ответ дан 4 December 2019 в 02:26
поделиться

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

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

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

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

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

2
ответ дан 4 December 2019 в 02:26
поделиться
Другие вопросы по тегам:

Похожие вопросы: