Ваше понимание верно. При прочих равных условиях это не имеет значения; но есть морщины.
Одним из преимуществ их генерации на рассматриваемом сервере является то, что он сводит к минимуму вероятность взлома ключа при передаче. Пока вы используете защищенную машину для их генерации и безопасный метод (невосприимчивый к атакам MITM), чтобы переместить их на сервер, вы избежите этого. Не забудьте надежно стереть их в генерирующей системе, если только вы не намеренно намерены хранить копии и соответственно защищены.
Одно из преимуществ генерации на отдельной машине: обычно это будет ваш рабочий стол. Энтропийный пул на настольном компьютере почти всегда глубже, чем на необслуживаемом сервере, потому что на рабочем столе большой источник случайности, связанный с помощью кабелей клавиатуры и мыши (т. Е. Вас!). Нехватка энтропии может либо привести к тому, что генерация ключей займет много времени, либо использовать /dev/urandomвместо этого вывод PRNG, в зависимости от того, насколько параноидален инструмент генерирования, и это может привести к более слабым ключам; Настольные машины, как правило, не имеют этой проблемы.
Позднее редактирование : в соответствии с обсуждением в другом месте, которое связано здесь, два вопроса были подняты. Во - первых, вы могли бы пойти на полпути дома путем генерации энтропии на рабочем столе с помощью, например dd if=/dev/random bs=1k count=10 of=/tmp/entropy.dat, копирование , что на удаленном сервере, и подача его в ключевой процесс генерации либо непосредственно , либо путем углубления пула энтропии удаленного сервера. Я еще не нашел способ сделать первое, а для второго обычно требуется применение привилегий, которые - если канал между вами и удаленным сервером не является безопасным, что, скорее, является причиной всего возражения, - также небезопасны.
Во-вторых, оценочный mjg59 поднимает проблему аппаратных модулей безопасности, то есть устройств, в которые вы помещаете или внутри которых вы создаете закрытые ключи и которые затем выполняют операции с ключами, не выпуская ключ. Это отличный момент, но за рамками этого вопроса.
Но более общий результат потока - то, что вы должны иметь точную модель угрозы и правильно выбирать свои ответы - является хорошим. Моя модель угрозы состоит в том, что мои каналы связи безопасны, но мои конечные точки находятся под интеллектуальной атакой. Это означает, что я буду генерировать энтропически сильные пары ключей SSL локально и распространять их. Если окажется, что моя модель неточна, а мои связи оказались уязвимыми, я сразу пойму, что все мои пары ключей SSL взломаны. Если ваша модель угроз отличается, вы должны соответствующим образом адаптировать свои методы.
Это несколько важно.
Если вы генерируете их на другом компьютере, ключи уязвимы на генерирующем компьютере, а затем на сервере. Если вы используете зараженную машину для их генерации, некоторые Virii могут украсть ключи, даже прежде чем они будут перемещены на защищенный сервер.
Если вы генерируете их на защищенном сервере и просто перемещаете CSR / сертификат, шансы того, что кто-то / что-то получит закрытый ключ, меньше, чем в первом случае, поскольку закрытый ключ находится только на одной машине.
источник