2013-03-04 2 views
2

Я хочу, чтобы пользователи на моем сайте, чтобы создать асимметричный частный & открытый ключ, чтобы они могли:Создание асимметричного ключа из ключевой фразы

  • загрузить публичный ключ на сайт, чтобы мой веб-приложение может шифровать файлов они загружают
  • загрузки файлов и расшифровать их с помощью локального приложения и секретный ключ

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

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

Итак, мой вопрос: возможно ли создать асимметричную пару частных/открытых ключей на основе кодовой фразы? Это позволит пользователю при необходимости обновить закрытый ключ.

+0

Я отредактировал ваше название. Пожалуйста, смотрите: «Если вопросы включают« теги »в их названиях?] (Http://meta.stackexchange.com/questions/19190/), где консенсус« нет, они не должны ». –

+0

Возможно, вы захотите изменить заголовок, чтобы сказать «асимметричный», если это то, что вы действительно ищете. –

ответ

0

Какие поля для вашего алгоритма (например, RSA http://msdn.microsoft.com/en-us/library/system.security.cryptography.rsaparameters.aspx) являются более или менее точными. Вы можете легко создать алгоритм для генерации D и P из некоторой строки (вычисление других полей RSA из них). Я бы порекомендовал, что вы не выбрали бы один из ответов на StackOverflow (это просто даст кому-то, кто хотел бы получить ваши данные, что-то легко попробовать).

Алгоритмы, подобные RSA, трудно разбить, это объем усилий, которые направлены на обратное проектирование частного/открытого ключа на основе зашифрованных данных. Если вы вводите «ярлык», такой как алгоритм воспроизводимого поколения, основанный на парольной фразе, безопасность вашей системы теперь зависит от того, насколько хорошо парольная фраза хранится в секрете, а не сам алгоритм шифрования.

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

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

+0

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

+0

Я не понимаю, почему кто-нибудь нашел это полезным? Игнорируя присущие ей дыры в безопасности, зачем кому-то загружать незашифрованные файлы, которые они должны были бы расшифровать при их загрузке? Почему бы тогда не просто зашифровать данные, а затем загрузить его? Гораздо меньше неприятностей для них - плюс более безопасный. –

+0

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

1

Один из способов сделать именно то, что вы спрашиваете, является:

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

Этот процесс должен детерминистически генерировать пару ключей открытого/закрытого RSA-ключа. Тем не менее, причины этого не делать:

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

Лучший способ добиться того, что вы пытаетесь сделать, это:

  1. Определить уровень безопасности N, тем больше более безопасной, но медленнее этот процесс будет.
  2. Создайте «соль» и свяжите его с идентификатором пользователя.
  3. Создание пары открытых и закрытых ключей RSA.
  4. Iterate PBKDF2 N раз, чтобы создать симметричный ключ на основе пароля пользователя и соли.
  5. Используйте симметричный алгоритм шифрования для шифрования закрытого ключа.
  6. Загрузите незашифрованный открытый ключ и зашифрованный закрытый ключ на сервер.

Это лучше, потому что:

  • Все процессы, перечисленные выше, AFAIK стандартный и проверены.
  • Генерация открытых/закрытых ключей (занимает много времени) происходит только один раз при настройке учетной записи пользователя.
  • Доступ к ключам всегда происходит в фиксированном количестве времени.

Это решает проблему:

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

Конечно, есть очевидные предупреждения, например, если пользователь забыл свой пароль, все данные заблокированы до тех пор, пока не будут доступны общедоступные сведения о том, как взломать RSA, или на миллиард лет текущей вычислительной мощности ставится задача взлома их пароль ;-) (в зависимости от N и размера ключа, конечно). Кроме того, соль важна для предотвращения атак со словарем.

Смежные вопросы