Як убезпечити приватний ключ вашої організації?

Я збираюся впровадити власний орган сертифікації (CA) лише для внутрішнього використання.

Зараз існує проблема, що приватна особа ніколи не повинна експлуатуватися. Тому зараз приватний ключ зашифрований.

Що ще можна зробити для підвищення безпеки приватного ключа?

Я працював у компанії, де безпека ключа CA була вирішальною для подальшого успіху бізнесу. З цією метою ключ був зашифрований за допомогою користувацького протоколу, який вимагав принаймні двох людей з фізичними маркерами, підключеними до терміналів, щоб розшифрувати його (було щонайменше 5 з цих жетонів, будь-які 2 комбіновані працювали б). Термінали були фізично відокремлені від фактичної машини ключем CA. Інтерфейс, який користувачі розшифрували, це термінал VT220, який дозволив їм вводити маркери розшифровки, а потім вибирати те, що вони хотіли «підписати» ключем (ніколи не надаючи їм доступу до розшифрованого ключа). Ця система означала, що принаймні 4 людини повинні працювати разом, щоб поставити під ключ ключ, два власника жетонів, хлопець, який мав доступ до центру обробки даних,

Якщо ви зацікавлені в більш детальній інформації про подібні налаштування, Брюс Шнайер має чудовий сайт, що охоплює розробку та реалізацію комп'ютерної безпеки:

http://www.schneier.com/

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

http://www.schneier.com/book-applied.html

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

Такі налаштування, звичайно, також включають міркування щодо фізичної доступності машини, а також обмеження дозволених засобів масової інформації. Хороший шлях USB-накопичувач, мабуть, не найкращий вибір ...

(Це, до речі, дуже наочний приклад торгівлі між безпекою та зручністю.)

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

Цей чудовий посібник із проведення церемонії генерації ключів окреслює деякі стандартні протоколи, які можуть допомогти забезпечити генерацію ключів, хоча вони здебільшого зводяться до (а), що має все, про що свідчать численні знаючі аудитори, які (б) роблять сучасні записи про все, що робиться (в) за заздалегідь визначеним протоколом, написаним кимось, окрім виконавця.

Залежно від того, наскільки ви серйозні, варто подумати про використання апаратного обладнання 140 140 ( http://en.wikipedia.org/wiki/FIPS_140#Security_levels ) для зберігання ключів CA та резервних копій цих ключів. У вас повинен бути один кореневий ЦА та один проміжний ЦА, щоб ви могли зберігати кореневий ЦЗ в режимі офлайн та фізично захищений. Корінь потрібен лише для поновлення або підписання нових проміжних ЦО, тоді як проміжні ЦО залишаються в Інтернеті для щоденних операцій. Як і інші запропонували, забезпечити генерацію ключів та управління ключами з п про м управління має важливе значення.

CPS VeriSign (нині Symantec) - хороша орієнтація на те, як комерційний CA створює та захищає свої ключі. Подивіться на глави 5 та 6, зокрема: http://www.verisign.com/repository/cps/ . (Я працював у VeriSign кілька років)

Також NIST має кілька хороших публікацій про керування ключами ( http://csrc.nist.gov/publications/drafts/800-57/Draft_SP800-57-Part1-Rev3_May2011.pdf ) та покоління, і ваша компанія також повинна мати CPS який визначає політику та практику, яку ви використовуєте для управління вашим КА. IETF пропонує хороший шаблон: http://www.ietf.org/rfc/rfc2527.txt

Відмінне запитання і кілька чудових відповідей теж.

Майте на увазі, що ви на 90% випереджаєте більшість інших людей, просто розглядаючи цю проблему, а не сліпо заряджаючи вперед.

Маючи на увазі це і прийнявши інші поради тут, я просто додам: не відпочивайте на лаврах; слідкуйте за новинами безпеки та криптографії як щодо загальних проблем, пов’язаних з видачею сертифікатів, ануляцією, зломками тощо, так і найвищим чином щодо вразливих місць та проблем із певними продуктами, які ви використовуєте для створення та управління своїми ключами.

Нарешті: фізична безпека. Зробити щось "хакерське підтвердження" - це не допомога, якщо я можу просто влаштуватися на роботу, як прибиральник контрактів у вашій будівлі, а потім одного дня покладіть диск, що містить вашу кореневу частину, в кишеню. Ви здивуєтеся, скільки людей сумує за цим.