Czy synchronizacja kluczy prywatnych jest dobrym pomysłem?

Często zadawane pytania dotyczące bezpieczeństwa Ubuntu One wskazują, że Canonical szyfruje połączenia i ogranicza dostęp do danych użytkownika. Wszystko w porządku i ufam SSL dla bankowości internetowej i innych rzeczy cenniejszych niż moje klucze prywatne.

To powiedziawszy, jestem bardzo zaniepokojony postawieniem ~/.ssh/id_dsasiebie w chmurze. Oczywiście żaden system nie jest całkowicie bezpieczny. Czy zatem jakaś kompetentna partia mogłaby w sposób pragmatyczny oszacować ryzyko?

Pamięć Ubuntu One nie jest szyfrowana kluczem kryptograficznym użytkownika

Podobnie jak Dropbox, sklep Ubuntu One nie jest szyfrowany specjalnym hasłem. Dlatego jest technicznie możliwe, aby ktoś uzyskał dostęp do twoich danych albo przez niegodnego zaufania pracownika, albo przez naruszenie bezpieczeństwa. Zobacz ten raport o błędzie dotyczący szyfrowania danych pamięci UbuntuOne , nadal jest to lista życzeń.

Więc nie zsynchronizowałem mojego folderu ~ / .ssh z chmurą. O ile nie ustawisz zaszyfrowanego kontenera, który jest następnie przesyłany do chmury, ale w przypadku kluczy ssh nie zawsze jest to przydatne. Ale daję ci wciąż przydatne sposoby szyfrowania danych:

• Zabezpieczanie pamięci w systemie Ubuntu One
• Bezpieczne korzystanie z magazynu w chmurze

Więcej informacji

Ubuntu One używa szyfrowania do połączenia (jak powiedziano w rzeczywistości), co oznacza, że ​​zasadniczo dane są przesyłane za pomocą pewnego rodzaju HTTPS. Możesz użyć naprawdę dobrze wykonanej animacji tego, co jest widoczne dla podsłuchującego podczas korzystania z HTTPS , dzięki uprzejmości EFF (Electronic Frontier Foundation) .

Klikając przycisk HTTPS na animacji EFF, będziesz mógł zobaczyć, co jest widoczne dla wszystkich, gdy umieścisz klucze SSH w kontenerze Dropbox lub Ubuntu One. Jak pokazuje animacja, wiele osób na site.com (np. One.ubuntu.com) będzie mogło przeglądać twoje dane (i wiele innych). Nawet jeśli użyjesz czegoś takiego jak Tor do kierowania całym ruchem, nadal oznacza to, że ludzie w witrynie site.com mogą uzyskać dostęp do danych.

Musisz więc zaszyfrować dane, zanim opuści Twój komputer. Przybywa więc zaszyfrowane na stronie.com przy użyciu poświadczeń, o których nie wiedzą. Oczywiście musiałbyś użyć silnego mechanizmu szyfrowania, aby spowodował, że złamanie go przez użytkowników witryny.com byłoby bardzo wolne.

Oczywiście w przypadku banku nie możesz zaszyfrować swoich pieniędzy, ponieważ płacisz bankowi, aby zajął się nim za Ciebie. Nie masz więc innego wyjścia, jak tylko zaufać bankowi, że jego system informatyczny będzie tak bezpieczny jak ich fizyczne skarbce, dzięki czemu tylko niewielka część pracowników (zarządzających twoim kontem) będzie mogła przeglądać i modyfikować twoje dane.

Bardzo niepokoi mnie umieszczenie mojego ~ / .ssh / id_dsa w chmurze.

Cóż, jednym z rozwiązań jest to, co robię z kluczami prywatnymi ssh i gpg za pomocą Dropbox: szyfruj je w archiwum i usuwaj „surowe” oryginały. W razie potrzeby tymczasowo rozpakowuję go, a następnie usuwam po zakończeniu.

Używam p7zip(używa szyfrowania AES-256), ale możesz użyć wielu innych narzędzi. W ten sposób wszystko, co zostanie zsynchronizowane, to zaszyfrowane archiwum, a nawet jeśli dojdzie do naruszenia pamięci w chmurze, nikt nie będzie mógł wyodrębnić kluczy prywatnych, chyba że zna hasło do archiwum.

Aby ułatwić życie tym, co często robisz (na przykład deszyfrowanie gpg), możesz mieć prosty skrypt bash obsługujący tymczasową część deszyfrowania / używania / usuwania; powinien także tymczasowo wyłączyć wszystkie demony synchronizacji, aby wyodrębnione klucze nie zostały przypadkowo zsynchronizowane.

Możesz zapisać swoje klucze na U1 za pomocą narzędzia do tworzenia kopii zapasowych Deja-dup. Jeśli ustawisz hasło, pliki kopii zapasowych są automatycznie szyfrowane na U1. Nie musisz tego robić ręcznie.

Istnieją różne dostępne mierniki do definiowania ryzyka, ale należy wziąć pod uwagę wartość danych lub systemów, do których klucz mógłby dać dostęp. Jeśli klucz zostanie zgubiony i jakiś podmiot może go użyć, aby uzyskać dostęp, co zostanie naruszone? Czy obawą będzie ujawnienie poufnych danych, utrata danych, możliwość naruszenia bezpieczeństwa kont z poziomu administracyjnego lub konta itp.? Jeśli możesz odtworzyć dane, które nie są poufne, i jeśli masz poufne dane bezpiecznie przechowywane (np. Zaszyfrowane), jest to mniej pilne. Myślę, że wyliczenie obejścia różnych słabości w systemie jest częścią zdefiniowania ogólnego ryzyka. Pragmatycznie nie jest prawdopodobne, aby przechowywanie pliku .id_rsa stanowiło problem, szczególnie jeśli obracasz klucze w określonych odstępach czasu. Opiera się to na kilku założeniach, ale mimo to

Proste rozwiązanie. Raczej. Jeśli nie możesz użyć czegoś takiego jak dysk flash USB, wpisz hasło na kluczu SSH. Natychmiastowe uwierzytelnianie dwuskładnikowe (w pewnym sensie). Nie musisz nawet przesyłać nowego klucza publicznego.