Certyfikat kwalifikowany - Czy da się wyciągnąć klucz prywatny?

0

Czy jakiś urząd certyfikacji pozwala na otrzymanie certyfikatu kwalifikowanego tak aby
mieć całą paczkę danych czyli klucz prywatny/publiczny i certyfikat i wrzucić na serwer
i zautomatyzować proces podpisywania?
Z tego co wiem mamy karty kryptograficzne, z których klucza prywatnego nie da się wyciągnąć
i to one są odpowiedzialne za realizację podpisu jakiś danych, my podajemy tylko pin do karty
i zwykle trzeba mieć jakieś oprogramowanie, które skomunikuje się z tą kartą i podpisze jakieś dane.
Ja potrzebuję jednak mieć ten certyfikat kwalifikowany wraz z kluczami (najlepiej w jednym pliku .p2 lub .pfx)
gdzieś na serwerze gdzie aplikacja, która go wczyta będzie mogła go wykorzystać w celu podpisania danych.
Czy jest to możliwe? Jak wygląda sytuacja z certyfikatami wydawanymi na pendrive, czy są w postaci jawnej,
czy raczej w jakiś sposób zaszyfrowane i potrzebny jest pin (strzelam, że raczej to drugie)?
Czy da się wyeksportować te dane?

Klient chce zautomatyzować proces podpisywania dokumentów jego certyfikatem kwalifikowanym,
z tym, że nie chce go za bardzo udostępniać. Ja myślę, że tego typu certyfikaty są raczej do podpisywania
osobistych dokumentów i średnio się nadają do masowych automatycznych podpisów. Jednak
musi być to podpis kwalifikowany ponieważ te dane już podpisane idą do zewnętrznego systemu,
który wymaga aby były podpisane właśnie certyfikatem kwalifikowanym.

Proszę o sugestie.

8

Klucz prywatny z założenia jest prywatny i to totalnie. Jeśli klucz prywatny został wygenerowany przez użytkownika, firmę czy instytucję X to nie wolno go przekazywać użytkownikowi, firmie czy instytucji Y. Jeśli klucz prywatny zostanie przesłany od X do Y to już nie jest prywatny tylko compromised. Stąd jeśli chcesz by ktoś podpisał twój certyfikat to tworzysz CSR (certificate signing request) dzięki któremu nie musisz przesyłać klucza prywatnego, ale i tak udowadniasz że posiadasz klucz prywatny, tzn CSR zawiera dowód że pochodzi od właściciela klucza prywatnego.

Co do reszty to nie wiem, bo nie miałem do czynienia z urządzeniami (do szyfrowania dokumentów), które zawierają prywatne certyfikaty. Nie jestem nawet pewien jaki dokładnie proces szyfrowania i przekazywania kluczy chcesz osiągnąć.

1

Szkoda, że to co napisał @Wibowit mało osób rozumie, na dodatek problem dotyczy też programistów adminów i ogólnie całego IT, który powinien obligatoryjnie to rozumieć.
Teraz pracuje dla pewnej znanej firmy, która się powinna znać na bezpieczeństwie z racji swojego profilu.
Szczena mi opadła do ziemi jak zobaczyłem, że klucze generuje serwer i admin może je ściągnąć (jako pfx) i zainstalować na klientach.

W poprzedniej firmie było podobnie, zgłosiłem menadżerowi buga dokładnie związanego z tym problemem i ostrzegłem, iż produkt nie przejdzie przez to certyfikacji JITC (produkt miał być używany w jednostce rządowej USA). Ostrzeżenie zgłosiłem na 6 miesięcy przed oficjalnym stwierdzeniem tego faktu, ale zostałem zignorowany bo osoba, która to zakodowała przekonywała, że jest dobrze.

0

Klucz prywatny z założenia jest prywatny i to totalnie. Jeśli klucz prywatny został wygenerowany przez użytkownika, firmę czy instytucję X to nie wolno go przekazywać użytkownikowi, firmie czy instytucji Y.

Jeżeli instalacja odbywa się na naszych serwerach to klient chyba musi przekazać ten klucz prywatny dla admina aby on mógł go podpiąć (np. w przypadku certyfikatów komunikacyjnych ssl/tls)?

Stąd jeśli chcesz by ktoś podpisał twój certyfikat to tworzysz CSR (certificate signing request) dzięki któremu nie musisz przesyłać klucza prywatnego, ale i tak udowadniasz że posiadasz klucz prywatny, tzn CSR zawiera dowód że pochodzi od właściciela klucza prywatnego.

