Chcę, aby ktoś inny zaszyfrował tajne dane moim kluczem publicznym, który mogę następnie odszyfrować moim kluczem prywatnym. Stworzyłem parę kluczy prywatny / publiczny RSA, a OpenSSL dał im klucz publiczny i wszystko działa.
Niedawno ktoś wskazał, że jesteśmy narażeni na atak typu man-in-the-middle gdzie złoczyńcy zaakceptowaliby mój klucz publiczny i przekazali swój własny klucz publiczny drugiej stronie. Następnie druga strona sumiennie zaszyfruje tajne dane, przekaże je do MITM, który je odszyfruje, ponownie zaszyfruje za pomocą mojego klucza publicznego, zanim przekaże mi go, nie będąc mądrzejszym. Zalecanym rozwiązaniem jest podpisanie mojego klucza publicznego przez urząd certyfikacji, któremu ufa druga strona, przed przekazaniem go.
W ramach eksperymentu utworzyłem CSR, który mogłem podpisać własnym CA, ale wynikowy certyfikat zawiera również (zaszyfrowany) klucz prywatny. Wolałbym nie przekazywać nikomu swojego tajnego klucza, zaszyfrowanego lub nie.
Czy istnieje sposób, aby po prostu podpisać mój klucz publiczny?
Komentarze
- Certyfikat zawiera klucz prywatny? Co? Jak ci się to udało? Czy możesz opublikować ten plik na pastebin.com? (Powtórz to z drugą parą kluczy, abyś ' nie musiał udostępniać oryginału).
- Myślę, że zaczynam rozumieć. Mimo że potrzebuję klucza prywatnego do wygenerowania CSR, CSR i wynikający z niego certyfikat nie zawierają klucza prywatnego. Certyfikat jest faktycznie podpisanym kluczem publicznym, czyli dokładnie tym, czego chcę.
Odpowiedź
Podpisywanie klucza publicznego jest faktycznie certyfikatem. Oto kroki, które podejmuję, aby utworzyć certyfikat klucza publicznego, który mogę przekazać innym, aby mogli się ze mną bezpiecznie komunikować:
Konfiguracja
- Wygeneruj klucze prywatne:
openssl genrsa -out private.pem 2048
- Wygeneruj klucze publiczne:
openssl rsa -in private.pem -outform PEM -pubout -out public.pem
- Utwórz CSR (żądanie podpisania certyfikatu)
openssl req -new -key private.pem -out certificate.csr
- Utwórz certyfikat z podpisem własnym (możesz udostępnić ten certyfikat)
openssl x509 -req -days 365 -in certificate.csr -signkey private.pem -out certificate.crt
Szyfrowanie
openssl rsautl -encrypt -inkey private.pem -keyform PEM -in data> zaszyfrowane_dane
Deszyfrowanie
- Wyodrębnij klucz publiczny z certyfikatów
openssl x509 -pubkey -noout -in certificate.crt> certpubkey.pem
- Odszyfruj dane
openssl rsautl -decrypt -inkey certpubkey.pem -keyform PEM -pubin -in encrypted_data> dane
Jeśli zamierzasz mieć swój klucz podpisany przez CA, będziesz musiał wysłać swój plik CSR (i trochę gotówki) do wybranego CA, otrzymasz od niego certyfikat, którego możesz użyć zamiast certyfikatu z podpisem własnym I wspomniane w powyższych krokach.
Komentarze
- To jest coś w rodzaju odwrotności tego, o co proszę, ale zrobi to na potrzeby dyskusji. Aby druga strona mogła odszyfrować, potrzebują albo wyodrębnionego przeze mnie klucza publicznego, który jest przedmiotem ataku MITM, albo całego certyfikatu, który zawiera (zaszyfrowany) klucz prywatny.
- @ user1683793 drugi koniec potrzebuje dwóch certyfikatów. Pierwszy z nich powinien już mieć (certyfikat CA z podpisem własnym). Drugi zawiera klucz publiczny, który chcesz zweryfikować, i jest podpisany certyfikatem CA (przy użyciu powiązanego klucza prywatnego CA). Ważność drugiego certyfikatu jest sprawdzana przy użyciu klucza publicznego w certyfikacie CA. Klucze prywatne są zawsze prywatne.
- Myślę, że chcesz ” -encrypt ” i ” -decrypt ” zamiast ” -sign ” i ” -verify „. (Szczegóły tutaj: czeskis.com/random/openssl-encrypt-file.html )
- Nie działa: 2. Odszyfrowanie danych nie działa dla mnie. W przypadku:
openssl rsautl -decrypt -inkey certpubkey.pem -keyform PEM -pubin -in encrypted_data > datapojawia się ten błąd / msg:A private key is needed for this operation - Sekcja
Setup, step2dajepublic.pem– nie jest już ' nie używany w żadnym innym kroki. Jaki jest pożytek z tego klucza publicznego, gdy CSR jest generowany przy użyciu klucza prywatnego?
Odpowiedź
W proces powinny być zaangażowane trzy podmioty:
- Nadawca – Ty
- Odbiorca – Użytkownik
- Urząd certyfikacji – Zaufana strona trzecia (lub w niektórych przypadkach Ty)
Proces który zapewnia bezpieczeństwo, to „Nadawca”, generuje parę kluczy (publiczny i prywatny). Lubię nazywać je kluczem i zamkiem, aby uzyskać lepszy obraz. Klucz (prywatny) nigdy nie powinien pozostawać w posiadaniu nadawcy, dlatego nazywa się go kluczem prywatnym.
Następnie nadawca generuje żądanie podpisania certyfikatu (CSR) z kluczem publicznym (blokada ), który jest przekazywany do ośrodka certyfikacji (zaufanej strony trzeciej), urząd certyfikacji podpisuje klucz publiczny (blokadę) kluczem prywatnym urzędu certyfikacji.
Urząd certyfikacji wysyła teraz klucz publiczny „Nadawcy” który jest podpisany przez klucz prywatny urzędu certyfikacji z powrotem do „Nadawcy”, który jest teraz certyfikatem.
Odbiorca otrzymuje certyfikat (powiedzmy przez przeglądarkę internetową) i sprawdza, czy jest ważny klucz publiczny urzędu certyfikacji, który mają zarówno „nadawca”, jak i „odbiorca”, ponieważ są one zaufaną stroną trzecią. Po zweryfikowaniu, klucz publiczny w certyfikacie może być zaufany * jako niezmieniony klucz publiczny „Nadawcy”.
Jeśli „Odbiorca” musi wysłać dane do „Nadawcy”, użyje klucz publiczny z zaufanego certyfikatu w celu zaszyfrowania danych na szyfrogram, który następnie jest przekazywany do „Nadawcy”. Ponieważ tylko prywatny klucz „Nadawcy” może odszyfrować zaszyfrowany tekst zaszyfrowany kluczem publicznym „Nadawcy” każdy pośrodku w zasadzie zawiera bezużyteczny, zniekształcony tekst.
W niektórych przypadkach „Nadawca” może wygenerować swój własny ośrodek certyfikacji, podpisując własny CSR innym zestawem kluczy lub samopodpisując się tym samym zestawem W tym przypadku klucz publiczny „Nadawcy” musi być znany obu stronom za pośrednictwem bezpiecznego kanału, aby można było mu zaufać. W oprogramowaniu możesz dołączyć certyfikat do elementu dostarczanego, który może być używany jako zaufana strona trzecia.
* Zaufany jest ważny tylko wtedy, gdy urząd certyfikacji prowadzi listę CRL (lista unieważnionych certyfikatów), a wszystkie strony monitorują listę aby upewnić się, że wydany certyfikat nie został naruszony. Sytuacja, w której urząd certyfikacji jest zagrożony i klucz prywatny wycieknie, a kiedy tak się stanie, agent naruszający bezpieczeństwo może użyć klucza prywatnego do wygenerowania zaufanego certyfikatu naśladującego „Nadawcę” , w takim przypadku MITM jest możliwy i MITM może odbierać dane od „Nadawcy” odszyfrować, zapisać, zaszyfrować za pomocą ważnego certyfikatu, który wygląda jak „Nadawca”, a następnie przekazać go do „Odbiorcy”.
Odpowiedź
Wyjmij zaszyfrowany klucz prywatny z kopii utworzonego przez siebie certyfikatu CA (podczas przekazywania go innym). Klucz prywatny nie Nie musisz tam być, chyba że zamierzasz użyć go do podpisania certyfikatu zawierającego coś takiego er klucz publiczny.
Kiedy przesyłasz swój klucz publiczny, zamiast tego prześlij cały certyfikat (z wyjątkiem klucza prywatnego), podpisany przy użyciu powiązanego klucza prywatnego CA. Aby sprawdzić ważność klucza publicznego w nim zawartego, należy porównać skrót certyfikatu z zaszyfrowanym hashem (który został zaszyfrowany przy użyciu prywatnego klucza urzędu certyfikacji). Jest on odszyfrowywany przy użyciu klucza publicznego urzędu certyfikacji . Jeśli odszyfrowanie powiedzie się, a hash jest zgodny z hashem certyfikatu, można zaufać informacjom zawartym w certyfikacie.
Jest to również coś więcej niż tylko szyfrowanie, na przykład atak polegający na powtórzeniu osoba atakująca wysyła zapisane wcześniej zaszyfrowane dane. TLS obejmuje znacznie więcej, niż mógłby przypuszczać przeciętny człowiek, a wdrażanie podobnego systemu absolutnie nie jest zalecane. Używaj TLS, gdy tylko jest to możliwe, do wszystkiego, co ma być prywatne.