certificates.tex

\chapter{Tanúsítvány-kiszolgáló (CA) és titkosítás}

Manapság elengedhetetlen a hálózati forgalom titkosítása, bármilyen környezetről legyen is szó. Ennek elmulasztása
jelentős kockázattal járhat, mert illetéktelen személyek (harmadik félnek is nevezik) hozzájuthatnak olyan adatokhoz,
amikre nem jogosultak. Bár a legbiztonságosabb titkosítás az egyszer használatos kulcs (One Time Padding, OTP), sajnos
nem valósítható meg gazdaságosan, ezért általában a nyilvános kulcsú titkosítást (és~hitelesítést) szokták
használni. A kapcsolat során fontos annak ismerete is, hogy kivel történik a kommunikáció (nem egy harmadik személy,
hanem tényleg az, akinek gondoljuk). A tanúsítványok használata ezekre a problémákra nyújt jó megoldást.


\section{A nyilvános kulcsú rendszerek és a tanúsítványok}
A nyilvános kulcs használata nagy számításigényű, ugyanis két nagy prímszámot szükséges találni, majd az ezekből
képezett kulcsokkal kell a kódolást elvégezni. Ezért a titkosított kapcsolatok esetén az terjedt el, hogy egy ilyen
rendszerrel (például RSA kódolással) a kapcsolat elejét kódolják, amely alatt egy megfelelően hosszú kulcsot cserélnek,
majd szimmetrikus kódolással folytatódik a kommunikáció. Ennek a módszernek előnye, hogy továbbra is biztonságos marad,
ámde gyorsabban is működik.

Aki nyilvános kulcsú hitelesítést vagy titkosítást szeretne használni, annak egy kulcspárra lesz szüksége, amely egy
magán (privát) kulcsból és egy publikus (nyilvános) kulcsból áll, az utóbbit bárki ismerheti, az előbbit azonban csak a
tulajdonos. A hitelesítés valójában aláírást jelent, egy elektronikus aláírással védett adat sértetlenségét hivatott
bizonyítani. Az aláírás a privát kulcs használatával történik, ellenőrzése pedig a publikus kulccsal. A~titkosítás
viszont fordítva használja fel a kulcsokat, a publikus féllel titkosított szöveget (adatot) csak a kulcspár privát
részének ismeretében lehet elolvasni. Ezért fontos a magán kulcs védelme, hiszen ellenkező esetben más is hozzáférne az
adatokhoz (információkhoz, el tudná olvasni a levelet).

Az ilyen jellegű felhasználás azonban felvet egy problémát, és pedig azt, hogy a publikus rész felhasználója nem
tudhatja teljes bizonyossággal, hogy a kulcspár valóban azé, akiének gondolja. Ezen probléma megoldására több
lehetőségünk is van, mindegyiknek vannak előnyei és hátrányai is. Az egyik lehetőség, hogy a publikus kulcsot úgy
továbbítjuk, hogy az semmilyen hálózaton nem megy keresztül, hanem például pendrive-ot használunk, vagyis a kulcs
sértetlensége garantált marad. Sajnos a legtöbb esetben ez nem kivitelezhető, ugyanis a fizikai távolság vagy más
tényező meggátol minket ebben. Másik lehetőség, hogy publikus kulcsot  csak már korábban is ismert publikus kulccsal
aláírtan fogadunk el (vagyis a korábbi kulcs hitelesíti az újat). Természetesen legalább egy publikus kulcsban meg kell
bíznunk, hogy ez a lehetőség működőképes legyen. Az X.509-es tanúsítványok pont ezt valósítják meg, és az Interneten
egy-egy kiszolgáló ilyen tanúsítványt használ.


A publikus kulcsot foglaljuk tanúsítványba további információkkal együtt. Ezen információk közül a leglényegesebb, hogy
ki írta alá (ki igazolja a tanúsítványunk hitelességét). Emellett szerepel a tanúsítvány neve is, valamint a hozzá
tartozó ország, állam, szervezet, szervezeti egység, egy e-mail cím, esetleg más információk is.