Ok czyli generuje własny klucz prywatny i tworzę CSR i daję dla klienta aby podpisał to swoim certyfikatem kwalifikowanym?
System, który będzie realizował podpisywanie wysyła to do zewnętrznego systemu, który wymaga aby dane były podpisane
certyfikatem kwalifikowanym tzn. że zwykłe certyfikaty komunikacyjne ssl/tls tu nie zadziałają ponieważ zewnętrzny system
waliduje czy owy certyfikat, został wystawiony jako certyfikat kwalifikowany chociaż z punktu widzenia technicznego składają
się z tym samych komponentów (czyli np. para klucz prywatny, publiczny rsa).

Mój problem polega na tym, że mam napisany mechanizm podpisywania, który aby coś podpisać
potrzebuje klucza prywatnego (np. gdzieś na dysku w postaci pliku .pfx razem z certyfikatem - który dodatkowo musi być kwalifikowany aby system wewnetrzny taki podpis przyjął).
Certyfikat kwalifikowany posiada klient na pendrive i nie chce się nim podzielić aby system mógł go wykorzystać do podpisów i w sumie słusznie bo nie można nim
się dzielić z resztą nawet jakby nim się podzielił to nie wiem czy byłbym w stanie go wyeksportować, prawdopodobnie na pendrive jest on przechowywany
w jakiejś formie zaszyfrowanej i zwykle jest do tego jakiś dedykowany program np. Szafir.

Myślałem więc o tym aby klient zgłosił się do jakiegoś CA i poprosił o kolejny certyfikat kwalifikowany dedykowany do tego systemu,
wtedy ja bym otrzymał całą paczkę, klucz prywatny, certyfikat itd. i wrzucilbym na serwer.
Warto zaznaczyć, że certyfikat kwalifikowany jest imienny tzn. nie można podać nazwy firmy/instytucji itp. on jest przypisany
do konkretnej osoby. Jednak z tego co wiem jedna osoba może mieć wiele certyfikatów kwalifikowanych więc klient miałby po prostu 2.

Wspomnę też, że klient nie jest za bardzo techniczny i wymyślił takie rozwiązanie,
że będzie wchodził do panelu administracyjnego poda pin do cert kwalifikowanego,
wybierze plik certyfikatu + klucz prywatny z dysku, pojdzie upload na serwer i na servie system bedzie mial
juz klucz prywatny aby podpisywac, i system bedzie cykliczne usuwał klucz prywatny dla "bezpieczenswa"...

3

Myślę, że powinieneś porozmawiać zarówno z dostawcą podpisów kwalifikowanych jak i autorami zewnętrznego systemu, który takich podpisów wymaga.

Zasada nieprzesyłania kluczy prywatnych jest żelazna. Przesyłanie swojego klucza prywatnego na zewnątrz w zasadzie niweluje sens jego istnienia.

Ogólnie cały zaproponowany schemat wygląda podejrzanie. Jeżeli wasz system ma decydować o tym jakie dokumenty zostają podpisane to powinien być podpisany waszym podpisem, a nie podpisem klienta. W zabezpieczeniach chodzi o semantykę, a nie że program coś tam pokazał (np kłódka w przeglądarce niekoniecznie oznacza, że jesteśmy bezpieczni). Jeśli coś jest podpisane podpisem Kowalskiego to oczekuję, że Kowalski sam to podpisywał, a nie że ktoś to podpisywał w jego imieniu. Obojętnie czy to jest podpis elektroniczny czy odręczny.

Same podpisy, certyfikaty, dokumenty, etc posiadają metadane, więc teoretycznie (w sensie bardzo teoretycznie, bo nie wiem czy takie coś jest dozwolone) można by np w certyfikacie wygenerowanym na serwerze zawrzeć informację, że to ma być do podpisywania dokumentów konkretnego użytkownika. Mimo wszystko jak dla mnie byłoby to jednak dziwne i podejrzane.

Certyfikat kwalifikowany posiada klient na pendrive i nie chce się nim podzielić aby system mógł go wykorzystać do podpisów i w sumie słusznie bo nie można nim
się dzielić (...)

Wspomnę też, że klient nie jest za bardzo techniczny i wymyślił takie rozwiązanie,
że będzie wchodził do panelu administracyjnego poda pin do cert kwalifikowanego,
wybierze plik certyfikatu + klucz prywatny z dysku, pojdzie upload na serwer i na servie system bedzie mial
juz klucz prywatny aby podpisywac, i system bedzie cykliczne usuwał klucz prywatny dla "bezpieczenswa"...

No to chce się dzielić kluczem prywatnym czy nie? Chce się dzielić, ale tylko na swój sposób? Tak czy siak nie powinien i trzeba go o tym uświadomić.

1 użytkowników online, w tym zalogowanych: 0, gości: 1