Jak zabezpieczyć klucz prywatny swojego urzędu certyfikacji?

24

Mam zamiar wdrożyć mój własny urząd certyfikacji (CA) wyłącznie do użytku wewnętrznego.

Teraz istnieje problem polegający na tym, że prywatny urząd certyfikacji nigdy nie powinien być nigdy wykorzystywany. Więc teraz klucz prywatny jest szyfrowany.

Co jeszcze można zrobić, aby zwiększyć bezpieczeństwo klucza prywatnego?

JMW
źródło
Czy możemy uzyskać system operacyjny, na którym działa serwer WWW? Prawdopodobnie możesz ustawić uprawnienia do pliku, aby nikt nie mógł go odczytać poza aplikacją i superużytkownikiem.
Rilindo,
prowadzimy RHEL
JMW

Odpowiedzi:

25

Pracowałem w firmie, w której bezpieczeństwo klucza CA było kluczowe dla dalszego sukcesu firmy. W tym celu klucz został zaszyfrowany przy użyciu niestandardowego protokołu, który wymagał obecności co najmniej 2 osób z fizycznymi tokenami podłączonymi do terminali, aby go odszyfrować (było co najmniej 5 z tych tokenów, każda 2 łącznie działałaby). Terminale zostały fizycznie oddzielone od rzeczywistej maszyny za pomocą klucza CA. Interfejs, który mieli użytkownicy, którzy go odszyfrowali, był terminalem VT220, który pozwolił im wprowadzić tokeny odszyfrowujące, a następnie wybrać to, co chcieli „podpisać” kluczem (nigdy nie dając im dostępu do odszyfrowanego klucza). Ten system oznaczał, że co najmniej 4 osoby będą musiały współpracować, aby skompromitować klucz, dwóch posiadaczy tokenów, facet, który miał dostęp do centrum danych,

Jeśli chcesz uzyskać więcej informacji na temat tego rodzaju konfiguracji, Bruce Schneier ma świetną stronę obejmującą projektowanie i wdrażanie zabezpieczeń komputerowych:

http://www.schneier.com/

Opublikował również bardzo dobrą książkę Kryptografia stosowana, która, jak znalazłem, pomogła mi zrozumieć podstawy takich systemów i jak tworzyć bezpieczniejsze infrastruktury (czytelne dla osób, które nie noszą ochraniaczy kieszeni):

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

wielomian
źródło
2
A operacja dwoma kluczami (lub dowolnym n od m, m> = n, n> 1) jest kolejnym doskonałym środkiem ostrożności - ale dla moich pieniędzy najpierw pomiń szczelinę powietrzną i dodaj poprawki takie jak ten drugi, w zależności od stopnia paranoi (tj. koszt awarii).
MadHatter obsługuje Monikę
1
Dlaczego osoba z dostępem do katalogu głównego nie może zrzucić zawartości pamięci do pliku, podczas gdy dwie upoważnione osoby wykonują swoją pracę? Oznacza to, że facet z rootem może uzyskać klucz tylko z dodatkowymi zasobami wymaganymi do zrzucenia pamięci z komputera.
Slartibartfast
Kontrolowana fizyczna kontrola dostępu jest równie ważna dla tego rodzaju bezpieczeństwa, jak kontrolowana logiczna kontrola dostępu. Operacja podpisywania nie powinna wymagać uprawnień do skrzynki (ta kontrola jest obsługiwana przez wymóg dowolny-n-z-m), więc posiadacz hasła roota nie powinien być w ogóle, gdy trwa logowanie. (S) będzie on potrzebny do działań związanych z konserwacją systemu, ale powinny one być wykonane zgodnie z precyzyjnym, wcześniej napisanym skryptem przez osobę inną niż autor scenariusza i kontrolowane w czasie rzeczywistym przez znającą się na rzeczy osobę trzecią.
MadHatter obsługuje Monikę
16

Dużym zyskiem jest całkowite odcięcie prywatnego klucza CA na dedykowanym komputerze od sieci. Następnie należy podpisać i ewentualnie wygenerować nowe certyfikaty na tym komputerze, a następnie użyć nośnika fizycznego, aby przenieść nowe certyfikaty z komputera CA.

Taka konfiguracja oczywiście obejmowałaby także rozważania dotyczące fizycznej dostępności maszyny, a także ograniczenia dotyczące dozwolonych mediów. Dobrze podróżująca pamięć USB prawdopodobnie nie jest najlepszym wyborem ...

(Nawiasem mówiąc, jest to bardzo wyraźny przykład kompromisu między bezpieczeństwem a wygodą).

andol
źródło
Airgap stanowi doskonałe zabezpieczenie, a niebezpieczeństwo związane z nośnikami wymiennymi można zmniejszyć, ustawiając pole podpisu, aby niczego nie uruchamiało automatycznie, zezwalało na pliki binarne SUID lub w inny sposób ufało plikom wykonywalnym na takich nośnikach.
MadHatter obsługuje Monikę
Można to dodatkowo zoptymalizować za pomocą karty inteligentnej do generowania, przechowywania i używania klucza. Pomyśl o karcie inteligentnej jako o dedykowanej maszynie, która ma pewne zabezpieczenia przed ingerencją (w zasadzie chip wolałby raczej złamać niż oddać klucz, co jest trudne w przypadku bardziej złożonego systemu) i który ma interfejs, który jest na tyle prosty, że stos protokołu mógł zostać poprawnie skontrolowany.
Simon Richter,
Popieram sugestię karty inteligentnej, ale istnieje ryzyko. Gdy klucz może znajdować się tylko w jednym miejscu, tylko jeden element sprzętowy musi sprawić, że klucz będzie niedostępny. Myślę jednak, że jedna lub więcej kart inteligentnych może stanowić ważną część bezpiecznego procesu generowania i przechowywania kluczy.
Slartibartfast
Jeśli chodzi o problem z autouruchamianiem. W przypadku menedżera plików GUI może być również wskazane wyraźne poinformowanie go, aby nie próbował wykonywać żadnych inteligentnych podglądów / miniatur wymienionych plików. Choć samo w sobie nie jest zagrożeniem, może stanowić wektor ataku na istniejące luki w zabezpieczeniach.
andol
Jeśli bezpieczeństwo jest naprawdę ważne, wybrałbym kilka płyt CD-R z jednokrotnym zapisem.
Lie Ryan,
15