Most már meg tudjuk állapítani, hogy a tanúsítványt ki írta alá, és ezáltal azt is, hogy az aláíró tanúsítvány kitől
származik, illetve azt is, hogy ki írta alá, és így tovább. A~tanúsítványok ennek megfelelően 
ún. tanúsítványláncot alkotnak. Az egyik
végén van a mi tanúsítványunk, a másik végén pedig az a kitüntetett tanúsítvány, amelyben megbízunk. Előfordulhat, hogy
több ilyen is van, több tanúsítványban is megbízunk, s ezáltal az általuk aláírtakban, és az azok által aláírtban, és
így tovább. Ez az utolsó tanúsítvány egy tanúsítvány-kiszolgálóé (Certificate Authority, pontosabb fordításban hitelesítő
hatóság), a tanúsítvány elnevezése pedig gyökértanúsítvány (root certificate).

Amikor a tanúsítványokat használjuk, akkor az adott kiszolgáló - vagy épp egy adott személy - publikus kulcsával
dolgozunk.

A Interneten számos olyan szerver van, amelyik egyáltalán nem használ aláírt tanúsítványokat, pontosabban csak
önaláírtat használ. Ezzel a legnagyobb probléma, hogy általában rövid ideig, például egy évig érvényesek, és nem lehet
ellenőrizni eredetüket. Ha pedig nem lehet ellenőrizni, könnyen megtehető, hogy egy harmadik személy beékelődik a
titkosított kapcsolat két végpontja közé, a szervernek, ami a tanúsítványt és a privát kulcsot birtokolja ez nem tűnik
fel, azonban a kliens számára feltűnő, ha ellenőrzi a tanúsítványt. Sajnos az~emberek erre általában lustaságból vagy
tudatlanságból nem képesek, ezért könnyen vissza lehet élni vele. Hogyan dolgozik a beékelődött személy? Létrehoz az
eredeti tanúsítványhoz hasonló saját tanúsítványt, és eléri, hogy ne az eredeti szerverhez csatlakozzanak, hanem őhozzá,
majd pedig az eredeti kiszolgálóhoz csatlakozik, teljesen elrejti, hogy tevékenykedik. Tipikusan így lehet jelszavakhoz
és más személyes adatokhoz hozzájutni, a támadás angol neve: man-in-the-middle attack.

