Генерация парольной фразы для шифрования - PullRequest
0 голосов
/ 20 марта 2019

Я работаю над шифрованием некоторых данных с использованием 128-битного алгоритма шифрования AES (Symmetric Encryption Algorithm).

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

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

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

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

Ответы [ 2 ]

1 голос
/ 20 марта 2019

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

Таким образом, вы будете:

  1. Шифровать свои данные с помощью «мастер-ключа»
  2. Шифровать свой «мастер-ключ» с помощью «личного ключа» (по одному на каждыйuser)

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

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

Нет способа сделать это, если вы хотите отправить данные пользователю в зашифрованном виде.

0 голосов
/ 20 марта 2019

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

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

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

когда пользователь входит в систему, я попрошу его Ключ

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

...