\documentclass[a4,12pt]{seminar}
\usepackage{polski}
%\usepackage[OT4]{polski}
\usepackage[T1]{fontenc}      % polish fonts
\usepackage[latin2]{inputenc}
\usepackage[dvips]{pstcol} % To use the standard `color' package with Seminar
\usepackage{semcolor}
\usepackage{semlayer}
\usepackage{pstricks}
%\usepackage{array}
\usepackage{multirow}

\ptsize{17}
%\renewcommand\slidefootfont{\ptsize{10}}
%\renewcommand\slideleftmargin{-5mm}
\def\FileAuthor{{\textcolor{gray}{\textit{Piotr Kucharski}}}}
\def\FileTitle{\textcolor{gray}{Infrastruktura Klucza Publicznego}}
\def\FileSubject{\textcolor{gray}{\textit {Systemy zabezpieczeń i kryptografia. Warszawa, 2 grudnia 2006}}}
%\def\FileTitle{\textcolor{gray}{Digital Signatures and Certificate Authorities}}
%\def\FileSubject{\textcolor{gray}{\textit {NATO ANW: 10th CEENet Network Technology Workshop, June 25-29, 2005, Ohrid, Macedonia}}}

\usepackage{tabularx}
\input{macrosPresentation.tex}
% wytrych do tabelek...
\newcommand{\PreserveBackslash}[1]{\let\temp=\\#1\let\\=\temp}
\let\PBS=\PreserveBackslash

\def\BOX#1{\vbox to 1.7cm{\hsize4.8cm\parindent0pt
\leftskip 2mm plus 1fill \rightskip 2mm plus 1fill
\vss#1\vss}}
%\def\Bx#1{\BOX{5cm}{2cm}{#1}}

% For overlays, to force to print all preceding ones
\makeatletter
\def\pst@initoverlay#1{%
\pst@Verb{%
/BeginOL {dup (all) eq exch TheOL le or {IfVisible not {Visible
/IfVisible true def} if} {IfVisible {Invisible /IfVisible false
def} if} ifelse} def \tx@InitOL /TheOL (#1) def}} \makeatother

\hyphenpenalty=10000
\parindent=0pt


\begin{document}
\Huge
\sffamily 
\pagestyle{fancy}
%%% Title %%%%
\begin{slide}
\begin{center}
\Middle{Infrastruktura klucza publicznego}
%\textit{otherwise known as}\\
%\textbf{Public Key Infrastructure}\\
\vspace{1cm}
\textit{\Large Piotr Kucharski}
\end{center}
\end{slide}
%%%%%%%%%%%%%%%%%%%%%%%%%%% Overview %%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{slide}
\slideheading{Infrastruktura klucza publicznego}
\begin{itemize}
\item Wstęp do kryptografii
\item Podstawy podpisu elektronicznego
\item Infrastruktura klucza publicznego
\end{itemize}
\end{slide}

\begin{slide}
\slideheading{Wprowadzenie do kryptografii}
\begin{itemize}
\item Podstawowe terminy
\item Podstawowe algorytmy kryptograficzne
%\item Podpis elektroniczny
\item Kryptograficzne funkcje skrótu
\item Inne ważne rzeczy
%\item Kryptograficzne generatory liczb losowych
%\item Siła algorytmów kryptograficznych
\item Kryptoanaliza i ataki na systemy kryptograficzne
\end{itemize}
\end{slide}
% Part I. Introduction to Cryptography

\begin{slide}
\slideheading{Kryptografia: podstawowe terminy}
\begin{description}
\item[kryptografia] sztuka lub nauka o matematycznych technikach związanych z takimi aspektami bezpieczeństwa, jak poufność, integralność danych, uwierzytelnianie, niezaprzeczalność
%\item[cryptography] art or science of mathematical techniques related to such aspects of data security as confidentiality, data integrity, authentication, non-repudiation
\item[kryptoanaliza] badanie matematycznych metod, które są używane w próbach złamania technik kryptograficznych
%\item[cryptanalysis] study of mathematical methods which are used in attempting to defeat cryptographic techniques
\item[kryptologia] kryptografia i kryptoanaliza
%\item[cryptology] study of cryptography and cryptonalysis
\end{description}
\end{slide}

\begin{slide}
\slideheading{Kryptografia: podstawowe terminy}
%\renewcommand\baselinestretch{0.5}
%\ptsize{17}
\center
  \psset{arrowscale=2 2}
  \begin{psmatrix}[rowsep=0.5,colsep=0.5]
    & \psframebox[fillstyle=solid,fillcolor=yellow]{\parbox{2cm}{\center tekst jawny}} & \\
    \psovalbox{szyfrowanie} & & \psovalbox{deszyfrowanie} \\
    & \psframebox[fillstyle=crosshatch,hatchcolor=yellow]{\parbox{2cm}{\center tekst zaszyf- rowany}} & \\
    \psset{linestyle=dashed} \psframebox{klucz szyfrujący $K_S$}
    && \psset{linestyle=dashed} \psframebox{klucz deszyfrujący $K_D$} \\
    \ncline[offsetA=-0.5,nodesepA=0.1]{->}{1,2}{2,1}
    \ncline[offsetB=-0.5,nodesepB=0.1]{->}{2,1}{3,2}
    \ncline[offsetA=-0.5,nodesepA=0.1]{->}{3,2}{2,3}
    \ncline[offsetB=-0.5,nodesepB=0.1]{->}{2,3}{1,2}
    \ncline{->}{4,1}{2,1}
    \ncline{->}{4,3}{2,3}
  \end{psmatrix}

% \vskip 2mm
% \begin{tabular}{c@{ }c@{ }c@{ }c@{ }c}
% plaintext & $\longrightarrow$ encryption $\longrightarrow$ & ciphertext 
% & $\longrightarrow$ decryption $\longrightarrow$ & plaintext \\
% & $\uparrow$ && $\uparrow$ & \\
% & encryption key $K_E$ && decryption key $K_D$&
% \end{tabular}
% %\vskip 5mm
\end{slide}

\begin{slide}
\slideheading{Kryptografia: szyfry}

\vskip -5mm
Metoda szyfrowania i deszyfrowania nazywana jest \textbf{szyfrem}. Niektóre
metody kryptograficzny polegają na tajności algorytmu szyfrującego. Naiwnie.
\vskip 1mm
Holenderski kryptograf Auguste Kerckhoff von Nieuwenhof w 1883 sformułował:
\begin{description}
\item[Zasada Kerckhoffa]
\textit{Bezpieczeństwo systemu kryptograficznego nie może być oparte na utrzymywaniu
tajności algorytmu, tylko na utrzymywaniu tajności klucza.}
\end{description}
\end{slide}

\begin{slide}
\slideheading{Kryptografia: algorytmy}
Dwie klasy szyfrów:
\begin{description}
\item[symetryczne] (z tajnym kluczem), ten sam klucz jest używany zarówno do szyfrowania, jak i do deszyfrowania, z tego powodu klucz \textbf{musi} być utrzymany w sekrecie; te algorytmy możemy podzielić na dwie grupy:
szyfry strumieniowe (bit po bicie) i blokowe (64 bity lub więcej na blok).
\item[asymetryczne] (z kluczem publicznym), jeden klucz jest używany do szyfrowania, a inny do deszyfrowania i \textit{vice-versa}; dzięki temu jeden klucz może być publicznie dostępny, a dla zapewnienia bezpieczeństwa drugi klucz (prywatny) utrzymywany w sekrecie
\end{description}
\end{slide}

\begin{slide}
\slideheading{Kryptografia: algorytmy symetryczne}
\begin{description}
\item[The One-Time Pad] (jednorazowy) udowodniony jako nie do złamania; Vernam w 1917 wymyślił szyfr: tyle samo bitów tekstu jawnego i tyle samo losowego ,,klucza''. Nie można go użyć drugi raz. W 1949 Shannon udowodnił skuteczność.
\item[DES] wymyślony w latach 70, NIST zrobił z niego standard, bloki 64-bitowe, klucze 56-bitowe (bezpieczne, ale podatne na przeszukanie przestrzeni wszystkich kluczy), wolny; jego odmiana 3DES poprawia problem krótkiego klucza, ale jest 3 razy wolniejsza...
\end{description}
\end{slide}

\begin{slide}
 \begin{description}
\item[AES] National Institute of Standards and Technology 
zorganizował konkurs na nowy \textbf{A}dvanced \textbf{E}ncryption \textbf{S}tandard. 
Wszyscy finaliści używali bloków 128-bitowych i akceptowali klucze o długości
128, 192 i 256 bitów.
 \item[Rijndael] Zwycięzca; autorzy: Joan Daemen i Vincent Rijmen; łatwo go zaimplementować sprzętowo, ma krótki czas zestawienia klucza, zużywa mało pamięci (najlepszy atak w 7 rundach na 10... {\footnotesize nie tak źle, ciągle wymaga $2^{120}$ kroków i $2^{100}$ bajtów pamięci})
\end{description}
\end{slide}

\begin{slide}
 \begin{description}
 \item[Serpent] autorzy: Anderson, Biham, i Knudsen; nowatorski projekt, może zostać zaimplementowany w logice bramek wektorowych, najbezpieczniejszy, ale wolny (najlepszy atak w 10 z 32 rund)
 \item[Twofish] autorzy: Schneier et al., Counterpane Security; tak pomiędzy Rijndaelem i Serpentem, wygląda całkiem nieźle (najlepszy atak w 8 z 16 rund)
 \item[RC6] autorzy: Rivest, Robshaw i Yin, RSA Laboratories; ewolucja RC5 (najlepszy atak w 17 z 20 rund)
 \item[MARS] autorzy: Zunic et al., IBM; zależy od zestawu instrukcji 32-bitowych procesorów, problemy na innych architekturach, wykonuje wiele operacji, stąd bardzo kosztowny
 \end{description}
\end{slide}

\begin{slide}
\begin{description}
\item[inne] Blowfish, CAST-128 (RFC2144), IDEA (uważany jest za bardzo bezpieczny, jest dobrze poznany, ale opatentowany i płatny w celach komercyjnych), Rabbit (zupełnie nowy), RC4 (podobno źródło wypłynęło, nieznane bezpieczeństwo, szybki, wariant OTP)
\item[przed 1970] Fish (niemieckie dowódzwo armii 2WŚ, doprowadził do powstania pierwszego komputera: Colossus), Enigma (rotory, polscy kryptoanalitycy, Bletchley Park (dziś nie jest bezpieczny)), szyfr Vernama, szyfry podstawieniowe (w tym przesuwające: Cezar, rot13), inne starożytne
\item[ROT13] stosowany m.in. w Usenecie (,,fgbfbjnal j Hfrarpvr'')
\end{description}
\end{slide}

% here maybe slide about block cipher modes

\begin{slide}
\slideheading{Kryptografia: algorytmy asymetryczne}
W późnych latach 70 zaobserwowano, że w oparciu o bardzo, bardzo trudny
problem, którego rozwiązanie zajęłoby tysiące lat, mógłby powstać
system kryptograficzny
z dwoma kluczami, publicznym (do szyfrowania) i prywatnym (do deszyfrowania).
\vskip1mm
Wymiana kluczy. Zanotowano, że kryptograficzny system z kluczem publicznym
mógłby zostać użyty do utworzenia tajnego klucza używanego w szyfrowaniu
symetrycznym dużej ilości danych.
Whitfield Diffie i Martin Hellman skonstruowali protokół wymiany klucza,
który na zawsze zmienił oblicze świata kryptografii.
\vskip1mm
Niedługo później Ron Rivest, Adi Shamir i Leonard Adleman utworzyli
pierwszy prawdziwy system kryptograficzny z kluczem publicznym.
\end{slide}

\begin{slide}
W ogólności system kryptograficzny z kluczem publicznym jest zbudowany
z trudnego problemu:
\begin{enumerate}
\item weź trudny problem (NP-zupełny), dla którego możesz znaleźć szczególną
postać rozwiązywalną w krótkim czasie {\footnotesize(trapdoor function with high computational complexity)}
\item przekształć jawny tekst do takiej łatwej postaci trudnego problemu
\item użyj klucza publicznego do przekształcenia łatwej postaci z powrotem na trudny problem
\item prześlij po niezabezpieczonym kanale
\item użyj klucza prywatnego do przekształcenia trudnego problemu w łatwą postać
\item rozwiąż łatwą postać w celu uzyskania jawnego tekstu
\end{enumerate}
\end{slide}

\begin{slide}
\begin{description}
\item[RSA] autorzy: \textbf{R}ivest, \textbf{S}hamir i \textbf{A}dleman; 
najczęściej używany algorytm klucza publicznego; rozkładanie na czynniki iloczynu dwóch dużych (gigantycznych!) liczb pierwszych;\\
{\ptsize{14}Interaktywny tutorial o RSA \url{http://www.youdzone.com/rsa.html}}
%\item[Rabin] pochodna RSA
\item[ElGamal] podobny do DH, wolniejszy, ale bez obciążeń patentowych
\item[Diffie-Hellman] protokół wymiany klucza z 1976(!);  pozwala dwóm stronom bez
uprzedniego wspólnego tajnego klucza stworzyć taki; mogą potem użyć go jako
klucza w kryptografii symetrycznej (szybkie szyfry blokowe) lub jako podstawę do wymiany klucza; problem logarytmów dyskretnych.
% discrete logarithm problem.
\end{description}
\end{slide}

\begin{slide}
\begin{center}
\textbf{Schemat protokołu Diffie-Hellman}
\end{center}
Mamy liczbę pierwszą $p = 23$ i generator $g = 3$
{\tiny(matematycznie starannie dobrane)}
\begin{description}
\item[Alicja] wybiera losowo liczbę $a = 6$\\
oblicza $A=g^a \!\mod p = 3^6 \!\mod 23 = 16$\\
i wysyła $A=16$ do Bartka
\item[Bartek] wybiera losowo liczbę $b=15$\\
oblicza $B=g^b \!\mod p = 3^{15}\!\mod 23 = 12$\\
i wysyła $B=12$ do Alicji
\item[wspólny sekret] $s=g^{a\cdot b}\!\mod p$ możemy obliczyć tak:
 \begin{itemize}
 \item Alicja zna $a$ i $B$ i oblicza $s=B^a \!\mod p = 12^6 \!\mod 23 =9$
 \item Bartek zna $b$ i $A$ i oblicza $s=A^b \!\mod p = 16^{15} \!\mod 23 =9$
 \end{itemize}
\end{description}
\end{slide}


\begin{slide}
\slideheading{Kryptograficzne funkcje skrótu}
,,Kompresują'' wiadomość do stałego rozmiaru \textbf{wartości skrótu} (hash).
Tak zaprojektowane, żeby różne wiadomości dawały różne wartości skrótu.
(Nie do końca to możliwe.)
Ale przynajmniej niewielkie zmiany wiadomości dają zupełnie inny wartości
skrótu i jest trudno znaleźć dwie takie same wiadomości, które by dawały
taką samą wartość skrótu (\textit{kolizja}).
\begin{description}
\item [MD5] rozwijane przez RSA Labs, opublikowane w RFC1321, skraca do wartości 128 bitowych, np.:\\
MD5 (irc2.11.1p1.tgz) = c5a2b3097a5fbeb91b39412730b02ab5
%\\MD5 collisions {\ptsize{14}\url{http://www.cits.rub.de/MD5Collisions/}}
\item [RIPEMD-160] miał zastąpić MD5, daje skróty 160 bitowe
\item [SHA-1] opublikowany przez rząd USA (FIPS PUB 180-1), 160-bit, ma dłuższe (256, 384, 512) odmiany
\end{description}
\end{slide}

\begin{slide}
\slideheading{Inne ważne rzeczy}
\begin{description}
\item[MAC] (message authentication codes) kody autoryzujące wiadomość; oparte na skrótach (HMAC-SHA-1) lub blokowych szyfrach symetrycznych (DES-CBC-MAC), używane do weryfikacji integralności wiadomości
\item[dzielony tajny klucz] rozdaje się klucz $N$ ludziom (lub więcej) i gwarantuje, że mniej niż $N$ osób nie będzie w stanie dostać całego klucza
\end{description}
\end{slide}

\begin{slide}
\begin{description}
\item[generatory liczb losowych] bardzo często używane w kryptografii (jak klucze); potrzebujemy przynajmniej 128 bitów entropii
 \begin{description}
 \item[prawdziwe] fizyczne, sprzętowy (przepuszczanie półprzewodników) szum, najmniej znaczący bit wejścia audio, czas między przerwami a klawiszami naciskanymi przez użytkownika
 \item[pseudo] najlepiej wziąć trochę fizycznego (nawet jeśli malutko) i zamieszać; ANSI X9.17; FIPS-186 (DSS)
 \end{description}
\end{description}
\center \textbf{\textit{GLL musi być bardzo dobry... albo system krypto będzie popsuty.}}
\end{slide}

\begin{slide}
\slideheading{Kryptoanaliza i ataki na systemy kryptograficzne}
\begin{description}
\item[brute-force] aka przeszukiwanie całej przestrzeni kluczy
\item[man in the middle] wejdź między Alicję i Bartka, rób za pośrednika
\item[kryptoanaliza] sztuka odszyfrowywania zaszyfrowanego
%communications without knowing the proper keys
\begin{description}
\item[atak na wiadomość zaszyfrowaną] nic nie wiemy
\item[atak ze znanym tekstem jawnym] odszyfruj resztę lub zdobądź klucz
\item[atak z wybranym tekstem jawnym] w celu zdobycia klucza
%\item[problemy w kryptosystemie] oczywiste
\item[przetwarzania kwantowe] rozwiąż \textit{WSZYSTKIE} równania w jednej chwili
\end{description}
\item[czynnik ludzki] oszukiwanie
\end{description}
\end{slide}

%
%The Dutch Cryptographer Auguste Kerckhoff von Nieuwenhof formulated this in 1883: 
%Kerckhoff's Principle: 
%"The security of a cryptosystem shall not be based on keeping the algorithm 
%secret but solely on keeping the key secret."

% o key pairs
%
%http://www.ssh.fi/support/cryptography/introduction/
\begin{slide}
\slideheading{Podstawy podpisu elektronicznego: wstęp}
\begin{itemize}
\item Podpis tradycyjny
\item Podpis elektroniczny
\begin{itemize}
\item koncept
\item tworzenie i weryfikacja
\item problemy
\item przykład
\end{itemize}
%\item Fields of Use
%\item Methods and Purpose
\end{itemize}
\end{slide}
% Part II. Digital Signatures basics
\begin{slide}
\slideheading{Podpis tradycyjny}
\hskip-2mm Podpis nie jest treścią transakcji, raczej jej reprezentacją.\\
Podpis tradycyjny służy następującym celom:
\begin{description}
\item [dowodowy] odręczny podpis jest cechą podpisującego, więc łączy
dokument z podpisującym
\item [ceremonialny] kładzie nacisk na istotę prawną, co pozwala zapobiegać
,,nierozważnym zobowiązaniom''
\item [aprobujący] niektóre akty prawne wymagają formy pisemnej pod rygorem nieważności
\item [skuteczność i logistyka] daje poczucie jasności i ostateczności (negocjacje)
i jest łatwy do zrobienia!
\end{description}
\textit{Zapewnia strony o ważności i wymagalności transakcji.}
\end{slide}

\begin{slide}
\slideheading{Podpis elektroniczny}
Zalety dokumentów elektronicznych (łatwość duplikacji, szybki transport,
przetwarzania przez komputer) są równocześnie ich wadami. Potrzeby:
%Potrzebują dodatkowych rzeczy:
%\overlay{0}{
\begin{description}
\item[uwierzytelnienie podpisującego] podpis musi wskazywać, kto podpisał które
dane i powinien być trudny do podrobienia
\item[uwierzytelnienie dokumentu] podpis musi wskazywać, co dokładnie zostało
podpisane, bez możliwość podrobienia lub zmiany dokumentu lub podpisu
\item[wydajność] podpis, jego tworzenie i weryfikacja powinny zapewniać
możliwie największe zaufanie dla podpisującego i autentyczności dokumentu
przy najmniejszym możliwym koszcie
\end{description}
%}\overlay{1}{
\textit{To jest zadanie usługi niezaprzeczalności w PKI.}
%}
\end{slide}

\begin{slide}
Podpis elektroniczny korzysta z systemów kryptografii z kluczem publicznym,
które używają dwóch matematycznie związanych ze sobą kluczy:
\begin{description}
\item[klucz prywatny] znany tylko podpisującemu, \\
używany do tworzenia podpisu
\item[klucz publiczny] znany powszechnie, \\
używany do weryfikowania podpisu
\end{description}
Klucze są związane, ale jest praktycznie niemożliwe obliczeniowo wymyślenie klucza prywatnego na podstawie publicznego.
\end{slide}

\begin{slide}
Ze względu na wydajność nie jest podpisywana cała wiadomość (choć krótkie powinny być), a tylko jej skrót
\begin{description}
\item[skrót wiadomości, hash] wynik funkcji skrótu (hashującej, mieszającej) zaaplikowanej na całej wiadomości
\item[funkcja skrótu] jednokierunkowy mechanizm produkujący unikatowy, stałej wielkości, ,,odcisk palca'' danych wejściowych
\end{description}
\end{slide}
 
\begin{slide}
\slideheading{Tworzenie podpisu elektronicznego}
\renewcommand\baselinestretch{0.5}
\ptsize{17}
\center
%\psframebox[linearc=0.5,cornersize=absolute]{%
  \psset{arrowscale=2 2}
  \begin{psmatrix}[rowsep=0.5,colsep=0.5]
    \psframebox[fillstyle=solid,fillcolor=yellow]{\parbox{3cm}{\center Wiadomość\vskip1mm}} \\
    \psovalbox{funkcja skrótu\vphantom{g}} \\
    \psframebox[fillstyle=solid]{skrót wiadomości} &
    \psframebox[fillstyle=solid,fillcolor=yellow]{\parbox{3cm}{\center Wiadomość\vskip1mm\vrule width 3cm depth 0pt height 0.5pt\vskip1mm podpis}} & \pscirclebox{świat} \\
    \psovalbox{funkcja podpisująca} \\
    \psset{linestyle=dashed}
    \psframebox{klucz prywatny podpisującego}  \\
%    % Links
    \ncline{->}{1,1}{2,1}
    \ncline{->}{1,1}{1,2}
    \ncline{->}{2,1}{3,1}
    \ncline{->}{3,1}{4,1}
    \ncline{->}{3,2}{3,3}
    \ncline{->}{5,1}{4,1}
    \ncbar[angleB=90,armB=0,nodesepB=-1.5,offsetB=-1]{->}{1,1}{3,2}
    \ncbar[angleB=-90,armB=0,nodesepB=-1.5,offsetB=1]{->}{4,1}{3,2}
    \end{psmatrix}%
%}

\small{Uwaga: funkcja podpisująca to de facto szyfrowanie skrótu wiadomości}
\end{slide}

\begin{slide}
\slideheading{Weryfikacja podpisu elektronicznego}
\renewcommand\baselinestretch{0.5}
\ptsize{17}
\center
%\psframebox[linearc=0.5,cornersize=absolute]{%
  \psset{arrowscale=2 2}
  \begin{psmatrix}[rowsep=0.5,colsep=0.5]
    & & \psovalbox{funkcja skrótu\vphantom{g}} \\
    & & \psframebox[fillstyle=solid]{skrót wiadomości} \\
    \pscirclebox{świat} &
    \psframebox[fillstyle=solid,fillcolor=yellow]{\parbox{3cm}{\center Wiadomość\vskip1mm\vrule width 3cm depth 0pt height 0.5pt\vskip1mm podpis}} &
    \psdiabox{zgadza się?} \\
    & & \psframebox{oryginalny skrót} \\
    & & \psovalbox{funkcja weryfikująca} \\
    & &
    \psset{linestyle=dashed}
    \psframebox{klucz publiczny podpisującego}  \\
%    % Links
    \ncline{->}{3,1}{3,2}
    \ncline{->}{1,3}{2,3}
    \ncline{->}{2,3}{3,3}
    \ncline{->}{4,3}{3,3}
    \ncline{->}{5,3}{4,3}%>{must be successful}
    \ncline{->}{6,3}{5,3}
    \ncbar[offsetA=0,angleA=90,armB=0,offsetB=-2.75,nodesepB=-0.5]{->}{3,2}{1,3}
    \ncbar[offsetA=0,angleA=-90,armB=0,offsetB=2.30,nodesepB=-0.5]{->}{3,2}{5,3}
%    \ncbar[angleB=0,angleB=0,armA=0,nodesepB=0,offsetB=0]{->}{3,2}{1,3}
%    \ncbar[angleB=0,angleB=0,armA=0,nodesepB=0,offsetB=0]{->}{3,2}{4,3}
    %\ncbar[angleB=90,armB=0,nodesepB=0.25]{->}{1,1}{4,2}
    \end{psmatrix}%
%}

\small{Uwaga: funkcja weryfikująca to de facto deszyfrowanie podpisu}
\end{slide}

\begin{slide}
\slideheading{Problemy z podpisem elektronicznym}
\begin{description}
\item [funkcja skrótu] polegamy na niej, a z definicji istnieje możliwość kolizji\ldots
może być \textit{więcej niż jedna} wiadomość, która daje tę samą wartość skrótu
$\Rightarrow$ podrobienie \\
kolizje MD5 {\ptsize{14}\url{http://www.cits.rub.de/MD5Collisions/}}
\item [wiadomość] podpisujący musi mieć pełną świadomość, co podpisuje
\item [klucze] skąd wiadomo, czyj jest dany klucz? $\Rightarrow$ Infrastruktura Klucza Publicznego
\item [PKI] czy możemy jej wierzyć?
\end{description}
\end{slide}

\begin{slide}
\slideheading{Przykład podpisu elektronicznego w PGP}
\renewcommand\baselinestretch{0.8}
\ptsize{12}
\begin{verbatim}
% cat test.txt
Cześć, to przykładowy plik na zajęcia z kryptografii
Mój PIN do komórki: 981cff74a11a7ffacab4ce26656b3f55

% pgp -sba -u chopin@sgh.waw.pl test.txt
Pretty Good Privacy(tm) 2.6.3ia - Public-key encryption for the masses.
(c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-03-04
International version - not for use in the USA. Does not use RSAREF.

A secret key is required to make a signature.
You need a pass phrase to unlock your RSA secret key.
Key for user ID: Piotr Kucharski <chopin@sgh.waw.pl>
1024-bit key, key ID D818A489, created 1995/10/31

Enter pass phrase: s3kr3t... Pass phrase is good.  Just a moment...
Transport armor file: test.txt.asc

% cat test.txt.asc
-----BEGIN PGP MESSAGE-----
Version: 2.6.3ia

iQCVAwUAQr899kABjqnYGKSJAQFabgP9GsOfNMs25xNTrMPcdNEodZfmtpzTSJg5
3vEyR20OsVD9txVkL1qchhIRznssgYNiEtOYQwVrt1XRedgEnkAUyO8iRjPn4DQm
ETP17NReV3bcwHZI5SFdNsZiLNe7YIujycIbywuP4C/a/MrtEAdp5tLgHTBX01l/
uFVYM6fnoLw=
=IRV1
-----END PGP MESSAGE-----
\end{verbatim}
\end{slide}

\begin{slide}
\renewcommand\baselinestretch{0.8}
\ptsize{12}
{\ptsize{14}Sprawdźmy}
\begin{verbatim}
% pgp +verbose=0 test.txt.asc -o /dev/null
Good signature from user "Piotr Kucharski <chopin@sgh.waw.pl>".
Signature made 2005/06/20 23:20 GMT using 1024-bit key, key ID D818A489
\end{verbatim}
{\ptsize{14}
Teraz usuwam linijkę z PIN-em i sprawdzam jeszcze raz.}
\begin{verbatim}
% pgp +verbose=0 test.txt.asc -o /dev/null
WARNING: Bad signature, doesn't match file contents!

Bad signature from user "Piotr Kucharski <chopin@sgh.waw.pl>".
Signature made 2005/06/20 23:20 GMT using 1024-bit key, key ID D818A489
\end{verbatim}
{\ptsize{14}
Przywracam linijkę z PIN-em, ale zmieniam podpis i sprawdzam jeszcze raz.}
\begin{verbatim}
% pgp +verbose=0 test.txt.asc -o /dev/null
ERROR: Bad ASCII armor checksum

Error: Transport armor stripping failed for file test.txt.asc

For a usage summary, type:  pgp -h
For more detailed help, consult the PGP User's Guide.
\end{verbatim}
\end{slide}

% o traditional signatures
% o fields of use
% o methods and purpose
%   - integrity
%   - authenticity, verification, distribution, TTP
%   - nonrepudiability
% o details
% o problems
%
%
%"ABA Digital Signatures Tutorial"
%http://www.abanet.org/scitech/ec/isc/dsg-tutorial.html
%= http://www.commerce.state.ut.us/digsig/tutorl.htm
%digital signatures literature http://rechten.uvt.nl/simone/ds-lit.htm
\begin{slide}
\slideheading{Infrastruktura Klucza Publicznego (PKI)}
\begin{itemize}
\item model
\item oferowane usługi
\item centra certyfikujące
\item model zaufania
\item problemy
\end{itemize}
\end{slide}


% Part III. 1. Public Key Infrastructure Model}
\begin{slide}
\slideheading{PKI: model infrastruktury}
\begin{description}
\item[infrastruktura] w ogólności: jak prąd czy sieć lan
\item[potrzeby] związane z aplikacjami, bezpieczne (i raz) logowanie, przezroczystość
\item[zyski] oszczędność kosztów, swobodna wymiana informacji (wewnętrzna i zewnętrzna),
jednorodne rozwiązania (łatwość administracji), \textit{droga do możliwego osiągnięcia bezpieczeństwa}
\item[model infrastruktury] \footnotesize{na następnym slajdzie}
\end{description}
\end{slide}

\begin{slide}
\renewcommand\baselinestretch{0.7}
\ptsize{17}
\begin{tabularx}{\textwidth}{XXX}
\multicolumn{3}{c}{Infrastruktura} \\ \hline
\begin{itemize}
\item centra certyfikacyjne
\item archiwizacja kluczy
\item zarządzania \par historią kluczy
\end{itemize}
&
\begin{itemize}
\item repozytoria certyfikatów
\item odzyskiwanie kluczy
\item certyfikacja krzyżowa
\end{itemize}
&
\begin{itemize}
\item odwoływanie \par certyfikatów
\item automatyczna \par aktualizacja kluczy
\item oprogramowanie użytkownika
\end{itemize}
\\
\multicolumn{3}{c}{Usługi} \\ \hline
\begin{itemize}
\item uwierzytelnianie 
\item bezpieczny \par znacznik czasu
\item bezpieczna \par archiwizacja danych
\end{itemize}
&
\begin{itemize}
\item integralność 
\item notariat 
\item tworzenie uprawnień/polityki
\end{itemize}
&
\begin{itemize}
\item poufność
\item niezaprzeczalność
\item weryfikacja uprawnień/polityki
\end{itemize}
\end{tabularx}
\end{slide}

\begin{slide}
\slideheading{Przegląd infrastruktury PKI}
\begin{description}
\item[Centrum certyfikujące (CA)] zaufana trzecia strona, wiąże dany klucz publiczny z jakimś podmiotem przez wydawania certyfikatów podpisanych przez CA
\item[Repozytorium certyfikatów] mechanizm dostarczający certyfikaty; wydajność, skalowalność, dostępność on-line
\item[Odwoływanie certyfikatów] zmiana nazwy lub kradzież klucza prywatnego -- musi być sposób, żeby oznaczyć dany certyfikat jako nieważny; publikowane listy certyfikatów odwołanych (CRL), używanie Online Certificate Status Protocol (OCSP)
\end{description}
\end{slide}

\begin{slide}
\begin{description}
\item[Archiwizacja i odzyskiwanie kluczy] klucze (do podpisu i szyfrowania) będą gubione (ułomna ludzka pamięć lub uszkodzenie sprzętu) -- dla organizacji może być nie do zaakceptowania, żeby \textit{nie} mogli odszyfrować zaszyfrowanych danych
\item[Automatyczna aktualizacja kluczy] certyfikaty nie są wieczne -- jeśli aktualizacja będzie obowiązkiem użytkownika, to na pewno zostanie zapomniana
\end{description}
\end{slide}

\begin{slide}
\begin{description}
\item[Zarządzanie historią kluczy] nowe klucze nie będą w stanie odszyfrować starych danych zaszyfrowanych starymi kluczami (a reszyfrowanie jest praktycznie niewykonalne)
\item[Krzyżowa certyfikacja] uniwersalna (światowa) PKI to mit; różne współpracujące systemy PKI potrzebują sposobu, żeby ich użytkownicy sobie ufali
\item[Oprogramowanie klientów] cała infrastruktura (serwery) jest niczym bez klientów; to klienty ściągają certyfikaty, przetwarzają CRL-e, weryfikują procedury...
\end{description}
\end{slide}


\begin{slide}
\slideheading{Przegląd usług PKI}
\begin{description}
\item[Uwierzytelnianie] zapewnienie jednego podmiotu, że drugi podmiot jest tym, za kogo się podaje
\item[Integralność] zapewnienie, że dane nie zostały zmienione
\item[Poufność] zapewnienie, że nikt nie może odczytać danych oprócz explicite wybranych odbiorców
\end{description}
\end{slide}

\begin{slide}
\begin{description}
\item[Bezpieczny znacznik czasu] sekwencje zdarzeń nie mogą pozostawiać wątpliwości
\item[Notariat] certyfikacja poprawności danych (acz ,,poprawność'' to bardzo subiektywny termin)
\item[Niezaprzeczalność] jak podpiszesz, nie możesz twierdzić, że nie podpisałeś; nie można być na 100\% pewnym, ale to dużo pomaga
\end{description}
\end{slide}

\begin{slide}
\begin{description}
\item[Bezpieczne archiwum danych] wszystkie stare certyfikaty, listy CRL, dokumenty ze znacznikami czasu itd. muszą być zachowywane w celach dowodowych
\item[Tworzenie uprawnień/polityki] mechanizmy do tworzenia szczegółowej polityki kontroli dostępu dla osób lub grup (a w zasadzie ich certyfikatów)
\item[Weryfikacja uprawnień/polityki] mechanizmy do sprawdzania tego, co wyżej
\end{description}
\end{slide}

\begin{slide}
\slideheading{Podstawowe usługi PKI: uwierzytelnianie}
\textbf{Uwierzytelnianie} to zapewnienie jednego podmiotu, że drugi podmiot jest tym, za co się podaje. W pewien sposób.
\begin{description}
\item[Uwierzytelnienie podmiotu] bez zważania na to, co robi; to pierwszy krok przed sprawdzaniem czegokolwiek innego
\begin{itemize}
\item lokalne uwierzytelnienie: poziom podstawowy, zwykle wymaga osobistej interwencji i objawia się w sposób bezpośredni i oczywisty (przyciśnięcie kciuka, wpisanie hasła itp.)
\item zdalne uwierzytelnienie: gdy użytkownik korzysta z serwisów zdalnych, które potrzebują wiedzieć, kim ten użytkownik jest;
może bezpośrednio angażować użytkownika, ale z powodu problemów z zabezpieczaniem danych w transporcie oraz (co ważniejsze) dyskomfortem użytkownika (może nie być SSO), przetwarzany jest tylko \textit{wynik lokalnego uwierzytelnienia}
\end{itemize}
\end{description}
\end{slide}

\begin{slide}
\begin{description}
\item[Uwierzytelnienie podmiotu] można uzyskać na wiele sposobów
\begin{description}
\item[coś, co masz] smartcard czy token
\item[coś, co wiesz] hasło lub PIN
\item[coś, czym jesteś] unikatowy odcisk palca, wzór siatkówki 
\item[coś, co robisz] wzór odręcznego pisma
\end{description}
Pojedynczy czynnik jest mniej bezpieczny niż kombinacja. Świat biznesu zwykle używa dwóch czynników, np. smartcard (PIN i chip elektroniczny), securID (kod tokena i PIN).
\item[Identyfikacja źródła danych] identyfikuje podmiot jako źródło jakichś danych -- statycznie i nieodwołalnie {\footnotesize (umożliwia działanie usługi niezaprzeczalności)}
\end{description}
\end{slide}

\begin{slide}
\slideheading{Podstawowe usługi PKI: integralność}
\begin{itemize}
\item zapewnienie niezmienialności (celowej lub nie), zarówno w trakcie transportu (między \textit{tam} a \textit{tu}), jak i przechowywania (między \textit{wtedy} a \textit{teraz})
\item bity parzystości, kody CRC mogą wykryć przypadkowe błędy w pojedynczych bitach, ale nic nie poradzą na świadomych włamywaczy
\item rozwiązaniem jest podpisywanie swoim kluczem prywatnym (jeden do wielu (w zasadzie to pochodna uwierzytelniania) lub kluczem publicznym odbiorcy (jeden do jednego) --- nikt poza właścicielami klucza nie będzie mógł manipulować danymi \textit{oraz} zapewnić integralności podpisu
\end{itemize}
\end{slide}

\begin{slide}
Kody Uwierzytelniające Wiadomość (Message Authenticating Code, MAC) są zbudowane
z blokowych szyfrów symetrycznych np. DES-CBC-MAC (FIPS113) lub kryptograficznych
funkcji skrótu np. \mbox{HMAC-SHA-1} (RFC2104) -- używają kryptografii symetrycznej,
ale klucze są zwykle rozpowszechniane przy pomocy PKI.

\renewcommand\baselinestretch{0.8}
\ptsize{14}
\begin{tabularx}{\textwidth}{|>{\centering}X|>{\PBS\centering}X|}
\multicolumn{2}{c}{Co ma zrobić Alicja, by uwierzytelnić wiadomość dla Bartka?} \\
\hline
jeśli Bartek ma klucz publiczny PKI & jeśli Bartek nie ma takiego klucza \\
\hline \hline
& niech Bartek wygeneruje sobie klucz publiczny DH \par i użyje go z jej kluczem prywatnym DH, by \\
\hline
\multicolumn{2}{|c|}{wygenerować nowy klucz symetryczny} \\
\hline
\multicolumn{2}{|c|}{użyć tego klucza do podpisania danych kodem MAC} \\
\hline
zaszyfrować klucz symetryczny \par kluczem publicznym Bartka & \\
\hline
dołączyć zaszyfrowany klucz symetryczny do danych & dołączyć jej publiczny klucz DH do danych \\
\hline
\multicolumn{2}{|c|}{wysłać dane do Bartka} \\
\hline
\end{tabularx}
\end{slide}

\begin{slide}
\slideheading{Podstawowe usługi PKI: Poufność}
Poufność to zapewnienie podmiotu, że nikt nie może odczytać danej wiadomości oprócz
explicite wybranych odbiorców. Pierwsza i oczywista myśl: zaszyfrować wszystkie dane kluczem publicznym odbiorcy.\\
To. Jest. P.O.W.O.L.N.E... Lepiej użyć szybkiej kryptografii symetrycznej (żeby uprościć, to niezależnie od wielkości danych):
\begin{itemize}
\item utwórz klucz symetryczny
\item użyj go (przy użyciu szyfru blokowego) do zaszyfrowania danych
\item wyślij zaszyfrowane dane do Bartka
 \begin{itemize}
 \item z własnym publicznym kluczem DH lub
 \item z kopią klucza symetrycznego zaszyfrowanego kluczem publicznym Bartka
 \end{itemize}
\end{itemize}
\end{slide}

\begin{slide}
\slideheading{Usługi dodane PKI: bezpieczna komunikacja}
Transmisja danych zabezpieczona przez podstawowe usługi PKI (uwierzytelnianie,
integralność, poufność) i nałożone na istniejącą infrastrukturę sieciową
daje \textit{bezpieczną komunikację}:
\begin{description}
\item[e-mail] S/MIMEv2 (RFC2311, RFC2312) lub PGP
\item[web] SSL/TLS (RFC2246)
\item[VPN] IPsec/IKE (RFC2401, RFC2411)
\end{description}
\end{slide}

\begin{slide}
\slideheading{Usługi dodane PKI: bezpieczny znacznik czas}
\begin{itemize}
\item kolejność zdarzeń musi być poza wątpliwością
\item zwłaszcza gdy korzystamy z certyfikatów, ich czasem życia i odwołaniami
\item zwłaszcza gdy używamy podpisu elektronicznego
\end{itemize}
\end{slide}

\begin{slide}
\slideheading{Usługi dodane PKI: wsparcie niezaprzeczalności}
%   - non-repudiation (authorship or delivery confirmation)
Produkt innych usług PKI: uwierzytelniania i bezpiecznego znacznika czasu.
\begin{itemize}
\item gdy już raz bezpiecznie podpiszesz dokument (czy jako autor, czy jako odbiorca),
\textbf{nie możesz} wyprzeć się faktu podpisania
\item chyba że jesteś w stanie dowieść, że podpis został wcześniej skradziony... może w sądzie uwierzą
\end{itemize}
\end{slide}

\begin{slide}
\slideheading{Usługi dodane PKI: notariat}
\begin{itemize}
\item notariusz (trzecia strona) zaświadcza, że jakieś dane są ,,poprawne''
\item co jest ,,poprawne'', to bardzo subiektywna sprawa
%   - notarization
\end{itemize}
\end{slide}

\begin{slide}
\slideheading{Usługi dodane PKI: zarządzanie uprawnieniami/polityką}
\begin{itemize}
\item mechanizmy do tworzenia szczegółowej kontroli dostępu dla użytkowników i grup (czy raczej ich certyfikatów)
\item kto (certyfikat klienta) może zrobić co i kiedy
\item czasem zawarte wprost w certyfikacie, ale to jest trudne w zarządzaniu
\end{itemize}
\end{slide}


\begin{slide}
\slideheading{Certyfikaty}
\renewcommand\baselinestretch{0.8}
\ptsize{17}
\begin{description}
\item[X.509v3] standard ISO, z kluczem publicznym, ogólne zaufanie do jednego centrum, próbuje powiązać osoby (ich nazwiska) z pojedynczymi certyfikatami na całym świecie; opisane przez IETF jako PKIX w RFC 3280
\item[SET] Secure Electronic Transaction: płatności kartami kredytowymi, ,,prywatne'' rozszerzenie X.509v3
\item[Atrybuty] oparte na rolach, RFC 3281, bazowane na X.509, bez klucza publicznego, podstawa dla Infrastruktury Zarządzania Uprawnieniami
\item[SPKI/SDSI] (Simple Public Key Infrastructure/Simple Distributed Security Infrastructure), odłącza nazwiska osób od certyfikatów; miało być proste, ale nikt tego nie używa
\item[certyfikaty PGP] (Pretty Good Privacy), przenosi ,,władzę'' z globalnej na każdego użytkownika oddzielnie {\footnotesize(więcej o tym później, na slajdzie Modele Zaufania)}
\end{description}
\end{slide}

\begin{slide}
\slideheading{struktura X.509 (RFC 3280)}
\renewcommand\baselinestretch{0.8}
\ptsize{17}
\begin{itemize}
\item Certyfikat
\begin{description}
\item[Version] identyfikuje wersję certyfikatu
\item[Serial Number] niepowtarzalny w obrębie danego CA identyfikator liczbowy certyfikatu
\item[Algorithm ID] algorytm użyty do podpisania certyfikatu
\item[Issuer] jednoznaczna nazwa wydawcy certyfikatu
\item[Validity] ważne nie przed i nie po
\item[Subject] jednoznaczna nazwa właściciela
\item[Subject Public Key Info] klucz publiczny (i jego algorytm) właściciela
\item[Issuer Unique ID] opcjonalny niepowtarzalny identyfikator wydawcy
\item[Subject Unique ID] opcjonalny niepowtarzalny identyfikator właściciela
\item[Extensions] opcjonalne rozszerzenia
\end{description}
\item Algorytm podpisu elektronicznego certyfikatu
\item Podpis elektroniczny certyfikatu
\end{itemize}
\end{slide}

\begin{slide}
\renewcommand\baselinestretch{0.8}
\ptsize{17}
\renewcommand\baselinestretch{0.8}
\begin{center}\textbf{Rozszerzenia X.509}\end{center}
\begin{description}
\item[Authority Key Identifier] niepowtarzalny identyfikator klucza służącego do weryfikacji podpisu elektronicznego certyfikatu
\item[Subject Key Identifier] niepowtarzalny identyfikator klucza publicznego w tym certyfikacie (dla rozróżnienia różnych kluczy tego samego właściciela)
\item[Key Usage] zastrzega użycie klucza do jednego lub więcej pól eksploatacji:
podpis elektroniczny, niezaprzeczalność, szyfrowanie kluczy, szyfrowanie danych, uzgadnianie kluczy, podpisywanie certyfikatów, podpisywanie list CRL, tylko szyfrowanie, tylko deszyfrowanie
\item[Extended Key Usage] lista identyfikatorów określających użycie klucza publicznego:
uwierzytelnianie TLS serwera, uwierzytelnianie TLS klienta, podpisywanie kodu, zabezpieczenie poczty, znacznik czasu, podpisywanie OCSP
\item[CRL Distribution Point] miejsce (zwykle URI), skąd można ściągnąć najnowsze listy CRL (pełne lub różnicowe)
\item[Private Key Usage Period] kiedy klucz prywatny może być używany (może być inne niż czas życia klucza publicznego); pomaga zarządzać kluczami
\item[Certificate Policies] identyfikatory polityki i opcjonalnych kwalifikatorów: praktyki centrum certyfikującego (Certification Practice Statement, CPS) i informacje dla użytkownika
\item[Policy Mappings] identyfikatory polityk ekwiwalentnych między dwoma CA
\item[Subject Alternative Name] alternatywne nazwy właściciela certyfikatu, np. adres e-mail, IP, URL itp. (musi być wypełnione, jeśli pole \textbf{Subject} jest puste)
\item[Issuer Alternative Name] alternatywne nazwy wydawcy certyfikatu
\end{description}
\end{slide}

\begin{slide}
\begin{description}
\item[Basic Constraints] podstawowe zastrzeżenia: podmiot końcowy (jeśli fałsz) lub certyfikat CA (jeśli prawda)
\item[Path Length Constraint] maksymalna liczba CA, które mogą być w łańcuchu certyfikatów za tym certyfikatem
\item[Name Constraints] dozwolone/wykluczone poddrzewa atrybutów w postaci DN, URI, e-mail, czegokolwiek hierarchicznego; pozwala elastycznie zarządzać (delegując władzę/uprawnienia)
\item[inne] Subject Directory Attributes, Policy Constraints, Inhibit Any Policy, Freshest CRL Pointer,
prywatne rozszerzenia np. Authority Information Access czy Subject Information Access
\end{description}
\end{slide}

\begin{slide}
\renewcommand\baselinestretch{0.8}
\ptsize{12}
\begin{verbatim}
% openssl s_client -connect www.sgh.waw.pl:443 -showcerts | \
  openssl x509 -noout -text
Certificate:
  Data:
    Version: 3 (0x2)
    Serial Number: 208317 (0x32dbd)
    Signature Algorithm: sha1WithRSAEncryption
    Issuer: C=PL, O=Unizeto Sp. z o.o., CN=Certum Level III
    Validity
      Not Before: Apr 18 16:29:54 2006 GMT
      Not After : Apr 18 16:29:54 2007 GMT
    Subject: C=PL, O=Szkola Glowna Handlowa, OU=Centrum Informatyczne,
             CN=*.sgh.waw.pl/emailAddress=unix@sgh.waw.pl
    Subject Public Key Info:
      Public Key Algorithm: rsaEncryption
      RSA Public Key: (1024 bit)
        Modulus (1024 bit):
          00:db:4d:35:90:3e:18:1c:c2:d8:f1:a1:e3:f4:da:
          54:4c:f0:5f:8e:48:36:09:5a:63:79:83:66:8e:4f:
          ff:9c:82:4e:12:3f:e6:3a:df:cc:62:bd:0d:7f:da:
          9d:ff:92:2a:72:0b:47:c2:a8:4a:ad:ad:7d:e2:e4:
          a4:c5:7f:2b:d3:27:82:a1:6e:a4:dc:52:1e:91:78:
          83:b1:be:6c:b7:fb:da:9f:ce:17:8e:24:a0:09:0e:
          13:79:0f:97:07:56:77:2f:7b:4f:11:8c:1e:2f:1c:
          55:0e:15:ae:0c:0d:09:cb:fa:39:cd:0c:40:91:7c:
          f7:a2:65:ef:b3:1e:de:65:3b
        Exponent: 65537 (0x10001)
    X509v3 extensions:
      X509v3 Extended Key Usage:
        TLS Web Server Authentication
      X509v3 Basic Constraints:
        CA:FALSE
      X509v3 CRL Distribution Points:
        URI:http://crl.certum.pl/class3.crl
      Authority Information Access:
        OCSP - URI:http://ocsp.certum.pl
      X509v3 Certificate Policies:
        Policy: 1.2.616.1.113527.2.2.3
         CPS: http://www.certum.pl/CPS
         User Notice:
          Organization: Unizeto Sp. z o.o.
          Number: 1
          Explicit Text: Usage of this certificate is strictly 
subjected to the Certum Certification Practice Statement (CPS) 
incorporated by reference herein and in the Certum Repository at
https://www.certum.pl/repository. This CPS is also available by 
mail at Unizeto Sp. z o.o. 70-486 Szczecin, Krolowej Korony 
Polskiej 21, Poland. Copyright (c) 1998-2004 Unizeto Sp. z o.o. 
All Rights Reserved.

  Signature Algorithm: sha1WithRSAEncryption
    8c:db:01:95:75:33:ff:2e:4a:8e:24:16:97:3b:7f:65:73:f0:
    e3:a7:23:61:d3:2a:f4:40:97:58:20:b7:69:39:70:b8:63:5d:
    2c:3e:c8:8b:ce:a6:86:02:64:df:4c:7f:a2:55:5b:d7:2f:e4:
    cd:8e:0c:16:42:10:ec:e7:8a:0c:96:f0:ff:cc:2d:06:bf:11:
    2f:7b:ff:94:39:5a:08:54:08:31:d9:31:ea:e3:d4:bd:e0:cc:
    4d:d2:23:64:f3:db:f9:8c:35:f8:61:d7:1e:2d:e2:0f:be:7f:
    bf:8c:f1:ae:10:52:f0:f5:f5:f4:fd:25:94:7e:0b:46:aa:17:
    ce:fb
\end{verbatim}
\end{slide}


\begin{slide}
\slideheading{Centra Certyfikacyjne}
Po angielsku Certificate Authorities, CA.
%The basic premise is that CA is vouching for the link between the entity identity and the public key.

CA dają poczucie pewności, że klucz publiczny zawarty w certyfikacie faktycznie
należy do podmiotu wymienionego w certyfikacie.

Podpis elektroniczny ,,złożony'' przez CA na certyfikacie zapewnia
\textit{kryptograficzne powiązanie} między kluczem publicznym podmiotu, jego nazwą
i innymi informacjami w certyfikacie, jak np. okresem ważności.
\end{slide}

\begin{slide}
\slideheading{Strony PKI}
\renewcommand\baselinestretch{0.8}
\begin{description}
\item [centra certyfikacyjne] (certification authorities) wydają certyfikaty
\item [abonenci] (subscribers) podmioty (indywidualni lub organizacje) korzystające z klucza prywatnego odpowiadającego publicznemu w certyfikacie
\item [klienci] (relying parties) podmioty polegające na certyfikacie
\item [centra rejestracyjne] podmioty wspierające CA w procesie uwierzytelniania tożsamości lub innych przymiotów aplikującego o certyfikat, inicjujące odwołanie certyfikatu na prośbę abonenta, akceptujące lub odrzucające żądania zmiany  kluczy w certyfikacie
\item [repozytoria] podmioty świadczące usługi publikacji, przechowywania i dostępu do certyfikatów, list CRL i innych dokumentów PKI
\end{description}
\end{slide}

\begin{slide}
\slideheading{Podstawowe obowiązki CA}
\begin{description}
\item[rejestracja abonentów] identyfikacja i uwierzytelnianie (często delegowane
do centr rejestracyjnych (Registration Authorities, RA)
\item[bezpieczne zarządzanie certyfikatem] tworzenie i wydawanie, dystrybucja, odnawianie certyfikatów i podpisywanie nowych kluczy (rekey), odwoływanie, zawieszanie
\item[zapewnienie informacji o statusie certyfikatu] wydawanie list odwołanych certyfikatów (CRL), utrzymywanie mechanizmów sprawdzania statusu on-line (OCSP)
\item[dostęp do certyfikatów i list CRL] przez Repozytorium Certyfikatów
(katalog online, może być zarządzany inną firmę) dostępnego dla klientów
\end{description}
\end{slide}

\begin{slide}
\slideheading{Rejestracja abonenta}
\begin{itemize}
\renewcommand\baselinestretch{0.8}
\item abonent tworzy swoją parę kluczy publiczny + prywatny
%(sometimes CA does that for him, but never for signing keys, only encrypting ones)
\item abonent dostarcza jakiś dowód tożsamości -- zależnie od polityki certyfikatu
i wymaganego poziomu ufności
\item abonent pokazuje, że jest w posiadaniu klucza prywatnego (podpisanie
jakichś danych, CA zweryfikuje kluczem publicznym)
\item CA wydaje certyfikat
\item CA podpisuje certyfikat własnym kluczem prywatnym
%\item * CA notifies subscriber of certificate issuance for review
\item abonent publikuje certyfikat (żeby inni mogli z niego korzystać)
\item CA publikuje certyfikat w repozytorium
\end{itemize}
\end{slide}

%American Bar Association, Section of Science \& Technology: Information Security
%{\ptsize{14}\url{http://www.abanet.org/scitech/ec/isc/}} published \textit{PKI Assessment Guide},
%360 pages to absorb, if you want to start (or assess) PKI/CA.

%Depending on assurance level required, 
%entity needs to provide \textit{proof of existance} (ID, passport, company 
%registry), in person, provide proof of key ownership, etc.

%CA in common sense is combination of Certification Authority, Certification Repository,
%Certificate Revocation publisher, Cross-Certification, Secure Time Stamping and a lot of
%paper work.
%\end{slide}

%XXX%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{slide}
\slideheading{Centra certyfikacyjne: podstawowa biurokracja}
\begin{description}
\item [Polityka Certyfikacyjna] (Certificate Policy, CP) określony zestaw zasad opisujących dozwolone przypadki użycia certyfikatu w konkretnym zastosowaniu czy klasie aplikacji o wspólnych wymaganiach co do bezpieczeństwa
%general requirements (and appropriate uses of certificates) PKI participants must meet in order to operate within PKI -- important for interoperability
\item [Komunikat o Praktykach Certyfikacyjnych] (Certification Policy Statement, CPS) opis praktyk i procedur, bardziej szczegółowy niż w CP -- gdy CP mówi o wymaganiach, CPS opisuje, jak CA je spełnia
\item [Porozumienie Abonenckie] wbrew nazwie: między CA a RA; koncentruje się na
odpowiedzialności abonenta i dozwolonych warunkach użycia certyfikatu
\end{description}
\end{slide}

\begin{slide}
\begin{description}
\item [Porozumienie Klienckie] określa warunki, po spełnieniu których klient może polegać
na certyfikacie (jak np. sprawdzenie statusu certyfikatów w łańcuchu)
\item [Komunikat Opisujący PKI] prosto i zwięźle najważniejsze punkty z CP i CPS
\item [inne porozumienia] dotyczące kompatybilności, porozumienia producentów, porozumienia związane z dystrybucją certyfikatów, wewnętrzne porozumienia związane z poziomem zaufania PKI
\item [inne biznesowe praktyki CA] plan zarządzania kluczami, instrukcje i polityka bezpieczeństwa, instrukcje treningów, używania, instalacji i dla użytkownika, przewodniki dla działu kadr i książki dla pracowników, polityka używania e-maili...
\end{description}
\end{slide}

\begin{slide}
\slideheading{Centra Certyfikujące: więcej biurokracji}
\renewcommand\baselinestretch{0.8}
\ptsize{17}
Opisy praktyk biznesowych CA dotyczące integralności usługi:
\begin{description}
\item [Kontrola środowiska CA] opisuje środowisko pracy
\item [Zarządzanie kluczami] opisuje procedury związane z kluczami samego CA
\item [Zarządzanie cyklem życia certyfikatów] opisuje procedury związane z certyfikatami abonentów
\end{description}
\end{slide}

\begin{slide}
\renewcommand\baselinestretch{0.8}
\ptsize{17}
Kontrola środowiska CA
\begin{itemize}
\item CPS i zarządzanie polityką dot. certyfikatów
\item zarządzanie bezpieczeństwem
\item klasyfikacja i zarządzanie zasobami
\item bezpieczeństwo osobiste
\item bezpieczeństwo fizyczne i środowiskowe
\item zarządzanie operacyjne 
\item zarządzanie dostępem do systemów
\item zarządzanie i rozwój systemów
\item zarządzanie planami ciągłości działania
\item monitorowanie i zgodność
\item zapisywanie zdarzeń
\end{itemize}
\end{slide}

\begin{slide}
\renewcommand\baselinestretch{0.8}
\ptsize{17}
Zarządzanie kluczami samego CA
\begin{itemize}
\item tworzenie kluczy CA
\item przechowywanie, archiwizacja i odtwarzanie kluczy CA
\item dystrybucja kluczy publicznych CA
\item (opcjonalne) odzyskiwanie klucza CA
\item używanie klucza CA
\item niszczenie klucza CA
\item archiwizacja
\item zarządzanie cyklem życia sprzętu kryptograficznego CA
\item (opcjonalne) usługi zarządzania kluczami abonenta
\end{itemize}
\end{slide}

\begin{slide}
\renewcommand\baselinestretch{0.8}
\ptsize{17}
Zarządzanie cyklem życia certyfikatów
\begin{itemize}
\item rejestracja abonentów
\item (opcjonalne) odnawianie certyfikatów
\item ponowne podpisywanie kluczy w certyfikacie (rekey)
\item wydawanie certyfikatów
\item dystrybucja certyfikatów
\item odwoływanie certyfikatów
\item (opcjonalne) zawieszanie certyfikatów
\item przetwarzanie informacji o statusie certyfikatów
%\item Integrated Circuit Life Cycle Management
\end{itemize}
\end{slide}

\begin{slide}
\slideheading{Odwoływanie Certyfikatów}
\begin{itemize}
\item certyfikat wiąże podmiot z kluczem publicznym
\item jeśli podmiot zmienia nazwę (nazwisko, pracę) lub klucz prywatny przestał być tajny... trzeba odwołać certyfikat!
\item \textbf{opóźnienie odwołania} to czas pomiędzy uzyskaniem informacji, że certyfikat powinien zostać odwołany, a wysłaniem samej informacji o odwołaniu -- bardzo ważny czynnik
\item metody
\begin{description}
\item[publikacje okresowe] jak listy certyfikatów odwołanych (CRL)
\item[systemy online] jak Online Certificate Status Protocol
\end{description}
\end{itemize}
\end{slide}

\begin{slide}
\center Publikacje okresowe (listy CRL)
\begin{description}
\item[Pełna lista CRL] problemy ze skalowalnością (duża!) i poprawnością danych
\item[Lista Odwołanych Centrów] (Authority Revocation Lists) do odwoływania certyfikatów CA, korzysta z rozszerzenia CRL nazwie "issuing distribution point"
\item[Punkty Dystrybucji CRL] (częściowe listy CRL) kilka list CRL z jednego CA, łatwiejsze w zarządzaniu, mogą wskazywać na URI; jednak muszą być statyczne
\item[Rozszerzone Punkty Dystrybucji CRL i Przekierowane CRL] wskaźniki do częściowych list CRL, ograniczone jakimś filtrem
\item[Listy różnicowe] różnice od ostatniej publikacji pełnej listy; małe i często
\item[Pośrednie listy CRL] sumy listy CRL z różnych CA (łatwiejsza weryfikacja)
\item[Drzewa Odwołanych Certyfikatów] (Certificate Revocation Trees) wymyślone przez Valicert, oparte na drzewach skrótu Merkle'a, wydajnie prezentują duże listy odwołanych certyfikatów
\end{description}
\end{slide}

\begin{slide}
\begin{center}
Systemy online
\end{center}
Online certificate status protocol (OCSP) RFC2560
\begin{description}
\item[żądanie] wersja protokołu, żądanie usługi, identyfikatory certyfikatów
\item[odpowiedź (ogólnie)] wersja, nazwa odpowiadającego, odpowiedzi na każdy z certyfikatów z pytania, dodatkowe rozszerzenia, algorytm podpisu, podpis
\item[odpowiedź na certyfikat] identyfikator docelowego certyfikatu, status (dobry, odwołany, nieznany), ważność odpowiedzi%
%(thisUpdate, nextUpdate (empty=always), producedAt)
, dodatkowe rozszerzenia
\end{description}
\end{slide}

\begin{slide}
\slideheading{CRL}
\begin{description}
\item[Listy Odwołanych Certyfikatów] (Certificate Revocation Lists) elektronicznie podpisane struktury danych
\begin{itemize}
\item zawierają listę odwołanych certyfikatów
\item integralność i uwierzytelnienie dzięki podpisowi elektronicznemu
\item podpisujący to zwykle wydawca odwołanego certyfikatu
\item mogą być trzymane w pamięci podręcznej
\end{itemize}
\end{description}
\end{slide}

\begin{slide}
\begin{description}
\item[CRL v1] specyfikacja X.509 z 1998; problemy:
\begin{itemize}
\item skalowalność (taka lista może być niezwykle duża)
\item problemy z rozszerzaniem
\item atak przez podłożenie innej listy
\end{itemize}
\item[CRL v2] dodaje ważną poprawkę: \textit{rozszerzenia}
\end{description}
\end{slide}

\begin{slide}
\slideheading{struktura CRL}
\renewcommand\baselinestretch{0.8}
\ptsize{17}
\begin{description}
\item[version] 2 lub brak (wtedy 1)
\item[signature] algorytm podpisu (np. md5WithRSAEncryption)
\item[issuer] jednoznaczna nazwa wydawcy CRL
\item[thisUpdate] data wydania
\item[nextUpdate] data następnego wydania (aka czas ważności tego wydania)
\item[revokedCertificates] lista numerów seryjnych odwołanych certyfikatów, czas
odwołania (plus, tylko w wersji 2, ewentualne rozszerzenia per wpis)
\item[extensions] tylko w wersji 2
\end{description}
\end{slide}

\begin{slide}
\renewcommand\baselinestretch{0.8}
\ptsize{17}
\begin{itemize}
\item rozszerzenia dla każdego wpisu (numeru seryjnego certyfikatu)
\begin{description}
\item[reason code] nieznany, utracony klucz, utracone CA, zmiana afiliacji, nadpisany,
zaprzestanie działania, wstrzymanie, usunięcie z CRL, wycofanie uprawnień...
\item[invalidity date] czas nieważności kluczy prywatnych i publicznych
\item[certificate issuer] wystawca certyfikatu dla przekierowanej listy CRL
\item[hold instruction code] co zrobić przy zawieszeniu certyfikatu (nic, zadzwonić do wystawcy, odrzucić)
\end{description}
\item rozszerzenia dla samej listy CRL
\begin{description}
\item[authority key identifier]
\item[issuer alternative name]
\item[CRL number]
\item[issuing distribution point]
\item[Delta CRL indicator]
\end{description}
\end{itemize}
\end{slide}

\begin{slide}
\renewcommand\baselinestretch{0.8}
\ptsize{12}
\begin{verbatim}
% wget http://crl.thawte.com/ThawteServerCA.crl
% openssl crl -inform der -text -noout -in ThawteServerCA.crl
Certificate Revocation List (CRL):
        Version 1 (0x0)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting 
                cc/OU=Certification Services Division/CN=Thawte Server 
                CA/emailAddress=server-certs@thawte.com
        Last Update: Dec  1 11:00:00 2006 GMT
        Next Update: Dec 29 11:00:00 2006 GMT
Revoked Certificates:
    Serial Number: 4B3D02FD9DCA2807A8E4FD4CC029385F
        Revocation Date: Oct 27 05:30:19 2006 GMT
    Serial Number: 4B463AB9B2FF900A6377EF14A330458B
        Revocation Date: Oct 23 20:47:28 2006 GMT
    Serial Number: 4B48D9D9606511B0B1AE3B61F00C9D8B
        Revocation Date: Mar 22 13:18:47 2006 GMT
[...]
    Signature Algorithm: sha1WithRSAEncryption
        cb:f8:f2:51:cf:96:a2:97:9a:8d:eb:7b:c3:71:5d:8e:e0:b9:
        83:1d:7e:3a:d1:ff:1b:f5:e5:27:3c:e4:12:20:0a:29:55:11:
        60:da:df:2d:ec:08:e7:95:e2:f5:0a:1e:24:f3:d5:27:fe:6a:
        e6:c1:a6:90:57:c2:e0:f8:03:25:17:8c:50:00:98:c7:de:a9:
        cc:68:2f:6f:c1:d6:c3:93:bd:2e:c5:be:70:76:20:9f:3b:44:
        2a:2e:d7:20:04:fc:b9:14:2a:cb:b8:2b:41:09:58:b4:b3:75:
        52:52:ad:df:c0:36:b9:2d:d5:85:47:7b:45:4b:70:a7:a1:3a:
        79:aa
\end{verbatim}
\end{slide}

%
% Certificate Authorities
%
% o overview
% o services provided
%   - certificate creation
%   - revocation lists
%   - cross certification
%   - digital timestamp
%   - directory service
% o Certification Policies: "a named set of
%   rules that indicates the applicability of a certificate to a
%   particular community and/or class of application with common security
%   requirements"
% o Certification Practice Statement 
%   - ABA Guidelines
% o technical requirements examples
%   - hardware (crypto module)
%   - procedures and people
%   - AICPA/CICA WebTrust for Certification Authorities
% o private CAs
%   - purpose
%   - getting widely accepted (distribute among clients, get root, cross CA)
%

%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% o key pairs
% o Certificate Authorities
%   - certificates (public key, owner data, expire date, CA name, CA signature)
%   - www servers, private, vpn, ssl services (smtp auth) etc.
% o Web of Trust
%   - pgp
% o key servers
% o storing \& securing private key
%   - disk file, symmetric crypto, hardware crypto (pin)
% o process flow
%
% http://ospkibook.sourceforge.net/
%
%%%% End Of Document %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%  

%%%

\begin{slide}
\slideheading{Gargantuizm PKI}
\begin{description}
\item[infrastruktura] centra certyfikujące, repozytoria certyfikatów,
odwoływanie certyfikatów, archiwizacja i odzyskiwanie kluczy, automatyczna
aktualizacja kluczy, zarządzanie historią kluczy, certyfikacja krzyżowa,
oprogramowanie klienckie
\item[usługi] uwierzytelnianie, integralność, poufność, bezpieczny znacznik czasu,
notariat, niezaprzeczalność, bezpieczne archiwum danych, tworzenie uprawnień/polityki,
weryfikacja uprawnień/polityki
\end{description}
\vskip5mm
\center Czy to \textit{wszystko} jest naprawdę potrzebne?
\end{slide}

\begin{slide}
\renewcommand\baselinestretch{0.8}
\ptsize{17}
\begin{tabularx}{\textwidth}{|!{\rule[-1cm]{0pt}{1.2cm}}>{\centering\vfill}X|>{\centering\vfill}X|>{\PBS\centering\vfill}X|}
\multicolumn{3}{c}{
\overlay{0}{www i poczta (ssl)}
\overlay{1}{\textcolor{red}{które są ważne}}
\overlay{2}{\textcolor{blue}{dla kilku instytucji}}
\overlay{3}{\textcolor{green}{rządowych}}}
\\ \hline
\overlay{0}{Centrum Certyfikacyjne}& 
\overlay{2}{\textcolor{blue}{Repozytorium Certyfikatów}}&
\overlay{1}{\textcolor{red}{Odwoływanie Certyfikatów}}
\\ \hline
\overlay{2}{\textcolor{blue}{Archiwizacja Kluczy}}& 
\overlay{3}{\textcolor{green}{Odzyskiwanie Kluczy}}& 
\overlay{3}{\textcolor{green}{Automatyczna Aktualizacja Kluczy}}
\\ \hline
\overlay{2}{\textcolor{blue}{Zarządzanie Historią Kluczy}}& 
\overlay{2}{\textcolor{blue}{Krzyżowa Certyfikacja}}&
\overlay{1}{\textcolor{red}{Oprogramowanie Klienckie}}
\\ \hline
\overlay{0}{Uwierzytelnianie}& 
\overlay{0}{Integralność}& 
\overlay{0}{Poufność}
\\ \hline
\overlay{2}{\textcolor{blue}{Bezpieczny Znacznik Czasu}}&
\overlay{3}{\textcolor{green}{Notariat}}&
\overlay{2}{\textcolor{blue}{Niezaprzeczalność}}
\\ \hline
\overlay{3}{\textcolor{green}{Bezpieczne Archiwum Danych}}&
\overlay{1}{\textcolor{red}{Tworzenie Uprawnień/Polityk}}&
\overlay{1}{\textcolor{red}{Weryfikacja Uprawnień/Polityk}}
\\ \hline
\end{tabularx}
\end{slide}

% Part III. 3. Public Key Infrastructure Trust Model}
%\begin{slide}
%\slideheading{PKI Trust Model}
%\begin{itemize}
%\item Overview
%\item Strict Hierarchy of Certificate Authorities
%\item Distributed Trust Architecture
%\item Mesh
%\item Hub-and-Spoke
%\item Web Model
%\item User-centric Trust
%\end{itemize}
%\end{slide}

\begin{slide}
\slideheading{Model Zaufania PKI}
Komu możesz ufać?
\begin{description}
\item [zaufanie] zdefiniowane przez ITU-T:\\
\textit{Podmiot "A" ufa podmiotowi "B", gdy "A" zakłada, że "B"
zachowa się dokładnie tak, jak "A" oczekuje}
\item [zaufanie PKI] wywodzi się z powyższego:\\\textit{
Podmiot ufa CA, gdy podmiot zakłada, że CA utworzy i będzie utrzymywać
dokładne i poprawne powiązanie atrybutów z kluczem publicznym}
\item [zaufanie do klucza publicznego] jeśli jesteś przekonany,
że klucz publiczny i prywatny należą do tego samego podmiotu
\end{description}
Założenia, oczekiwania, ludzkie zachowania\ldots
\end{slide}

%\newcommand\CAtree{\pstree{\Toval{subCA}}}
%\newcommand\CAuser{\Toval{user}}
\newcommand\CAtree{\pstree{\Tc{8pt}}}
\newcommand\CAuser{\TC*}

\begin{slide}
\center 
\slideheading{Ścisła hierarchia Centr Certyfikujących}
%\psset{showbbox=true}
\pstree[thislevelsep=0,edge=none,levelsep=2.5cm]{\Tn}{%
\pstree{\TR{Root CA}}{\pstree{\TR{sub CA}}{\pstree{\TR{sub CA}}{\TR{użytkownicy}}}}
\psset{edge=\ncline}
\pstree[radius=8pt]{\Tc{8pt}}{%
          \CAtree{
             \CAtree{\CAuser}
             \CAtree{\CAuser\CAuser\CAuser}
             }
          \CAtree{
             \skiplevel{\CAuser}
             \CAtree{\CAuser\CAuser}
             }
          \CAtree{
             \CAtree{\CAuser\CAuser}
             \CAtree{\CAuser}
             }
          }
}

Root CA jest \textit{kotwicą zaufania} \\
\small{Możesz utworzyć własny, podpisany przez siebie Root CA i się pobawić!}
\end{slide}

\begin{slide}
\center 
\slideheading{Architektura z Rozdzielonym Zaufaniem}

%\psset{showbbox=true}
\pstree[thislevelsep=0,edge=none,levelsep=2.5cm]{\Tn}{%
\pstree{\TR{równe Root CA}}{\pstree{\TR{sub CA}}{\TR{użytkownicy}}}
\psset{edge=\ncline}
          \CAtree{
             \CAtree{\CAuser}
             \CAtree{\CAuser\TR*{Bartek}\CAuser}
             }
          \CAtree{
             \skiplevel{\CAuser}
             \CAtree{\CAuser\CAuser}
             }
          \CAtree{
             \CAtree{\TR*{Alicja}\CAuser}
             \CAtree{\CAuser}
             }
}

\end{slide}

\begin{slide}
\center 
\slideheading{Sieć}

%\newcommand\CAtree{\pstree{\Tc{8pt}}}
%\psset{showbbox=true}
\pstree[thislevelsep=0,edge=none,levelsep=2.5cm]{\Tn}{%
\pstree{\TR{równe Root CA}}{\pstree{\TR{sub CA}}{\TR{użytkownicy}}}
\psset{edge=\ncline}
          \pstree{\Tc[name=A]{8pt}}{
             \CAtree{\CAuser}
             \CAtree{\CAuser\TR*{Bartek}\CAuser}
             }
          \pstree{\Tc[name=B]{8pt}}{
             \skiplevel{\CAuser}
             \CAtree{\TR{Jan}\CAuser}
             }
          \pstree{\Tc[name=C]{8pt}}{
             \CAtree{\TR*{Alicja}\CAuser}
             \CAtree{\CAuser}
             }
%\ncarc[linearc=0.3,linestyle=dashed,nodesep=0.4]{A}{B}
%\ncarc[linearc=0.3,linestyle=dashed,nodesep=0.4]{A}{C}
\ncarc[linestyle=dashed,arcangle=23]{A}{B}
\ncarc[linestyle=dashed,arcangle=45]{A}{C}\Bput{krzyżowa certyfikacja}
}

\tiny{tu: częściowa sieć}
\end{slide}

\begin{slide}
\center 
\slideheading{Oś i szprychy (Hub and Spoke)}

\pstree[thislevelsep=0,edge=none,levelsep=2.5cm]{\Tn}{%
\pstree{\TR{CA osi}}{\pstree{\TR{root CA}}{\pstree{\TR{sub CA}}{\TR{użytkownicy}}}}
\psset{edge={\ncline[linestyle=dashed]}}
\def\pstreehookiii{\psset{edge=\ncline}}
\pstree[radius=8pt]{\Tc{8pt}}{%
          \CAtree{
%\psset{edge=\ncline}
             \CAtree{\CAuser}
             \CAtree{\CAuser\CAuser\CAuser}
             }
          \CAtree{
%\psset{edge=\ncline}
             \skiplevel{\CAuser}
             \CAtree{\CAuser\CAuser}
             }
          \CAtree{
%\psset{edge=\ncline}
             \CAtree{\CAuser\CAuser}
             \CAtree{\CAuser}
             }
          }
}

\end{slide}

\begin{slide}
\slideheading{Model WWW}
\pstree[thislevelsep=0,edge=none,levelsep=2.5cm]{\Tn}{%
\pstree{\TR{w przeglądarce}}{\pstree{\TR{sub CA}}{\TR{użytkownicy}}}
\psset{edge=\ncline}
          \pstree{\Toval{CA$_1$}}{
             \CAtree{\CAuser}
             \CAtree{\CAuser\CAuser\CAuser}
             }
          \pstree{\Toval{CA$_2$}}{
             \skiplevel{\CAuser\CAuser\CAuser}
             }
          \pstree{\Toval{CA$_3$}}{
             \CAtree{\CAuser\CAuser}
             \CAtree{\CAuser}
             }
}
\end{slide}

\begin{slide}
\slideheading{Zaufanie użytkownika (user-centric)}
\pstree[thislevelsep=0,edge=none,levelsep=2.5cm]{\Tn}{
 \psset{edge=\ncline}
 \pstree{\Toval[name=M]{mama Kasi i Alicji}}{
   \pstree{\Toval[name=A]{Alicja, siostra Kasi}}{
 	\pstree[edge=none]{\Tn}{\Toval{nieznajomy}}
        \pstree{\Toval{kolega Alicji}}{\TC*\TC*\TC*}
   }
   \pstree{\Toval[name=K]{Kasia}}{
           \skiplevel{\TC*}
           \pstree{\Toval{Heniek}}{\TC*\Toval[name=J]{Jacek}}
   }
 }
 \pstree{\Toval[name=F]{Feliks, szef Kasi}}{
   \pstree{\Toval[name=D]{Dawid}}{
       \TC*
       \pstree{\Toval[name=B]{Bartek}}{\TC*\TC*}
   }
   \TC*
 }
% \ncline{K}{D}
 \ncline{K}{F}
 \ncline{K}{A}
 \ncline{B}{J}
}
\center model PGP\\
%''Six Degrees of Separation''
,,Sześć uścisków dłoni''
\end{slide}

\begin{slide}
\renewcommand\baselinestretch{0.8}
\ptsize{12}
\begin{verbatim}
% pgp +verbose=0 -kvv chopin@sgh
Type Bits/KeyID    Date       User ID
pub  1024/D818A489 1995/10/31 Piotr Kucharski <chopin@sgh>
sig       D818A489             Piotr Kucharski <chopin@sgh>
sig       61094A7D             Szymon Sokol <szymon@uci.agh>
sig       56A1520D             Tomasz R. Surmacz <ts@wroc.apk>
% pgp +verbose=0 -kvv ts@wroc
Type Bits/KeyID    Date       User ID
pub  1024/56A1520D 1995/04/23 Tomasz R. Surmacz <ts@wroc.apk>
sig       D818A489             Piotr Kucharski <chopin@sgh>
sig       C38B2AAD             Jan Rychter <jwr@itc.pw>
sig       61094A7D             Szymon Sokol <szymon@uci.agh>
sig       56A1520D             Tomasz R. Surmacz <ts@wroc.apk>
% pgp +verbose=0 -kvv szymon@uci
Type Bits/KeyID    Date       User ID
pub   512/61094A7D 1993/08/26 Szymon Sokol <szymon@uci.agh>
sig       8DF27F3D             <Wojtek.Sylwestrzak@icm>
sig       DA9F6825             Zbigniew Zych <zych@onet>
sig       56A1520D             Tomasz R. Surmacz <ts@wroc.apk>
\end{verbatim}
\ptsize{14}
MIT PGP Public Key Server \url{http://pgp.mit.edu/}
\begin{verbatim}
% pgp +verbose=0 -kvc chopin@sgh
Type Bits/KeyID    Date       User ID
pub  1024/D818A489 1995/10/31 Piotr Kucharski <chopin@sgh>
Key fingerprint =
    CE B8 CA 5D AC 3B 97 85  94 D5 8A 25 F3 4E 55 C6
\end{verbatim}
\end{slide}

\begin{slide}
\slideheading{Tworzenie i weryfikacja ścieżki certyfikatu}
\center
\pstree[treemode=U,thislevelsep=1cm,treefit=loose,edge={\ncline[linestyle=dashed]},levelsep=2.5cm]{\Tn}{%
\Toval[name=A]{CA$_A$}
\Toval[name=B]{CA$_B$}
\pstree{\Toval[name=C]{CA$_C$}}{\Toval[name=E]{CA$_E$}}
\pstree{\Toval[name=D]{CA$_D$}}{\Toval[name=F]{CA$_F$}}
}

\pstree[thislevelsep=1cm,edge=none,levelsep=2.5cm]{\Tn}{%
\psset{edge=\ncline}
     \pstree{\Toval[name=1]{CA$_1$}}{\CAuser\CAuser\TR*{Bartek}\CAuser}
     \pstree{\Toval[name=2]{CA$_2$}}{\CAuser\CAuser\CAuser}
     \pstree{\Toval[name=3]{CA$_3$}}{\CAuser\TR*{Alicja}\CAuser}
\ncline[linestyle=dashed]{A}{2}
\ncline[linestyle=dashed]{B}{2}
\ncline[linestyle=dashed]{C}{3}
\ncline[linestyle=dashed]{D}{3}
\ncline[linestyle=dashed]{1}{2}
\ncline[linestyle=dashed]{3}{2}
\ncline[linestyle=dashed]{E}{B}
}
\end{slide}

\begin{slide}
\slideheading{Problemy z tradycyjną PKI: technologiczne}
{\ptsize{14} \url{http://www.anu.edu.au/people/Roger.Clarke/II/PKIMisFit.html}}
\begin{description}
\item[problemy z podpisem elektronicznym] trzecia strona musi sprawdzić, czy klucz prywatny jest we właściwych rękach, trzecia strona musi być zaufana, klucz prywatny musi mieć zapewnione wysokie bezpieczeństwo (by nikt nie uzyskał do niego dostępu), klucz publiczny musi być odpowiedni, trzeba mieć wsparcie infrastruktury, informacje o wykradzionych kluczach i odwołaniach certyfikatów musi być szybko przekazana wszystkim (ale bez nadużywania sieci), podpis elektroniczny opiera się na funkcjach skrótu, które z natury są kolizyjne
\item [klucze publiczne] mogą być podrabiane (te wysyłane z wiadomością, zapisane na ftp/www lub w repozytoriach)... z tego powodu potrzebujemy certyfikatów
\end{description}
\end{slide}

\begin{slide}
\slideheading{Problemy z tradycyjną PKI: technologiczne}
\begin{description}
\item [proces uwierzytelniania przy wydawaniu certyfikatu]
(powiązanie klucza publicznego z jakimś podmiotem) musi być bezpieczny na wszystkich etapach (przyjście do RA, okazanie dokumentu ze zdjęciem, podanie klucza publicznego, dowód na posiadanie klucza prywatnego (podpisywanie na oczach RA), \textit{pokazanie dowodów na bezpieczeństwo klucza prywatnego}, podanie punktu/osoby kontaktowej, wybieranie punktu otrzymania certyfikatu
\item[CA] musi być zaufane i nie ma łatwego sposobu na odkrycie, czy CA nie zostało skompromitowane i czy certyfikat został wydany poprawnie
%\item each model of trust has own problems (global trust -- SPoF, distributed -- no communication, web -- lost control, user-centric -- poor scalability)
%\item PKI breaks privacy and explicitly does not allow anonymity
%\item PKI does not allow for many certificates per entity
\end{description}
\end{slide}

\begin{slide}
\slideheading{Problemy z tradycyjną PKI: technologiczne}
\begin{description}
\item[certyfikat X.509v3] jedna para kluczy na osobę, ,,wyróżniona nazwa'' jednoznaczna w całej przeogromnej przestrzeni nazw, nie pozwala na pseudonimy, mały wpływ na sposób generowania pary kluczy, a w wielu przypadkach taka generacja jest poza kontrolą danej osoby (co może oznaczać, że klucz prywatny nie jest prywatny na starcie), mały wybór nośników przechowujących klucz prywatny (token, dyskietka), certyfikaty należą do wydawcy (użytkownik tylko nabywa praw do używania); problemy z odwoływaniem
\end{description}
\end{slide}

\begin{slide}
\slideheading{Problemy z tradycyjną PKI: model zaufania}
\begin{description}
\item[hierarchiczny model zaufania] zaufanie do CA nie jest automatyczne, każde CA musi być podpisane przez jakieś wyższego rzędu, póki nie osiągnie się mitycznego CA, do którego wszyscy mają bezwarunkowe zaufanie
\item[dyktatura] wszystkie strony muszą odkryć swoją tożsamość, nawet jeśli potrzebują ujawnić tylko niektóre swoje atrybuty (wiek, kwalifikacje)
%all parties are required to disclose their identity even if it is needed only to communicate elligibility (age, qualifications etc.)
\item[jednoznacza wyróżniona nazwa] nie może być dwóch ,,Janów Kowalskich'', muszą być jakoś rozróżnieni; to także zabrania posiadania więcej niż jednego certyfikatu na osobę
\end{description}
\end{slide}

\begin{slide}
\slideheading{Problemy z tradycyjną PKI: (nie)bezpieczeństwo klucza prywatnego}
\begin{description}
\item[serwery korporacyjne] mają włamania, klucze prywatne użytkowników mogą zostać skradzione
\item[przechowywanie] użytkownicy zwykle zapisują swoje klucze prywatne na swoich stacjach roboczych, które są bezpośrednio podłączone do Internetu! to daje wiele możliwości odkrycia, skopiowania lub użycia kluczy prywatnych przez złośliwe oprogramowanie
\end{description}
\end{slide}

\begin{slide}
\slideheading{Problemy z tradycyjną PKI: ograniczone ubezpieczenie}
\begin{description}
\item[ubezpieczenia] praktycznie brak; CA starają się minimalizować odpowiedzialność
finansową w ,,Komunikatach Polityki Certyfikacyjnej'' oraz, co gorsza, wydają certyfikaty za różną cenę z różnym stopniem dokładności sprawdzania tożsamości przy wydawaniu certyfikatu
\item[BRAK ubezpieczenia] (i pewności) odnośnie:
\begin{itemize}
\item czy klucz prywatny był (w trakcie wydawania certyfikatu) dostępny tylko ,,właścicielowi''
\item czy klucz prywatny jest \textit{teraz} dostępny tylko ,,właścicielowi''
\item czy klucza prywatnego użył ,,właściciel''
\item czy klucza prywatnego użył ,,właściciel'' bez przymusu
%freely and consently
\end{itemize}
\end{description}
\end{slide}

\begin{slide}
\slideheading{Problemy z tradycyjną PKI: prywatność}
\begin{description}
\item[identyfikacja] rejestracja wymaga narzucania się z żądaniem dokumentów lub biometryk
\item[rejestry] certyfikatów są pełne danych osobowych
\item[listy CRL] powinny być sprawdzane przy każdej transakcji -- 
stwarza to zagrożenie śledzenia e-aktywności danej osoby i daje władzom
możliwość wymazania tożsamości danej osoby
\item[anonimowość] zwiększone użycie (nazwanych) certyfikatów może prowadzić
do załamania się tradycji anonimowości i pseudonimowości
\end{description}
\end{slide}


\begin{slide}
\slideheading{Problemy z tradycyjną PKI: alternatywy}
Modele różne od (naiwnego) wojskowego konceptu absolutnego zaufania:
\begin{description}
\item[sieć zaufania PGP] nie ma CA, każdy może wydać certyfikat, odporność na awarie przez mnogość (ścieżek do) certyfikatów, zaufanie jest względne nie absolutne -- jak w prawdziwym świecie
\item[SPKI/SDSI] porzucona globalna przestrzeń nazw, odrzucone założenie, że certyfikat pewnie jest związany z jakimś podmiotem, niech klienci decydują, atrybuty są związane z kluczami publicznymi, nie z tożsamościami z prawdziwego świata; wspiera pseudonimy
\item[inne] Stefan Brand's Alternative Certificates, Reputation and Brand, Trust-Management systems
\end{description}
\end{slide}