Saját tanúsítvány-kiszolgálót (hatóságot) is felhasználhatunk, tanúsítványok aláírására lehetőségünk van azonban már
más, általánosan elfogadott hatóságok esetén is, természetesen ebben az esetben ők írják alá, különben nekünk kell. Az
egyik legismertebb CA a~VeriSign, azonban náluk is pénzbe kerül az aláírás megszerzése. Van azonban egy hasonló,
ingyenes lehetőség is, a \texttt{https://www.cacert.org/index.php} oldalon.

\section{Tanúsítványok készítése}
Most, hogy már tudjuk, hogyan működnek a tanúsítványok, tekintsük meg a gyakorlati felhasználást is. Ehhez az OpenSSL
csomag telepítésére van szükségünk. Hacsak nem üzemeltetünk saját tanúsítvány-kiszolgálót, további beállítást nem
igényel a rendszerünk. Ellenkező esetben a következő részben ismertetett beállításokra szükségünk van.

\subsection{openssl.cnf}
Az OpenSSL beállításfájlja az \texttt{openssl.cnf}, mely általában a \texttt{/etc/ssl} (Gentoo-n) vagy a
\texttt{/etc/openssl} könyvtárban található. Mi most nem
ezekben a könyvtárakban tároljuk, bár itt kellene, hanem a \texttt{/root/panthernet.ca} könyvtárban. Ugyanaz a fájl több
különböző CA-ra is vonatkozhat. A \texttt{[ca]} szakaszban csak azt adjuk meg, hogy melyik az~alapértelmezett CA. Ezután
minden egyes CA-t külön elnevezhetünk, és külön szakaszban definiálhatjuk a beállításokat. A példában csak egyetlen
beállítás szerepel, a többi hasonlóan működik. Csak a \texttt{dir} beállítást szükséges megváltoztatni, ha többet
használunk, viszont mindegyik szabadon konfigurálható.

\begin{Verbatim}[frame=single,label=CA beállítások]
[ ca ]
default_ca      = CA_default

[ CA_default ]

dir             = /root/panthernet.ca   # Where everything is kept
certs           = $dir/certs            # Where the issued certs are kept
crl_dir         = $dir/crl              # Where the issued crl are kept
database        = $dir/ca.db.index      # database index file.
#unique_subject = no                    # Set to 'no' to allow creation of
                                        # several ctificates with
                                        # same subject.
new_certs_dir   = $dir/newcerts         # default place for new certs.

certificate     = $dir/ca/cacert.pem    # The CA certificate
serial          = $dir/ca.db.serial     # The current serial number
#crlnumber      = $dir/crlnumber        # the current crl number
                                        # must be commented out
                                        # to leave a V1 CRL
crl             = $dir/crl.pem          # The current CRL
private_key     = $dir/ca/private/cakey.pem #The private key
RANDFILE        = $dir/ca.db.rand       # private random number file

x509_extensions = usr_cert              # The extentions to add to the cert

# Comment out the following two lines for the "traditional"
# (and highly broken) format.
name_opt        = ca_default            # Subject Name options
cert_opt        = ca_default            # Certificate field options

default_days    = 365                   # how long to certify for
default_crl_days= 30                    # how long before next CRL
default_md      = md5                   # which md to use.
preserve        = no                    # keep passed DN ordering

policy          = policy_match
\end{Verbatim}


\begin{Verbatim}[frame=single]
[ policy_match ]
countryName             = match
stateOrProvinceName     = optional
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = supplied
\end{Verbatim}


Tehát a  második lista a CA beállításait tartalmazza, a harmadik pedig azt, hogy a CA mikor tud aláírni egy
tanúsítványt: minek kell egyeznie (\texttt{match}), mi az, ami nem kötelező \texttt{optional}, és mi az, ami kötelező,
de bármi lehet (\texttt{supplied}), azaz más értéket is felvehet, mint a CA tanúsítványában szereplő érték.

Megadható az is, hogy alapértelmezetten mivel legyen kitöltve a tanúsítvány, valamint hogy milyen kérdések
szerepeljenek (lehetne magyarul is!), csakúgy, mint az alapértelmezett kulcshossz is. Ezek a részletek:

\begin{Verbatim}[frame=single]
[ req ]
default_bits            = 1024
distinguished_name      = req_distinguished_name
\end{Verbatim}


\begin{Verbatim}[frame=single,label=alapértelmezett értékek és feliratok]
[ req_distinguished_name ]
countryName                     = Country Name (2 letter code)
countryName_default             = HU
countryName_min                 = 2
countryName_max                 = 2

stateOrProvinceName             = State or Province Name (full name)
stateOrProvinceName_default     = .

localityName                    = Locality Name (eg, city)
localityMame_default            = Budapest

0.organizationName              = Organization Name (eg, company)
0.organizationName_default      = PantherHome

organizationalUnitName          = Organizational Unit Name (eg, section)

commonName                      = Common Name (eg, YOUR name)
commonName_max                  = 64

emailAddress                    = Email Address
emailAddress_max                = 64
\end{Verbatim}




\subsection{Parancsok, parancsfájlok}

Általában több tanúsítványt is alá kell írni, vagy csak létrehozni, ha egy külső hatóság írja alá nekünk. Ezért érdemes
egy parancsfájlt írni ezekre a műveletekre.

Az első ismertetett kód mégsem ilyen, hanem a CA tanúsítványának létrehozásának módja, hiszen enélkül nem tudunk aláírni
semmilyen más tanúsítványt sem:

\begin{Verbatim}[frame=single]
openssl req -config /root/panthernet.ca/openssl.cnf \
    -new -x509 -keyout /root/panthernet.ca/ca/private/cakey.pem \
    -out /root/panthernet.ca/ca/cacert.pem  -days 3650
\end{Verbatim}

\noindent A következő szkript hoz létre egy ``kérést'' (request) aláírásra (.csr: certificate
sign request, tanúsítvány aláírási kérelem) és a hozzá tartozó  privát kulcsot (.key fájl). Semelyik szkript sem igényel
teljes nevet, kiterjesztéseket automatikusan hozzáilleszti.

\begin{Verbatim}[frame=single,label=careq]
#!/bin/bash
if [[ $# != 1 ]]; then exit 4; fi
echo generating $1
openssl req -config /root/panthernet.ca/openssl.cnf  -nodes \
    -newkey rsa:2048  -keyout $1.key -out $1.csr
echo changing permissions on $1.key
chmod 400 $1.key
\end{Verbatim}

\noindent Fontos, hogy a létrehozott privát kulcs fájlját (.key állomány) csak a tulajdonos tudja olvasni, sőt, még neki
sem kell írnia, ezért az utolsó sorban ennek megfelelően módosítottuk a jogokat.

A szkript által generált kérelmet (csr fájl) elküldjük a tanúsítvány-kiszolgálónak, amely aláírja, például saját
rendszeren a következő szkripttel. A létrehozott, aláírt tanúsítvány a~.crt kiterjesztésű
fájlba kerül.

\begin{Verbatim}[frame=single,label=casign]
#!/bin/bash
if [[ $# != 1 ]]; then exit 4; fi
echo signing $1
openssl ca -config /root/panthernet.ca/openssl.cnf  -policy policy_match \
    -out $1.crt -infiles $1.csr}
\end{Verbatim}

\noindent Nézzük meg, hogy hogyan is fog ez működni, azaz tekintsünk meg egy példát egy aláírásra:

\begin{Verbatim}[frame=single]
zeratul panthernet.certs # casign ldaps.panthernet
Using configuration from /root/panthernet.ca/openssl.cnf
Enter pass phrase for /root/panthernet.ca/ca/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 1 (0x1)
        Validity
            Not Before: Oct 15 10:36:30 2005 GMT
            Not After : Oct 15 10:36:30 2006 GMT
        Subject:
            countryName               = HU
            organizationName          = PantherHome
            commonName                = ldaps.panthernet
            emailAddress              = postmaster@panthernet}

\end{Verbatim}

\noindent Az így kapott tanúsítványt (crt), valamint a privát kulcsot be kell másolni az adott szerver által igényelt
helyre, és a szervert futtató felhasználó tulajdonába kell adni.




\section{Biztonsági megfontolások}
Azt már láttuk, hogy mi a célja a tanúsítványok rendszerének, azonban ha használjuk is őket, akkor a következőkre kell
ügyelnünk.

A legfontosabb az, hogy a privát kulcsot soha ne olvashassa más (az a jó, ha a tulajdonos is csak olvashatja). Érdemes a
kulcsot és a tanúsítványt elmenteni, hogy egy esetleges véletlen törléstől védve legyen, az ördög nem alszik, rosszul
kiadott parancsok következménye lehet ez, főleg, ha nem normál felhasználóként, hanem rootként dolgozunk. Az elmentett
kulcspárra (és tanúsítványra) ugyanaz vonatkozik, mint a CA-ra.

Ha saját hitelesítő hatóságunk (CA) van, akkor erre további szabályok vonatkoznak, amiket kötelező (lenne) betartani. A
privát kulccsal vissza lehet élni, ezért azt mindenképpen védeni kell. Minimális védelemnek tekinthető a kulcs jelszavas
védelme és a géptől független tárolása. Ha alá kell írni egy tanúsítványt, akkor az aláírás idejére be kell csatolni a
kulcsot tartalmazó fájlrendszert, ami ma nagy valószínűséggel pendrive vagy CD. Az~aláírás végeztével el kell távolítani
az eszközt. Az még jobb, ha már maga a pendrive fájlrendszere is jelszóval védett, habár ez utóbbi esetleg már inkább
csak extra védelmet nyújt. Ami lényeges, hogy az eltávolított eszközt biztonságos helyen, például páncélszekrényben kell
őrizni, amelyhez nem férhet hozzá akárki, és mindig lehet tudni, ki nyúlt bele...