Poparłem pozostałe dwie odpowiedzi i skomentowałem je, ponieważ uważam, że obie są doskonałe. Jeśli zdecydujesz się na oba, a może to być właściwe, zdecydowanie doradzam w początkowej generacji klucza, ponieważ nie jest najlepszy czas na kompromis klucza (w którym można zastosować wiele standardowych, powtarzalnych środków ostrożności zastosowane), ale w czasie generowania, który jest jednorazowy, jest znacznie łatwiejszy do obalenia.

Ten doskonały przewodnik na temat prowadzenia ceremonii generowania klucza przedstawia niektóre standardowe protokoły, które mogą pomóc w zabezpieczeniu generowania klucza, choć sprowadzają się one głównie do (a) posiadania wszystkiego, czego świadkami jest wielu dobrze wykwalifikowanych audytorów, którzy (b) rejestrują jednocześnie wszystko, co jest zrobione (c) zgodnie z wcześniej ustalonym protokołem napisanym przez osobę inną niż wykonawca.

MadHatter obsługuje Monikę
źródło
Tak, dobra uwaga na temat początkowego klucza gen.
andol
7

W zależności od tego, jak poważny jesteś, powinieneś rozważyć użycie sprzętu FIPS 140-2 ( http://en.wikipedia.org/wiki/FIPS_140#Security_levels ) do przechowywania kluczy CA i kopii zapasowych tych kluczy. Powinieneś mieć jeden główny urząd certyfikacji i jeden pośredni urząd certyfikacji, aby móc zachować swój główny urząd certyfikacji offline i fizycznie zabezpieczony. Rdzeń jest potrzebny tylko do odnowienia lub podpisania nowych pośrednich urzędów certyfikacji, podczas gdy pośrednie ośrodki certyfikacji pozostają w trybie online dla codziennych operacji. Jak inni sugerują, bezpieczne generowanie kluczy i zarządzanie kluczami z n o m kontroli jest bardzo ważne.

VeriSign (obecnie Symantec) CPS jest dobrym przykładem tego, jak komercyjny urząd certyfikacji generuje i chroni swoje klucze. Spójrz na rozdziały 5 i 6, w szczególności: http://www.verisign.com/repository/cps/ . (Pracowałem w VeriSign przez kilka lat)

Ponadto NIST ma kilka dobrych publikacji na temat zarządzania kluczami ( http://csrc.nist.gov/publications/drafts/800-57/Draft_SP800-57-Part1-Rev3_May2011.pdf ) i generowania, a twoja firma powinna również mieć CPS który określa zasady i praktyki stosowane do zarządzania urzędem certyfikacji. IETF zapewnia dobry szablon: http://www.ietf.org/rfc/rfc2527.txt

Wino z gruszek
źródło
1

Świetne pytanie i kilka świetnych odpowiedzi.

Pamiętaj, że wyprzedzasz większość innych ludzi o około 90%, biorąc pod uwagę ten problem, zamiast ślepo pobierać opłaty z wyprzedzeniem.

Mając to na uwadze i korzystając z innych rad tutaj, dodam po prostu: nie spoczywaj na laurach; miej oko na wiadomości dotyczące bezpieczeństwa i kryptografii, zarówno dotyczące ogólnych problemów związanych z wydawaniem certyfikatów, odwoływania, łamania itp., a przede wszystkim luk w zabezpieczeniach i problemów z konkretnymi produktami używanymi do generowania i zarządzania kluczami.

Wreszcie: bezpieczeństwo fizyczne. Uczynienie czegoś „odpornym na ataki hakerów” nie jest pomocne, jeśli mogę po prostu znaleźć pracę jako sprzątaczka kontraktu w twoim budynku, a następnie włożyć dysk z certyfikatem root do jednego dnia. Byłbyś zaskoczony, jak wiele osób tęskni za tym.

Rob Moir
źródło
Cieszę się, że to @jmw - jak powiedziałem, wyprzedzasz już 90%, a może nawet 99% większości ludzi, i wygląda na to, że masz to wszystko pod ręką. Byłbyś zszokowany ilością ludzi, którzy spędzają tygodnie i tony pieniędzy, patrząc na oprogramowanie, nie robiąc nic, aby fizycznie zabezpieczyć dane.
Rob Moir,
Dzięki, masz absolutną rację: informowanie o nowych zagrożeniach jest obowiązkowe dla każdego administratora. :-) o bezpieczeństwie fizycznym: centrum danych, w którym znajdują się nasze serwery, ma wysokie bezpieczeństwo fizyczne. dlatego skonfigurowane są hasła bios && grub. partycja, na której przechowywane są dokumenty CA, jest również szyfrowana. ponadto sam klucz CA jest szyfrowany. Nagios wyzwalałyby ostrzeżenia o „wyłączeniu serwera” w przypadku fizycznej kradzieży. Bardziej martwię się o exploity „niefizyczne”. :-)
JMW