реализация криптографии с открытым ключом - PullRequest
0 голосов
/ 04 августа 2009

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

У mcrypt, похоже, нет реализации для такой схемы. Кто-нибудь знает библиотеку (модуль PHP или чистый PHP), которая бы это делала?

Ответы [ 4 ]

2 голосов
/ 04 августа 2009

Я предлагаю взглянуть на привязки PHP OpenSSL и, в частности, функцию openssl_public_encrypt () . Вы действительно можете встроить главный открытый ключ в сценарий, и сценарий зашифрует ключ AES каждого пользователя с помощью этого открытого ключа. Храните соответствующий главный закрытый ключ в сейфе компании.

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

2 голосов
/ 04 августа 2009

Для этого есть расширение PECL. http://us2.php.net/manual/en/book.gnupg.php

Вы также можете использовать инструмент командной строки gnupg из php, если он не должен быть очень быстрым:

Я не пробовал ни один из методов.

1 голос
/ 04 августа 2009

Я не понимаю, как это будет работать. Любая двусторонняя функция шифрования будет расшифровываться только при подаче определенного пароля, используемого для шифрования (если только вы не являетесь АНБ и не отошли в алгоритмы). У вас не может быть двух паролей, расшифровывающих один и тот же файл (если нет коллизий хешей, но это не то, что вы можете легко осуществить).

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

Имейте в виду, что mcrypt не является криптографией с открытым ключом. Однако с помощью криптографии с открытым ключом вы можете делать то, что хотите. Например, с PGP / GPG вы можете зашифровать файл так, чтобы три разных пользователя могли расшифровать его, используя свои личные ключи, не зная личных ключей друг друга. Таким образом, у вас может быть виртуальный пользователь с мастер-паролем, который может расшифровать все.

Другой вариант - хранить две копии всех зашифрованных данных; один зашифрован паролем пользователя, а другой зашифрован мастер-паролем.

1 голос
/ 04 августа 2009

Просто чтобы быть уверенным в вашем требовании этого мастер-пароля ,

  1. Ожидается ли его использование только в качестве команды 'encrypt this', которая «запечатает» что-то
    который может быть открыт только тем, кто знает секретный ключ? Или же,
    • Это то, что вы ожидаете, чтобы открыть любое шифрование на предприятии?
    • Я просто хочу убедиться, что ваша фраза не будет интерпретироваться таким образом
    • ваша фраза 'decrypt any data' звучит опасно
      (и нереально / практично с асимметричным ключом шифрования)

Обновление на основе комментария.

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

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

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


Однако, если пользовательским данным доверяют ведущему (как это, очевидно, имеет место),

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

Если пользователю необходимо подписать данные, это можно сделать отдельно в процессе.
Это избавит вас от необходимости хранить двойные копии и хранить их.


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

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