Ентропія на віртуальних машинах


12

Як ви можете знати, що створити ентропію на віртуальній машині не так просто, як на "звичайному" ПК. Створення gpg-ключа на віртуальній машині може зайняти деякий час, навіть за допомогою правильних інструментів.

Існує набагато більше функцій криптовалюти, які не так усвідомлені ентропією, як gpg.

То чи можна сказати, що криптографія менш безпечна на віртуальній машині?


1
Випадкові числа "справжньої" машини насправді не є випадковими для початку (якщо ви не маєте апаратного генератора випадкових чисел, якого у більшості немає). Вони всі псевдовипадкові для початку, і ентропія породжується аналогічно. Якщо у віртуальних машинах це повільно, платформа для віртуалізації сповільнює його (я б ризикну здогадуватися, що ви не використовуєте Hypervisor Type 1).
Кріс С

Відповіді:


6

Перш за все, дозвольте сказати, що я зовсім не експерт із безпеки.

Оскільки створення ключів gpg використовується /dev/randomяк генератор випадкових чисел, воно настільки ж захищене як на віртуальній машині, так і на реальній машині.
/dev/randomє блокувальним пристроєм, і він припинить видавати будь-яку випадковість понад доступну кількість. Ви можете перевірити наявні випадковість за допомогою
cat /proc/sys/kernel/random/entropy_avail(має бути приблизно 2000 )

На віртуальній машині наявна випадковість дійсно нижча, ніж на реальній машині, через відсутність доступу до обладнання.
Ви можете збільшити ентропію, наприклад, застосувавши ентропійні ключі та / або переключившись на невіртуалізовану машину.

Є приємна стаття про ентропію на віртуальних машинах. На жаль, обидві частини статті доступні лише в кеші Google.

Ентропія надає вплив на будь-яке шифрування ssl / tls. Отже, використання /dev/urandomабо будь-яке не справді випадкове джерело дійсно впливає на безпеку ваших програм.

З точки зору того, наскільки надійний /dev/urandomпорівняно з справжньою випадковістю;
я не в змозі дати вам гідну відповідь, вибачте.

Для отримання додаткової інформації з цієї теми ви можете зайти на http://security.stackexchange.com та / або прочитати, наприклад. це повідомлення


1
/dev/urandomвикористовує криптографічно захищений PRNG (посіяний тим самим пулом, що і /dev/random), тому не повинно виникнути проблем, якщо в цьому пулі було достатньо початкової ентропії. Можливо, є сенс висівати його з пулу ентропії батьківської машини.
Paŭlo Ebermann

3

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

Останні можуть принаймні зібрати ентропію з якогось фактичного обладнання. Насправді робота шматка HW - у більшості випадків - пов'язана з деяким фізичним явищем, яке завжди піддається невеликим варіаціям, випадковим за всіма даними. Оскільки сервери, як правило, працюють дуже довго без скидання, отриманий пул ентропії з часом буде достатньої якості.

Віртуальні машини страждають від трьох проблем.

  1. Обладнання, яке вони бачать, не є реальним, і тому на нього навряд чи впливає якесь фізичне явище. Вони зможуть збирати ентропію набагато повільніше.
  2. ВМ скидаються набагато частіше, ніж реальні сервери, і вони можуть навіть не встигнути зібрати достатню кількість ентропії (саме тому при вимкненні добре зберегти поточний стан ентропії та використовувати його для подачі пулу ентропії при перезапуску).
  3. Хоча справжній сервер може мати певний шанс визначити, коли він має справу з поганим пулом ентропії, віртуальна машина легше буде працювати під враженням, що пул ентропії хороший (адже він був зібраний з HW, але не знаючи, що HW є не реально), тоді як це насправді погано.

Найкраще рішення - мати ВМ просто відмовитись і зрозуміти, що HW, яку він бачить, є поганим джерелом ентропії. Потім організуйте послугу локальної мережі для розповсюдження високоякісної ентропії (див. Брокер "Ентропія" ). "Ентропійний сервер" може витягувати випадковість із загальних HW (у цьому випадку він повинен працювати достатньо часу, і він повинен мати пристойну ОС) або з конкретної крипто HW (чіп TPM, чіп VIA Padlock тощо).

Віртуальний комп'ютер, що використовує таку послугу, може бути навіть більш безпечним (криптографічно), ніж "справжній" сервер, щойно завантажився.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.