Bezpieczne przechowywanie opcjonalnej entropii podczas używania DPAPI

Question

Próbuję zapisać klucz symetryczny za pomocą DPAPI. Wszystko jest dobrze i świetnie, ale co zrobić z entropią? To odpowiedział na pytanie here naprawdę nie zapewnia wystarczającej wglądu. Wydaje się, że jest to śliskie zbocze - mógłbym użyć magazynu maszynowego do przechowywania entropii, ale co uniemożliwiłoby to również komuś? Uwaga: Przechowuję bieżący klucz za pomocą zakresu użytkownika.

Moje pytanie brzmi: jaki jest najlepszy sposób przechowywania entropii za pomocą DPAPI?

Answer 1

Wszystko, co przechowujesz na miejscu, może zostać naruszone. Ale są kroki, które możesz podjąć, aby to utrudnić. Istnieje dokument o numerze Handling Passwords, który możesz rozważyć przeglądając. Uważasz swój klucz Entropy za hasło specyficzne dla twojej aplikacji.

Mam zamiar odnieść się do Entropy jako klucz Klucz, ponieważ jest funkcjonalnie dodatkowym kluczem.

To, czego nie chcesz robić, to przechowywać swój klucz lokalnie w nieszyfrowanym formacie. Zamiast tego chcesz albo zaszyfrować klucz, albo wyprowadzić go z innego, nieoczywistego źródła. Oczywiście jeśli zaszyfrujesz klucz, musisz przechowywać klucz używany do jego zaszyfrowania - ale często ta pojedyncza warstwa pośrednia wystarcza, aby zniechęcić większość rywali.

To byłaby korzyść z wyprowadzenia klucza. Możesz wyprowadzić go jako mieszankę jakiegoś innego stałego zbioru danych (musi to być coś, co nie zmienia się wraz z wersjami twojej aplikacji). Jedną lewą, gdy wyprowadzamy mieszankę, jest połączenie wartości mieszania z inną stałą wartością (np. GUID lub duża liczba losowa), aby ktoś inny nie mógł po prostu połączyć znanego algorytmu i uzyskać klucz. Jest to znacznie lepsza alternatywa dla tworzenia własnego algorytmu mieszania (którego nigdy nie powinieneś robić, chyba że masz matematykę z zakresu PHD).

W pewnym momencie będziesz potrzebować jakiegoś klucza zakodowanego w aplikacji. Ten klucz jest połączony z niektórymi innymi danymi w haszach, aby utworzyć klucz Entropy lub użyć go do odszyfrowania klucza entropii. W rzeczywistości możesz zmienić klucz za pomocą nowej wersji aplikacji, o ile zachowasz stary klucz do odszyfrowania istniejącego klucza. Następnie możesz ponownie zaszyfrować go za pomocą nowego klucza lub metody.

Jeśli chcesz uzyskać najlepsze zabezpieczenie, możesz przechowywać klucz Entropy z komputera. Wymagałoby to połączenia internetowego i certyfikatu SSL, ale wtedy klucz nie jest nigdzie nigdzie utrwalany na miejscu. Aby to zrobić, możesz skonfigurować bardziej odporny system odpowiedzi na wezwania, aby uwierzytelnianie było inne za każdym razem, a klucz jest dostarczany za pomocą szyfrowania SSL, więc nie można go przechwycić. Po użyciu klucza zostaje on odrzucony. Oczywiście ten rodzaj pokonuje cel wielu scenariuszy, w których używasz DPAPI do lokalnego bezpiecznego przechowywania.

Niezależnie od tego, co robisz, pamiętaj, że zostanie naruszona - to zawsze dzieje się, gdy ktoś ma pełny dostęp do lokalnej maszyny i przechowywanych na niej danych. Rozwiązaniem tego problemu jest publikowanie aktualizacji, które zmieniają metodę na tyle, że stare pęknięcie już nie działa. To spowoduje, że dystrybucja pęknięcia stanie się mniej wartościowa, ponieważ trudno będzie ją znaleźć dla odpowiedniej wersji.

Answer 2

Po pierwsze, pozwól mi zająć się pierwotnym pytaniem o wpis. Sprowadza się to do faktu, że entropia musi być przechowywana pod autorytetem użytkownika i/lub autorytetu aplikacji, jeśli ma być używana do utrzymywania przechowywania. Przypuszczam, że można użyć klucza zapisanego w aplikacji do zaszyfrowania informacji w utrwalonym magazynie, ale znowu złośliwa aplikacja będzie mogła uzyskać dostęp do tego klucza szyfrowania. Tak więc nie uważam, że istnieje sposób ochrony przed scenariuszem, o którym wspominasz w komentarzach. Jednakże, biorąc pod uwagę to, co zostało powiedziane, jest zamierzone użycie entropii, nie wydaje mi się, że pomaga to w rozwiązaniu problemu.

Wygląda na to, że rzeczywisty problem polega na ustanowieniu bezpiecznego kanału komunikacji między aplikacją kliencką a serwerem. W swoim projekcie wymieniasz klucze, które będą używane do szyfrowania komunikacji. Myślę, że próba użycia niestandardowego kodu do rozwiązania tego problemu spowoduje dodatkowe luki w zabezpieczeniach.

Biorąc to wszystko pod uwagę, proponuję utworzyć usługę WCF (Windows Communication Foundation), która służy do pobierania poufnych informacji. Można go oczywiście użyć do pobrania wszystkich informacji, ale najmniejszą zmianą byłoby ograniczenie usługi do poufnych informacji.

Dzięki WCF możesz skonfigurować zarówno klienta, jak i serwer, tak aby korzystał z bezpiecznego kanału. WCF ma wiele opcji do ustanowienia bezpiecznego kanału komunikacji z serwerem.

<wsHttpBinding> 
    <binding> 
     <security mode="Transport"> 
      <transport clientCredentialType="Windows" /> 
     </security> 
    </binding> 
</wsHttpBinding> 

Po bezpiecznym kanale wiele innych problemów jest prostszych, takich jak dostęp do danych CC. Jeśli te dane są wysyłane do bezpiecznego kanału, staje się kwestią autoryzacji zamiast bezpieczeństwa kanału.

Więcej informacji na stronie How to: Create a Secure Session.