Как мне хранить ключ шифрования AES?

Я запускаю сервер DV 3.5 на MediaTemple с Linux CentOS 5, php и mysql DB и пытаюсь зашифровать телефонные записи с помощью AES.

Я наткнулся на хороший скрипт PHPAES.

но я не уверен в следующем:

  1. Где я на самом деле храню ключ шифрования AES, используемый для шифрования и дешифрования номера телефона?

  2. Как вызвать ключ шифрования AES, когда пользователь отправляет свои данные через форму и сохраняет их в нашей базе данных MySQL?

  3. Когда я хочу расшифровать эту информацию для наших внутренних агентов по обслуживанию клиентов, как они, в свою очередь, вызывают ключ AES?

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


mysql linux aes php
person JM4    schedule 27.10.2010    source источник
comment
На самом деле это уже задано здесь stackoverflow.com/questions/2210011/   -  person Amir Raminfar    schedule 28.10.2010
comment
в конечном итоге я вижу, что это похоже, но не тот же вопрос - возможно, мне следует спросить, возможно ли зашифровать одним ключом (общедоступным) и расшифровать другим (закрытым)?   -  person JM4    schedule 28.10.2010

Ответы (2)


arrow_upward
2
arrow_downward

Я разработал процесс, в котором я начинаю с начального ключа шифрования, который я кодирую в хэш SHA1, затем шифрую с помощью комбинации имени пользователя и пароля и сохраняю его в базе данных. Пароль (хэшированный или другой) никогда не сохраняется в базе данных и используется только при входе в систему для расшифровки ключа шифрования. Затем я использую это основное имя пользователя/пароль для создания дополнительных пользователей с паролями, в которых PHP или JavaScript кодирует ключ дешифрования с именем пользователя/паролем нового пользователя и сохраняет этот зашифрованный ключ в базе данных. Когда я пытаюсь расшифровать ключ шифрования из базы данных, используя комбинацию имени пользователя и пароля, я должен ожидать обратного хэша SHA1. Если я не получу действительный хэш SHA1, который может расшифровать данные, я знаю, что пароль неверный и данные непригодны для использования. У вас должна быть действительная комбинация имени пользователя и пароля, чтобы получить ключ дешифрования, который передается клиенту через SSL, расшифровывается с помощью функции JavaScript, а затем сохраняется в файле cookie для сеанса SSL.

Чтобы обойти систему, расшифровать данные и получить доступ к информации, вы должны быть заражены кейлоггером или трояном, который просматривал ваши файлы cookie во время этого сеанса входа в систему, в противном случае владелец сервера или клиент без комбинации имени пользователя и пароля могут использовать данные в базе данных без перебора. Используя 256-битные AES и надежные пароли (12+ символов, A-Z, az, 0-9, символы и т. д.), вы получите довольно сложное решение для взлома или, по крайней мере, такое, которое было бы болезненно пытаться.

Каждая учетная запись имеет функцию блокировки, поэтому, если вы попытаетесь войти через Интернет слишком много раз и потерпите неудачу, учетная запись будет заблокирована. Все PHP-страницы кодируют/декодируют параметры для предотвращения атак SQL-инъекций и проверки того, что сеанс PHP активен и совпадает с последним сеансом, отслеживаемым во время вашего входа в систему, а также проверяет работу вашего ключа шифрования. Каждый раз, когда вы входите в систему или посещаете страницу входа, предыдущий сеанс становится недействительным или, если время сеанса истекает, он также становится недействительным. Даже со всеми этими слоями он работает быстро и не позволяет людям использовать сценарии PHP, которые выводят JSON с использованием сфабрикованных POST для сценариев и атак путем внедрения SQL. Это также ограничивает возможность владельца/администратора сервера расшифровывать и читать вашу информацию, если она хранится у общего провайдера и т. д.

person Jeremy    schedule 02.05.2011

arrow_upward
0
arrow_downward

В итоге я пошел по этому пути:

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

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

вполне безопасно на мой взгляд.

person JM4    schedule 03.11.2010
comment
Соленый хэш чего? Я предполагаю, что вы имеете в виду хеширование некоторых других данных и использование их в качестве ключа для AES, а не хеширование номера телефона и не называние его шифрованием. Но шифрование значения в вашей записи базы данных бессмысленно, если ключ является просто хэшем другого значения в этой записи базы данных. Зачем вообще нужен шаг AES, если сразу после этого вы шифруете с помощью RSA? Похоже, вы только что объединили кучу криптографических функций, предполагая, что чем она сложнее, тем более безопасной она должна быть. - person Wyzard; 02.05.2011
comment
Кстати, загружать свой закрытый ключ на удаленную машину только для того, чтобы расшифровать файл, - плохая идея; вы выпускаете это из-под вашего контроля. Даже если это временный файл, вы, вероятно, уже знаете, что удаленные файлы обычно на самом деле не удаляются. Лучше загрузить зашифрованные данные на свою машину, где находится ключ, и расшифровать их там. - person Wyzard; 02.05.2011