Witaj Gościu, jeżeli to czytasz to znaczy że nie jesteś zarejestrowany/zalogowany. Kliknij by się zarejestrować. Rejestracja zajmie mniej niż 30 sekund , a dzięki temu zniknie Ci ten dymek oraz będziesz miał pełne możliwośći personalizacji forum do własnych potrzeb.
[How-To] PKI czyli SMIME w Kmail'u (gpgsm)
Pokaż wyniki od 1 do 1 z 1

Temat: [How-To] PKI czyli SMIME w Kmail'u (gpgsm)

  1. #1
    Dołączył
    Dec 2004
    Wiek
    40
    Postów
    12
    Wątków
    4
    Downloads
    0
    Uploads
    0
    Siła Reputacji
    0
    Reputacja
    11

    [How-To] PKI czyli SMIME w Kmail'u (gpgsm)

    Wstęp

    Jedną z możliwości, jakie daje nam infrastruktura klucza publicznego (PKI), jest możliwość używania kluczy i certyfikatów do podpisywania lub szyfrowania poczty elektronicznej. Odbywa się to za pomocą protokołu SMIME (czyli Secure MIME). W niniejszym poradniku przedstawię jak skonfigurować wszystkie niezbędne elementy, tak aby można było w ostatecznym rozrachunku używać SMIME w KMailu. Będziemy potrzebowali następującego oprogramowania:

    GnuPG2 (gpgsm, gpg-agent, dirmngr)
    Kmail (oraz zarządzanie certyfikatami czyli program Kleopatra
    KwatchGnuPG (do wglądu w log)
    pinentry (a dokładnie qtpinentry)

    Całość tego poradnika została przygotowana tak, aby jednocześnie stanowiła wstęp do używania podpisu kwalifikowanego pod Linuksem. Jako wstępną lekturę polecam artykuł na temat OpenSSL .

    Konfiguracja GnuPG2

    W Mandrivie wszystkie pliki konfiguracyjne i potrzebne katalogi znajdują się w katalogu domowym użytkownika w katalogu .gnupg Manuale do odpowiednich programów wskazują inne lokalizacje, jednak my zastosujemy katalog domowy. Część katalogów trzeba założyć samemu:

    crls.d -> dirmngr-cache.d <- link do katalogu z listami crl
    dirmngr-cache.d <- katalog z listami crl
    extra-certs <- dodatkowe certyfikaty ładowane do cache programu dirmngr
    private-keys-v1.d <- zaimportowane klucze prywatne
    trusted-certs <- zaufane certyfikaty (certyfikaty CA)

    KMail komunikuje się z pozostałymi programami za pomocą programu gpg-agent. Generalnie KMail potrafi sam wystartować gpg-agenta lub dirmngr, jedna dla naszych potrzeb nie jest to wygodne rozwiązanie. Dlatego my będziemy startować obydwa programy w momencie uruchamiania KDE. Należy stworzyć dwa skrypty:

    W katalogu $HOME/.kde/env/agent_start.sh :

    Kod:
    if test -f ${HOME}/.gnupg/.gpg-agent-info && kill -0 `cut -d: -f 2 ${HOME}/.gnupg/.gpg-agent-info` 2>/dev/null; then
       export GPG_AGENT_INFO=`cat ${HOME}/.gnupg/.gpg-agent-info`
    else
       eval `gpg-agent --allow-mark-trusted --daemon`
       echo ${GPG_AGENT_INFO} >${HOME}/.gnupg/.gpg-agent-info
       export GPG_AGENT_INFO=`cat ${HOME}/.gnupg/.gpg-agent-info`
       eval `dirmngr --homedir ${HOME}/.gnupg --daemon`
       echo ${DIRMNGR_INFO} > ${HOME}/.gnupg/.dirmngr-info
       export DIRMNGR_INFO=`cat ${HOME}/.gnupg/.dirmngr-info`
    fi
    W katalogu $HOME/.kde/shutdown/agent_stop.sh :
    Kod:
    #!/bin/sh
    [[ -n ${GPG_AGENT_INFO} ]] && kill `echo ${GPG_AGENT_INFO} | cut -d ':' -f 2`
    [[ -n ${DIRMNGR_INFO} ]] && kill `echo ${DIRMNGR_INFO} | cut -d ':' -f 2`
    Programy komunikują się za pomocą zmiennych GPG_AGENT_INFO oraz DIRMNGR_INFO (pod którymi kryją się wskazania soketów na których nasłuchują programy). Musimy mieć te zmienne wyeksportowane globalnie oraz zapisane do plików. Do późniejszego wykorzystania

    Każdy z tych programów potrzebuje swoich plików konfiguracyjnych umieszczony w katalogu .gnupg :

    [piotr@agryppa .gnupg]$ cat gpg-agent.conf
    scdaemon-program /usr/bin/scdaemon
    debug-level basic
    log-file socket:///home/piotr/.gnupg/server.log

    [piotr@agryppa .gnupg]$ cat dirmngr.conf
    allow-ocsp
    debug-level basic
    log-file socket:///home/piotr/.gnupg/server.log

    [piotr@agryppa .gnupg]$ cat gpgsm.conf
    #disable-crl-checks <- włączenie tej opcji upraszcza korzystanie z całości (jednak nie będziemy wiedzieli czy certyfikat jest ważny)
    #disable-policy-checks
    #auto-issuer-key-retrieve
    debug-level basic
    log-file socket:///home/piotr/.gnupg/server.log

    Do tego pliku robimy link o nazwie ldapservers.conf

    [piotr@agryppa .gnupg]$ cat dirmngr_ldapservers.conf
    agryppa.homelinux.org:389:::dc=Agryppa
    193.178.164.16:389:::c=PL
    193.178.164.4:389:::c=PL
    ldap.certyfikat.pl:389:::c=PL

    Jak widać, w pliku z serwerami LDAP mamy wpisany mój własny LDAP, oraz serwery katalogowe Sigillum oraz Unizeto. Proponuję też wpisać te serwery (no oczywiście poza moim) do książki adresowej w programie Kontact.

    Po przelogowaniu się, mamy w tle uruchomione programy gpg-agent oraz dirmngr (można to sprawdzić poleceniem ps). Jeśli tak to kontynuujemy.

    Importowanie kluczy, certyfikatów oraz list crl

    Biorąc pod uwagę wsparcie jakiego udzielają Linuksowi polscy wystawcy podpisów kwalifikowanych (a raczej jego całkowitego braku), na dzień dzisiejszy możemy zrobić dwie rzeczy. Możemy wyszukać w katalogu LDAP osobę do której chcemy napisać, zaimportować jej certyfikat a następnie napisać do tej osoby emaila zaszyfrowanego jej certyfikatem. Osoba ta odczyta tego emaila w systemie Windows. Oczywiście w przypadku naszego własnego CA nie ma żadnych ograniczeń. Możemy wygenerować tyle kluczy i certyfikatów ile nam się podoba (i zaimportować je albo pod Linuksem albo pod Windowsem lub innym systemem).

    Do katalogu trusted-certs wgrywamy ściągnięte przez nas ze stron www.sigillum.pl oraz www.certum.pl certyfikaty (zaświadczenia) CA oraz wgrywamy też certyfikat naszego własnego CA:

    cacert.crt (to certyfikat mojego CA)
    CERTUM_QCA.crt
    rootca.crt
    Sigillum_UZC.crt
    subca.crt
    subca_old.crt
    Unizeto_CERTUM-CCK-CA.crt

    W katalogu .gnupg tworzymy plik trustlist.txt w którym umieszczamy odciski fingerprint (SHA1) kluczy którym ufamy, wygląda on tak:

    [piotr@agryppa .gnupg]$ cat trustlist.txt
    16BE2CD2BAAF1ACBD436460830F8776254536405 S
    36E41461FC16EB01C0EEE972C61749F1AA8487DF S
    6252DC40F71143A22FDE9EF7348E064251B18118 S
    800E32F42544F9B8133D408FD61B3A56DFEF5157 S
    7A01F022A20242457D753609DFFF0035E4A233F4 S

    Literka S (po dwóch spacjach) oznacza zaufanie

    To nie konieć, tworzymy plik qualified.txt który zawiera odciski kwalifikowanych, głównych (root) CA:

    [piotr@agryppa .gnupg]$ cat qualified.txt
    16BE2CD2BAAF1ACBD436460830F8776254536405 pl
    36E41461FC16EB01C0EEE972C61749F1AA8487DF pl
    6252DC40F71143A22FDE9EF7348E064251B18118 pl
    800E32F42544F9B8133D408FD61B3A56DFEF5157 pl

    Uruchamiamy program Kleopatra (KMail-->Narzędzia-->Zarządzanie certyfikatami) i importujemy ściągnięte certyfikaty. Warto też ściągnąć i zaimportować ze strony www.centrast.pl certyfikat naszego Narodowego CA.

    Możemy też stworzyć plik z politykami policies.txt (muszę przyznać że jak dla mnie jest to chyba najmniej ważny i potrzebny plik):

    [piotr@agryppa .gnupg]$ cat policies.txt
    1.2.616.1.113560.10.1.1.0
    2.5.29.32.0
    1.2.616.1.113560.1.200.10.1
    1.2.3.3.9994
    1.2.3.3.5
    1.2.3.3.6
    1.2.3.3.7
    1.2.3.3.8

    Do pliku zostały po prostu wklejone polityki danego certyfikatu (widoczne np. w szczegółowym podglądzie certyfikatu w programie Kleopatra).

    W tym miejscu możemy też zaimportować nasz własny klucz lub wygenerować go za pomocą programu Kleopatra (wraz z plikiem żądania req). Po wygenerowaniu, żądanie musimy certyfikować (jest to opisane tu) w naszym CA a certyfikat zaimportować Kleopatrą. W Unizeto można wygenerować, darmowy, testowy (ważny 3 miesiące) 'prawdziwy' certyfikat. Istnieje też kilkanaście innych zachodnich wystawców oferujących darmowe proste certyfikaty.

    Teraz zajmiemy się listami CRL. Lista CRL to nic innego jak zbiór zawierający informację o odwołanych certyfikatach. W naszym przypadku będziemy potrzebowali listy CRL ściągnięte z Sigillum oraz Unizeto a także naszej własnej listy CRL. Sprawdzanie ważności certyfikatu można wykonać na dwa sposoby, albo za pomocą listy CRL (które to listy trzeba regularnie ściągać, przeważnie ich okres ważności to 12 godzin) albo za pomocą mechanizmu OCSP. OCSP umożliwia sprawdzanie online informacji na temat danego certyfikatu. O ile ja w moim własnym CA wystawiam listy CRL ważne 90 dni, o tyle nasi 'kochani' wystawcy kwalifikowani wystawiają listy ważne tylko 12 godzin (co dokładnie znaczy że nowa lista pojawia się co 12 godzin lub w momencie odwołania certyfikatu, tak więc godziny publikacji są zmienne). Aby być w miarę na bieżąco, napisałem skrypt uruchamiany z crona co 12 godzin o 6 i 18 który ściąga odpowiednie listy i importuje je do dirmngra oraz odświeża cache samego programu.

    Kod:
    [piotr@agryppa Skrypty]$ cat crl_reload.sh
    #!/bin/bash
    #############################
    # CRL Reload (c) Piotr Pisz #
    #############################
    #
    CACHE="${HOME}/.gnupg/crl_cache"
    #
    if [ ! -d ${CACHE} ]; then
           mkdir -p ${CACHE}
    fi
    #
    rm ${CACHE}/*
    cd ${CACHE}
    #
    cp /etc/pki/CA/crls/cacrl.crl ${CACHE}
    #
    UNI0="http://crl.certum.pl"
    UNI1="https://crl.certum.pl"
    PKW="http://193.178.164.4/repozytorium/ca1.crl"
    PKO="http://193.178.164.16/repozytorium/ca2.crl"
    CRT0="${UNI0}/ca.crl"
    CRT1="${UNI0}/class1.crl"
    CRT2="${UNI0}/class2.crl"
    CRT3="${UNI0}/class3.crl"
    CRT4="${UNI0}/class4.crl"
    CRTQ="${UNI1}/qca.crl"
    CRTC="${UNI1}/cck-ca.crl"
    #
    get_crl()
    {
           for CRL in ${PKW} ${PKO} ${CRT0} ${CRT1} ${CRT2} ${CRT3} ${CRT4} ${CRTQ} ${CRTO}
           do
                   wget --no-check-certificate ${CRL}
           done
    }
    #
    dir_import()
    {
           dirmngr --flush
           CRL=`ls -1 *.crl`
           for CRT in ${CRL}
           do
                   dirmngr --load-crl ${CACHE}/${CRT}
           done
    }
    #
    get_crl
    dir_import
    #
    kill -SIGHUP `cat ${HOME}/.gnupg/.dirmngr-info | cut -d ':' -f 2`
    Wszystko pięknie, wszystko ładnie. A teraz łyżka dziegciu. Klucz ROOTCA Sigillum (kwalifikowany) nie zawiera w sobie informacji keyID (!), uniemożliwia to zaimportowanie listy ca2.crl (dirmngr nie jest w stanie powiązać jej z żadnym kluczem), klucze główne Unizeto CA, LevelI...IV (komercyjne) nie są publikowane w LDAP co uniemożliwia zaimportowanie ich list CRL (na dzień dzisiejszy dirmngr odwołuje się bezpośrednio do LDAP w celu sprawdzenia podpisu wystawcy listy CRL). Oczywiście z naszą listą nie będzie problemu o ile będziemy mieć własny serwer LDAP Taką listę można też zaimportować za pomocą Kleopatry. Zawsze też można wyłączyć sprawdzanie list CRL w pliku gpgsm.conf

    OK, no to mamy klucze, certyfikaty, listy CRL - jedziemy dalej

    Konfiguracja KMail

    A tutaj to już szybciutko, wybieramy konfigurację KMail'a, pozycję Bezpieczeństwo, zakładka SMIME i zaznaczamy co jest nam potrzebne

    Podsumowanie

    Na dzień dzisiejszy dzięki projektowi Aegypten (http://www.gnupg.org/aegypten/) oraz bibliotece gpgme (Made Easy) no i oczywiście całemu pakietowi GNUPG2 wsparcie w Linuksie dla certyfikatów x509 jest już na poziomie pełnej używalności. Można mieć ciągle wiele zastrzeżeń i życzeń do poszczególnych części składowych (Kleopatra wiesza się często przy przeszukiwaniu katalogów LDAP) ale nie zmienia to faktu że całość jest już w pełni funkcjonalna. Artykuł ten można też traktować jako wprowadzenie do używania podpisu kwalifikowanego w Linuksie (w końcu nie da się Linuksa ignorować przez wieczność). CryptoTech (dostawca rozwiązań dla Sigillum) przez jakiś czas rozwijał swoje oprogramowanie do obsługi kart kryptograficznych CryptoSign pod Linuksa. Niestety później zostało ono zarzucone, na szczęście w ostatniej TODO CryptoSign jest informacja że następna wersja będzie też dostępna pod Linuksa Unizeto zignorowało moje zapytanie o wsparcie Linuksa... Mam nadzieję że całość zawartych tu informacji okaże się dla kogoś przydatna, chętnie się też wymienię doświadczeniami w tej problematyce

    Piotr
    piotr@agryppa.homelinux.org

    P.S. Aktualizacje i inne powiązane artykuły znajdziecie na mojej małej Wiki

Informacje o wątku

Users Browsing this Thread

Aktualnie 1 użytkownik(ów) przegląda ten wątek. (0 zarejestrowany(ch) oraz 1 gości)

Uprawnienia

  • Nie możesz zakładać nowych wątków
  • Nie możesz pisać wiadomości
  • Nie możesz dodawać załączników
  • Nie możesz edytować swoich postów
  •