Temat : Charakterystyka i implementacja wybranego standardu

podpisu cyfrowego.

I Krótka charakterystyka Podpisu Cyfrowego

1. Czym jest Podpis Elektroniczny (Cyfrowy)

Podpis elektroniczny (cyfrowy) to dane w postaci elektronicznej, które wraz z innymi danymi, do których zostały dołączone lub z którymi są logicznie powiązane, służą do identyfikacji osoby składającej podpis. Musi on spełniać przynajmniej te same warunki, co podpis tradycyjny, tj.

• powinien identyfikować tożsamość składającego podpis;

• stwarzać możliwość weryfikacji;

• być trudny do podrobienia;

• na trwałe łączyć się z dokumentem.

    Podpis elektroniczny daje większe możliwości zabezpieczeń niż podpis odręczny. Jego użycie może uniemożliwić wprowadzanie w dokumencie nieuzgodnionych wcześniej zmian.
Dane niezbędne do weryfikacji podpisu oraz jego właściciela określone są za pomocą certyfikatu. Nadzór nad działalnością świadczenia usług certyfikacyjnych będzie prowadził minister gospodarki, udzielający również wpisu i akredytacji przedsiębiorcom świadczącym tego typu usługi.

    Na podpis elektroniczny składa się kilka dobranych w specjalny sposób i przypisanych do jednej osoby niepowtarzalnych ciągów bitów (kluczy kryptograficznych) wraz z odpowiednim algorytmem pracującym na tych kluczach oraz podpisywanej wiadomości. Zanim jednak przejdę do opisu działania podpisu cyfrowego, krótko powiem o podstawowych wymaganiach wobec usług kryptograficznych. Najważniejsze to:

• poufność - ochrona informacji przed jej poznaniem przez osoby nieuprawnione; poufność wiadomości może zapewnić jej zaszyfrowanie;

• integralność - ochrona przed wprowadzaniem zmian do wiadomości przez osoby do tego nieupoważnione; do tego celu używa się właśnie podpisów cyfrowych;

• uwierzytelnianie - potwierdzenie tożsamości danego użytkownika i/lub potwierdzenie prawdziwości przesłanej wiadomości; do weryfikacji tożsamości służą certyfikaty nadawane przez specjalne instytucje;

• niezaprzeczalność - uniemożliwia wyparcie się przez nadawcę faktu wysłania wiadomości o ustalonej treści.

2. W jaki sposób działa Podpis Elektroniczny

 Do podpisu cyfrowego potrzebny jest klucz asymetryczny (tzw. para kluczy publiczny/prywatny). Klucz prywatny jest znany tylko użytkownikowi i jego poufność jest jednym z najważniejszych elementów bezpieczeństwa podpisu. Klucz publiczny jest jawny, z jego użyciem zostaje utworzony podpis cyfrowy. Klucze używane do podpisu są inne niż klucze używane w protokole SSL.

    Wygenerowanie podpisu odbywa się następująco. Wszystkie dane operacji (np. kwota przelewu, numery rachunków) są formatowane w ciąg bitów. Na podstawie sformatowanych danych algorytm haszujący generuje unikalną krótką wartość hash (np. algorytm MD5 generuje wartość 128-bitową). Następnie hash jest szyfrowany za pomocą klucza prywatnego użytkownika (np. algorytmem RSA). Zaszyfrowana wartość hash jest podpisem cyfrowym danej transakcji. Wszystko to powinno odbywać się na komputerze użytkownika (czyli w środowisku WWW może to robić applet), następnie dane operacji wraz z elektronicznym podpisem są transmitowane np: do serwera banku.

Generowanie podpisu cyfrowego

    W serwerze banku następuję weryfikacja prawdziwości podpisu. Na podstawie sformatowanych danych operacji generowany jest hash A. Podpis cyfrowy jest odszyfrowany za pomocą klucza publicznego użytkownika i otrzymana wartość to hash B. Jeśli obie wartości hash są równe, to podpis jest prawidłowy, a operacja zostaje wykonana.

Weryfikacja podpisu cyfrowego

Certyfikat udzielany kluczowi klienta zapewnia jego autentyczność, powoduje jego uwierzytelnienie. Certyfikaty wydawane są przez zaufane Urzędy Certyfikacji (ang. Certification Authority - CA). Algorytm haszujący zapewnia, że wszelkie modyfikacje w danych transakcji zostaną wykryte. Zaszyfrowanie wartości hash uniemożliwa jednoczesne zmiany w danych transakcji i odpowiednie do tych zmian podrobienie podpisu cyfrowego.

3. Algorytm Podpisu Cyfrowego RSA

Jednym z najważniejszych i najlepszych algorytmów szyfrowania w systemie z kluczem publicznym jest algorytm RSA. Był on używany przez wcześniejsze wersje programu PGP, a także wiele innych typów transmisji szyfrowanych. Należy uświadomić sobie różnicę pomiędzy algorytmem, który jest konstrukcją matematyczną, a programem, takim jak PGP, który stosuje algorytm do wykonywania określonych zadań. Inaczej mówiąc, algorytm można porównać do młotka - bez poruszającej nim ręki (czyli programu, na przykład PGP) jest bezużyteczny. Algorytm RSA został opracowany przez matematyków z uczelni MIT. (Jeden z nich, Ronald Rivest, ma swoją stronę w Internecie pod adresem ~http://theory.les.mit.edu/~rivest.) Algorytm RSA generuje losowo bardzo dużą liczbę pierwszą - klucz publiczny. Klucz ten służy do utworzenia innej bardzo dużej liczby pierwszej (klucza prywatnego) za pomocą kilku dość złożonych funkcji matematycznych. Użytkownicy korzystają z tych kluczy do szyfrowania dokumentów, wysyłanych do siebie przez dwie lub więcej osób, i do odszyfrowywania dokumentów po ich otrzymaniu. Rivest, Shamir i Adleman podają cztery podstawowe cechy opracowanego przez siebie algorytmu.

1. Odszyfrowanie zaszyfrowanej formy wiadomości prowadzi do uzyskania wiadomości oryginalnej. Równanie to może być zapisane następująco: D(E(M))=M W tym równaniu D oznacza operację odszyfrowania, E oznacza operację szyfrowania, a M oznacza rzeczywistą wiadomość.

2. E i D są dosyć łatwe do obliczenia.

3. Publiczne podanie E nie ujawnia żadnego prostego sposobu obliczenia D. Dlatego tylko użytkownik znający wartość D może odszyfrować wiadomość zaszyfrowaną za pomocą E.

4. Odszyfrowanie informacji M, a następnie zaszyfrowanie jej daje w wyniku M. Inaczej mówiąc, odwrócenie poprzednio podanej funkcji jest operacją prawdziwą, co można zapisać następująco: E(D(M))=M Jak podają Rivest, Shamir i Adleman, jeśli ktoś transmitujący dane użył procedury spełniającej warunek 3, to inni użytkownicy próbujący odszyfrować wiadomość musieliby próbować wszystkich możliwych kluczy, aż do znalezienia klucza spełniającego warunek E(M)=D. Czynność ta jest dosyć prosta, jeżeli liczby szyfrujące mają 10 lub nawet 20 cyfr. Jednak dawne programy szyfrujące RSA używały liczb o długości do 512 bitów, zarówno dla klucza publicznego (E), jak i prywatnego (D) - liczby te w reprezentacji dziesiętnej mają 154 cyfry. Poza tym obie liczby są bardzo dużymi liczbami pierwszymi. Przetwarzanie takich liczb wymaga ogromnej mocy obliczeniowej - rzeczywiście nikt nie był w stanie złamać 512-bitowego klucza stosując brutalny atak siłowy. Funkcja spełniająca warunki 1-3 jest zwana funkcją - zapadnią działającą w jedną stronę, ponieważ, jak łatwo zauważyć, można ją obliczyć szybko w jedną stronę, ale nie w drugą. Funkcja jest zwana zapadnią, gdyż można łatwo obliczyć funkcje odwrotne, jeśli się zna pewną prywatną informację (klucz).

    Koncepcja algorytmu RSA nie jest skomplikowana. Procedura jest podobna do opisanej w poprzednim paragrafie, zawiera poza tym program wykonujący niezbędne czynności umożliwiające upewnienie się, że plik jest szyfrowany poprawnie. Klucz szyfrowania, oznaczony jako E, jest związany z pewną stałą n. Stała ta określa limit długości szyfrowanego bloku (czyli jak wiele bajtów danych może zawierać pojedynczy szyfrowany blok). Szyfrowanie jest wykonywane w trzech prostych krokach, omówionych poniżej.

1. Program wdrażający algorytm RSA przekształca wiadomość tekstową w liczbę całkowitą z przedziału między 0 a (n-1). Metoda używana do konwertowania tekstu na liczbę zależy od konkretnego programu. Duże wiadomości (takie, które nic mogą być reprezentowane przez liczbę mniejszą od n-1) są dzielone przez program na kilka bloków, z których każdy jest określony przez osobną liczbę całkowitą, mniejszą od n-1.

2. Program szyfruje wiadomość podnosząc każdą liczbę całkowitą do potęgi E-tej (czyli blokE). Następnie program wykonuje działanie modulo (szczególny rodzaj działania, które podaje tylko resztę z operacji dzielenia) na powstałej wartości, dzieląc ją przez m i zapisując resztę jako szyfrowaną wiadomość. Wiadomość ma teraz postać zaszyfrowanego dokumentu tekstowego C.

3. Aby odszyfrować wiadomość C, jej odbiorca podnosi ją do potęgi D, a następnie wynik dzieli modulo n. Powstaje seria wartości, reprezentująca bloki w odszyfrowanym pliku, które program konwertuje z powrotem na tekst za pomocą tej samej metody, co użyta poprzednio do konwersji tekstu.

4. Co nie jest Podpisem Elektronicznym

1. Kombinacja dwóch elementów: identyfikator użytkownika, hasło.
   Słabe zabezpieczenie przed podszywaniem.
   Istnieje możliwość modyfikacji transakcji po jej przyjęciu przez serwer banku, a przed jej realizacją w głównym systemie bankowym (gdzie następuje jej zaksięgowanie i np. przekazanie do KIR'u). Czyli nie ma zapewnionej integralności transakcji.

2. Kombinacja trzech elementów: identyfikator użytkownika, hasło użytkownika, liczba tokena (token zawiera algorytm symetryczny).
   Wysokie zabezpieczenie przed podszywaniem. Brak integralności danych transakcji od chwili wysłania danych z przeglądarki, w czasie transmisji danych przez sieć dane są zaszyfrowane, następnie są zapisywane w systemie internetowym banku (włamując się do systemu internetowego banku można ingerować w transakcję przed przekazaniem jej do głównego systemu bankowego).

5. Idea szyfrowania w Podpisie Cyfrowym

 W dużym skrócie idee szyfrowania tą metodą można przedstawić następująco. Wyobraźmy sobie dwie osoby korespondujące ze sobą - może to być Alicja będąca klientem banku PKO SA, a drugą osobą Bobem - przedstawicielem samego Banku PKO SA.

    Alicja chce poprzez INTERNET dokonać transakcji bankowej i nakazuje za pomocą poczty elektronicznej dokonać przelewu swoich pieniędzy na inne konto jakiejś osoby w Szwajcarii.

Przesyłkę tą dostaje Bob - pracownik BANKU PKO SA - nasuwają się pytania:

• Na jakiej podstawie Bob ma ufać dokumentowi elektronicznemu ?

• Jaką pewność ma Bob, że przesyłka została faktycznie wysłana przez Alicję, a nie przez złodzieja mającego konto w Szwajcarii ?

• A w końcu być może przesyłka elektroniczna, która trafiła do Boba, została wysłana faktycznie przez Alicję tyle, że po drodze została podmieniona przez kogoś jej treść co do sumy przelewu na niekorzyść Alicji ?

Aby zapobiec tego rodzaju sytuacjom matematycy opracowali tzw. asymetryczną metodę szyfrowania - metodę kluczy publicznych i prywatnych.
Polega ona na tym, że Alicji na podstawie pewnych przepisów matematycznych - mających związek z twierdzeniami o liczbach pierwszych - podaje się dwie liczby

• klucz prywatny

• klucz publiczny

Klucz prywatny jest poufny i nasza Alicja powinna trzymać go w wielkiej tajemnicy
Klucz publiczny jest jawny i Alicja może dawać go wszystkim osobom ( a nawet powinna) z którymi koresponduje. Klucze te stanowią coś w rodzaju dopełniającej się pary

6. Klucz prywatny i klucz publiczny

Klucz prywatny jest poufny i nasza Alicja powinna trzymać go w wielkiej tajemnicy
Klucz publiczny jest jawny i Alicja może dawać go wszystkim osobom ( a nawet powinna) z którymi koresponduje. Klucze te stanowią coś w rodzaju dopełniającej się pary

Za pomocą klucza publicznego Alicji wszyscy którzy są w jego posiadaniu mogą szyfrować z jego pomocą informacje przeznaczone dla Alicji
Alicja natomiast i TYLKO ONA i TYLKO za pomocą swojego tajnego klucza prywatnego może te informacje rozszyfrować
Metoda ta jest na tyle sprytna, iż pomimo to, że kilka osób zna publiczny klucz Alicji i każda z tych osób jest w stanie zaszyfrować informacje, to żadna z tych osób nie jest w stanie tych informacji rozszyfrować, gdyż do tego celu potrzebna jest znajomość prywatnego klucza Alicji, a tylko ona jest w jego posiadaniu.

Odwrotnie - jeśli Alicja zaszyfruje informacje kluczem prywatnym to informacji. ta może zostać odszyfrowana jedynie kluczem publicznym Alicji - w tym sensie klucz prywatny i publiczny stanowią coś w rodzaju dopełniającej się pary.

Co z tego praktycznie wynika ? Ano to, że jeśli Alicja wyśle zaszyfrowaną za pomocą swojego klucza prywatnego przesyłkę do BANKU PKO SA, a BANK dysponuje kluczem publicznym Alicji, bo Alicja wcześniej wysłała BANKOWI swój klucz publiczny, to BANK rozszyfrowując przesyłkę kluczem publicznym Alicji ma prawie pewność, że przesyłka faktycznie została wysłana przez nią - bo skoro udało się ją rozszyfrować kluczem publicznym Alicji to oznacza, że musiała zostać zaszyfrowana jej kluczem prywatnym a ponieważ jest on tajny i tylko Alicja go posiada więc tylko ona mogła tą przesyłkę wysłać!!!

Linijkę wyżej napisałem "BANK ma prawie pewność, że przesyłka faktycznie została wysłana przez Alicję".
Dlaczego nie ma całkowitej pewności?
Pomińmy fakt, że Alicji ktoś mógł po prostu wykraść jej klucz prywatny, natomiast zauważmy, że Alicja musiała na początku całej procedury powiadomić BANK jaki jest jej klucz publiczny. - I tu jest pies pogrzebany.
A co będzie jeśli w tej fazie przekazywania klucza publicznego ktoś (jakiś gangster) wyśle do BANKU swój klucz publiczny i poda się za Alicję zanim ona to uczyni?
Aby pozbyć się tej możliwości wymyślono tzw. Urzędy Certyfikacyjne, które potwierdzają autentyczność klucza publicznego.
Dysponując Urzędem Certyfikacyjnym BANK sprawdza czy klucz publiczny, który rzekomo jest wystawiony przez Alicję faktycznie należy do Alicji. Tak więc urząd certyfikacyjny jest czymś w rodzaju składnicy podpisów cyfrowych wraz z możliwością ich tworzenia przydzielania tym, którzy sobie tego zażyczą. Tego rodzaju Urząd Certyfikacyjny przechowuje klucze publiczne i prywatne osób które maja konta w takim urzędzie certyfikacyjnym i poświadcza autentyczność podpisów (kluczy publicznych) tym wszystkim którzy tego potrzebują np. BANKOWI w naszej historii o Kowalskim. Nie muszę dodawać, że tego rodzaju dane są pod szczególną ochroną - Jeden z serwerów Uniwersyteckich na którym jest posadowiony urząd certyfikacyjny taka ochronę ma!!!

Dochodzi jeszcze problem - nie tyle autentyfikacji autora, ten mamy już rozwiązany metodą opisana wyżej - ale problem polegający na tym że treść przesyłki wysłanej przez Alicję może zostać zmieniona zanim dotarła do BANKU.
W uproszczeniu - można temu zapobiec tworząc niepowtarzalny, zależny od treści przesyłki i dla niej charakterystyczny ciąg znaków, szyfrowany dodatkowo kluczem prywatnym Alicji.
Jeśli treść przesyłki zostanie przez kogoś zmieniona to wystąpi rozbieżność między zmienioną treścią przesyłki a utworzonym na podstawie pierwotnego tekstu - ciągu znaków dołączonych do przesyłki, ponieważ ciąg znaków charakterystyczny dla przesyłki jest szyfrowany kluczem prywatnym Alicji to niemożliwa jest niezauważalna ingerencja w treść przesyłki!

Taka metoda szyfrowania nazywa się niesymetryczna metodą szyfrowania (niesymetryczną bo potrzebne są dwa klucze jeden do szyfrowania a drugi do deszyfrowania - klucz prywatny i klucz publiczny)

Ważną rolę pełni tu Urząd Certyfikacyjny. bez jego istnienia możliwe są oszustwa i podstawienia fikcyjnych osób i podpisów cyfrowych. urząd certyfikacyjny (którym juz dziś dysponuje Uniwersytet Warszawski w Systemie MERCURY ) zapobiega tego rodzaju możliwościom!!

7. Ważne uwagi

Klucz prywatny jest Państwa sekretem, którego NIE MOŻNA zdradzić nikomu. Klucza prywatnego nikomu nie dajemy. Przechowujemy go w bezpiecznym miejscu i zabezpieczamy hasłem, aby w przypadku próby jego użycia bez znajomości hasła było to niemożliwe.

    Inaczej jest z kluczem publicznym. Tu wręcz przeciwnie - klucz ten jest jawny i dostęp do niego jest nieograniczony. Klucz publiczny uzyskany przez nas od kogoś (certyfikat elektroniczny świadczy, że faktycznie jest to klucz publiczny tej osoby), kto jest właścicielem tego klucza publicznego (i odpowiadającego mu klucza prywatnego) posłuży nam do szyfrowania informacji do tej osoby i tylko do niej (oznacza to, że przesyłka zaszyfrowana przy jego pomocy może być odszyfrowana TYLKO przez tą osobę za pomocą odpowiadającego klucza prywatnego tej osoby.

    Sam nasz klucz publiczny można wyeksportować z poziomu aplikacji używanej do wysyłania/odbioru przesyłek, dostając podpisany elektronicznie list możemy taki klucz publiczny zaimportować automatycznie. W takim przypadku aplikacja pocztowa umożliwi nam dołączenie m.in. klucza publicznego - dołączonego do przesyłki - do Certyfikatów Odbiorców. Od tego momentu możemy przesyłać zaszyfrowane informacje do osoby od której klucz publiczny (ściślej Certyfikat ) został uzyskany.

Wydany certyfikat służący do elektronicznego podpisywania przesyłek jest ściśle związany z danym kontem pocztowym. Jeśli mamy kilka kont pocztowym i w każdym z nich chcemy stosować podpisy elektroniczne, to musimy mieć kilka certyfikatów, z których każdy przeznaczony jest do odpowiadającego mu konta pocztowego.

Podsumowując:

• Klucz prywatny jest naszym sekretem i słuzy do podpisywania naszych listów lub deszyfracji informacji nam przesłanych. Przechowujmy go w bezpiecznym miejscu, tak by nikt niepowołany nie był w jego posiadaniu!

• Nasz klucz publiczny jest jawny i słuzy do szyfrowania informacji do nas. Osoba chcąca przesłać nam zaszyfrowaną informację musi byc w jego posiadaniu.

• Do każdego konta pocztowego danej osoby przypisany jest osobny certyfikat elektroniczny.

8. 
   Krótka charakterystyka urządzeń opartych o PKI

Token DigiPass 300 jest urządzeniem szyfrującym dane

    Stosuje się go na zasadzie pytanie/odpowiedĽ. Token zawiera klawiaturę cyfrową oraz wyświetlacz ciekłokrystaliczny. Token jest wielkości małego kalkulatorka. Dostęp do niego jest dodatkowo chroniony przez 6-cyfrowy PIN. Token posiada również złącze na podczerwień, za pomocą którego jest on wstępnie programowany przez bank.

    Token ma wbudowany algorytm szyfrujący DES (symetryczny) oraz tajny klucz symetryczny, token podcza szyfrowania uwzględnia również aktualny czas (z dokładnością do 15s). Użytkownik po wprowadzeniu operacji (np. przelewu) oraz swojego hasła na stronie wysyła formularz do serwera, operacja jeszcze nie zostaje wykonana. Serwer werifykuje dane i przesyła odpowiedĽ zawierającą ciąg cyfr, które zostały wygenerowane za pomocą tzw. funkcji skrótu na podstawie operacji, ten ciąg cyfr nazywany jest hash codem. Użytkownik wprowadza hash code do tokena, następnie token szyfruje go i wyświetla ciąg cyfr, który jest dodatkowym unikalnym hasłem dla operacji. Użytkownik wprowadza unikalne hasło na stronie, po czym znów wysyła formularz do banku i to kończy zlecenie wykonania operacji. System internetowy oczywiście potrafi zweryfikować czy hasło jest prawidłowe.

    W Pekao niemal wszystkie operacje (łącznie z usunięciem listu ze skrzynki) wymagają użycia tokena. W WBK token musi być użyty tylko przy wykonywaniu przelewów na obce konto.

Token RSA SecureID

    Token RSA SecureId jest generatorem haseł jednorazowych. Token na zewnątrz zawiera jedynie wyświetlacz ciekłokrystaliczny z sześcioma cyframi oraz ze skalą czasu odmierzającą upływające sekundy (skala informuje przez ile sekund będzie jeszcze ważne aktualne hasło, 1 kreseczka na skali to 10s). Token jest wielkości breloczka do kluczy.

    Token przez cały czas wyświetla pseudolosowy ciąg cyfr (tzw. cardcode), który się zmienia co 60 sekund. Dan ciąg jest ważny tylko przez czas jego wyświetlania na tokenie. Ciąg cyfr jest funkcją tajnego klucza zapisanego w karcie (liczba 64-bitowa - seed value) oraz aktualnego czasu (z dokładnością do 60s). System internetowy (dokładnie serwer autoryzacji ACE/Server) potrafi ustalić poprawność ciągu cyfr wygenerowanego przez token. Zegary tokena oraz serwera są zsynchronizowane.

PROCESOROWE KARTY ELEKTRONICZNE (ISO 7816)

Karta UNIPROTECT PKI to elektroniczna stykowa karta procesowa, (smart card) o bardzo szerokim spektrum zastosowań w dziedzinie zabezpieczeń. Jest to kartą nowej generacji, którą może być bardzo szeroko stosowana. Karta ta spełnia wymagania standardów ISO 7816-1,2,3,4.

ZASTOSOWANIA

UniProtect PKI jest kartą wieloaplikacyjną i może być wykorzystywana równolegle w poniższych aplikacjach.

• Kontrola dostępu do zasobów komputerowych. 
  Karta jest nośnikiem informacji o użytkowniku, domenie jak również haseł dostępu i kluczy szyfrujących wykorzystywanych przez system PROTECT.

• Systemy dla PKI (podpis elektroniczny).
  Karta może generować i przechowywać klucze prywatne o długości 1024-bitow oraz certyfikaty w technologii PKI. Używa algorytmu RSA, i umożliwia ochronę danych poufnych na poziomie standardu ISO 7816/4, w oparciu o Infrastrukturę Klucza Publicznego (PKI) tj. uwierzytelnianie, podpis elektroniczny, szyfrowanie. Niezawodnie zabezpiecza ona integralność danych, umożliwiając używanie kryptografii PKI. 

• Umożliwia to stosowanie podpisu elektronicznego i odszyfrowywania wiadomości bez ujawniania klucza prywatnego który NIGDY nie wychodzi na zewnątrz karty.

• Poprzez generowanie, przechowywanie kluczy i certyfikatów jest również możliwość uwierzytelniania się przez karty w systemach Windows2000 i XP do Active Directory.

• Inne aplikacje zależnie od potrzeb klienta np. dostęp do kserokopiarek

PROCESOROWE KARTY DUALNE (ISO 7816 oraz ISO 14443)

Karta MultiProtect PKI to elektroniczna dualna (stykowo zbliżniowa) karta procesowa, zaprojektowana do wykorzystania jako część systemu kompleksowych rozwiązań kontroli dostępu i PKI w przedsiębiorstwach jak również w jednostkach administracji państwowej. 

ZASTOSOWANIA:

MultiProtect PKI jest kartą wieloaplikacyjną, wykorzystywaną równolegle w poniższych aplikacjach.

• Kontrola dostępu do zasobów komputerowych. 
  Karta jest nośnikiem informacji o użytkowniku, domenie jak również haseł dostępu i kluczy szyfrujących wykorzystywanych przez system PROTECT. (wykorzystana część stykowa)

• Systemy dla PKI (podpis elektroniczny).
  Karta może generować i przechowywać klucze prywatne o długości 1024-bitow oraz certyfikaty w technologii PKI. Używa algorytmu RSA, i umożliwia ochronę danych poufnych na poziomie standardu ISO 7816/4, w oparciu o Infrastrukturę Klucza Publicznego (PKI) tj. uwierzytelnianie, podpis elektroniczny, szyfrowanie. Niezawodnie zabezpiecza ona integralność danych, umożliwiając używanie kryptografii PKI. Umożliwia to stosowanie podpisu elektronicznego i odszyfrowywania wiadomości bez ujawniania klucza prywatnego który NIGDY nie wychodzi na zewnątrz karty. (część stykowa)

• Kontrola dostępu do pomieszczeń, budynków i innych. (część zbliżeniowa)
  Karta jest wyposażona również w moduł zbliżeniowy (może to być technologia Mifare(r) lub Motorola(r) zależnie od potrzeby) dzięki czemu jest wykorzystywana w kontroli dostępu do pomieszczeń, budynków, systemów kredytowych. 

• Systemy RCP (część zbliżeniowa)
  Ten sam moduł zbliżeniowy może być zastosowany w systemach RCP.

• Inne aplikacje zależnie od potrzeb klienta np. stołówka, elektroniczna portmonetka czy dostęp do kserokopiarek.
  
  

II Standardy PKI - Public Key Cryptography Standards

PKCS #1 - RSA Cryptography Standard - opisuje metodę szyfrowania danych przy użyciu algorytmu szyfrowania danych przy użyciu algorytmów RSA; jest zwykle używany w konstrukcji podpisów i kopert cyfrowych;

PKCS # 2 - nie jest kontynuowany;

PKCS # 3 - Diffie - Hellman Key Agreement Standard, opisuje implementację metody uzgodnienia klucza Diffie - Hellmana, pozwalającą na anwiązanie bezpiecznej komunikacji;

PKCS # 4 - nie jest kontynuowany, został włączony do PKCS # 1

PKCS # 5 - Password-Based Cryptography Standard, zawiera zalecenia do implementacji kryptografii, opartej na hasłach, schematy szyfrowania i schematy wiadomości uwierzytelniających;

PKCS # 6 - Extended - Certificate Syntax Standard, opisuje składnię dla rozszerzonych certyfikatów, składających się z certyfikatu i zbioru atrybutów, podpisanych razem przez wystwacę certyfikatu;

PKCS # 7 - Cryptographic Message Syntax Standard, opisuje ogólną składnię danych, do których może być stosowana kryptografia, jak podpisy i koperty cyfrowe;

PKCS # 8 - Private Key Information Syntax Standard, opisuje składnię dla informacji klucza prywatnego oraz zbiór atrybutów; ten standard opisuje także składnię dla zaszyfrowanego klucza prywatnego;

PKCS # 9 - Selected Attribute Types, definiuje wybrane typy atrybutów do użytku w standardach PKCS # 6, PKCS # 7, PKCS # 8, PKCS # 10;

PKCS # 10 - Certification Request Syntax Standard, opisuje składnię zapytania o certyfikat klucza publicznego, nazwę i możliwy zbiór atrybutów;

PKCS # 11 - Cryptographic Token Interface Standard, specyfikuje API, zwane Cryptoki, do urządzeń, które przechowują kryptograficzne informacje i wykonują kryptograficzne funkcje, zapewniając bezpieczeństwo informacji kryptograficznych. Cryptoki udostępnia aplikacjom token kryptograficzny;

PKCS # 12 - Personal Information Exchange Syntax Standard, specyfikuje przenośny format do składowania i transportowania klucza prywatnego użytkownika, certyfikatów, tajnych informacji itp.;

PKCS # 13 - Elliptic Curve Cryptography Standard, rozwijany;

PKCS # 14 Pseudorandom Number Generation Standard, jest dopiero rozwijany;

PKCS # 15 Cryptographic Token Information Format Standard, ma zapewnić, że użytkownicy będą w rzeczywistości mogli używać tokenów kryptograficznych do identyfikowania samych siebie przez wiele standardowych aplikacji, niezależnie od Cryptoki albo innego dostawców tokenów;

III Charakterystyka standardu PKCS#7

1. Wprowadznie

Standard ten opisuje ogólną składnię danych, do których może być stosowana kryptografia, jak podpisy i koperty cyfrowe. Wspiera rekurencję, dzięki czemu możliwe jest np. zamieszczanie jednej koperty cyfrowej w drugiej kopercie cyfrowej lub część koperty może być podpisana przez inną kopertę. Pozwala również przypadkowym atrybutom (np. znacznik czasu) weryfikacje razem z wiadomością (w postaci szyfrogramu) oraz wspiera inne atrybuty, które wiązane są bezpośrednio z podpisem.

PKCS#7 jest kompatybilny z Privacy-Enhanded Mail (PEM). Umożliwia to konwersję do postaci wiadomości PEM bez żadnych dodatkowych operacji kryptograficznych. Chodzi tu o konwersje typu signed-data i signed-and-enveloped data.

Standard ten może wspierać różne architektury podpisów cyfrowych, np. proponowany dla

Privacy-Enhanded Mail w RFC 1422 (S. Kent. RFC 1422: Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management. February 1993.).

Sprawy związane z samą architekturą czyli z wyborem centrum certyfikujących, rodzajem nazw akceptowalnych, polityka postępowania weryfikującego przez centrum certyfikacji (np. podpis tylko przez zabezpieczony sprzęt (np. token) czy przedstawienie specyficznych form identyfikacji) zostały wyłączone poza standard (standard tego nie definiuje).

Wartości przedstawiane za pomocą tego standardu mają postać BER-encoded czyli są to wartości w postaci ciągów ósemkowych. Standard ten nie definiuje sposobu przedstawiania ciągu ósemkowego jako znaków ASCII czy innych formatów. RFC 1421 (J. Linn. RFC 1421: Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures. February 1993.) przedstawia sposób rozwiązania tego problemu.

3. Składnia ogólna

Ogólna składnia wymiany treści pomiędzy jednostkami posługującymi się tym standardem kojarzy typ treści z treścią. Składnia powinna posiadać ContentInfo typu ASN.1 :

ContentInfo ::= SEQUENCE {
contentType ContentType,
content
[0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }

ContentType ::= OBJECT IDENTIFIER

gdzie:

contentType - wskazuje typ treści. Jest to identyfikator obiektu, który oznacza, że jest to unikalny ciąg liczb całkowitych definiujących typ treści.

content - jest to treść. Pole jest opcjonalne. Przy braku wypełnienia zamierzona wartość musi zostać podana w inny sposób.

Uwagi

1. Typ treści może zostać zdeterminowany unikalnie przez contentType więc nie powinien być ustawiony jako opcjonalny (choice type).

2. Kiedy wartość ContentInfo jest wewnętrzną wartością signed-data, signed-and-enveloped-data lub digested-data treść (pole content) powinna zostać zaszyfrowana za pomocą algorytmu DER.

3. Kiedy wartość ContentInfo jest wewnętrzną wartością enveloped-data lub signed-and-developed-data treść (pole content) powinna zostać zaszyfrowana za pomoca algorytmu BER.

4. Możliwość opcjonalnego pominięcia pola content stwarza możliwość zbudowania „zewnętrznego podpisu”. Np. bez modyfikacji treści, do której stosuje się podpis.
   W przypadku zewnętrznego podpisu, treść podpisana zostanie pominięta przez wewnętrzn zkapsulowaną wartość ContentInfo włączając w to typ treści.

4. Data content type

Data content type jest po prostu ciągiem ósemkowym. Powinien posiadać typ danych ASN.1 :

Data::= OCTET STRING

Służy do wskazywania (referencja) na przypadkowe ciągi ósemkowe (np. Pliki tekstowe ASCII ). Tego typu ciągi ósemkowe nie potrzebują wewnętrznych struktur.

5. Signed-data content type

Składa się z treści jakiegokolwiek typu i treści przetworzonej przez żadnego lub wielu składających podpis. Szyfrowanie przez osobę składającą podpis jest podpisem cyfrowym treści dla żadnego lub wielu podpisujących. Każdy typ treści może zostać podpisany przez dowolna liczbę podpisujących równolegle. Co więcej, składnia ma zdegenerowany przypadek, w którym nie ma w ogóle podpisującego treść. Prowadzi to do tworzenia list unieważniających certyfikaty.

Oczekuje się, że typowa aplikacja, w której zaimplementowano szyfrowanie danych będzie reprezentowała podpis cyfrowy jednego podpisującego na daną treść.

Proces podpisywania danych skonstruowany jest wg następujących kroków:

1. Dla każdego podpisującego szyfrowana jest treść zgodnie ze specyfikacją algorytmu szyfrującego obowiązującego podpisującego (jeżeli dwóch podpisujących korzysta z tego samego algorytmu szyfrującego to treść zostanie zaszyfrowana tylko jednym z nich). Jeżeli podpisujący chce zaszyfrować jakąś inną informację niż treść (content), korzysta on również z algorytmu szyfrującego, który obowiązuje podpisującego.

2. Dla każdego podpisującego, szyfrowanie treści lub powiązanych z nią informacji odbywa się za pomocą klucza prywatnego podpisującego.

3. Dla każdego podpisującego, zaszyfrowana treść i inne informacje przechowywane są jako wartość SignetInfo.

4. Algorytmy szyfrujące zdefiniowane dla wszystkich podpisujących oraz wartość SignerInfo dla wszystkich podpisujących są zebrane razem z treścią w SignedData.

Odbiorca weryfikuje podpisy poprzez odszyfrowanie zaszyfrowanych informacji (treści) każdego z podpisujących za pomocą klucza publicznego podpisującego. Klucz publiczny podpisującego zawarty jest w certyfikacie dołączonym wraz z informacją podpisującego lub zawiera referencje na specyficzną nazwę i numer, który jednoznacznie identyfikuje certyfikat dla klucza publicznego.

Sekcja ta podzielona jest na pięć części:

1 część opisuje typ wyższego poziomu(top-level) SignedData

2 część opisuje typ SignerInfo dla każdego podpisującego

3 i 4 część opisuje sposób (algorytm) i proces szyfrowania

5 część podsumowuje kompatybilność z Privacy-Enhanced Mail

4.1 SignedData type

Powinien posiadać typ SignedData ASN.1

SignedData ::= SEQUENCE {
version Version,
digestAlgorithms DigestAlgorithmIdentifiers,
contentInfo ContentInfo,
certificates
[0] IMPLICIT ExtendedCertificatesAndCertificates
OPTIONAL,
crls
[1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos }

DigestAlgorithmIdentifiers ::=
SET OF DigestAlgorithmIdentifier

SignerInfos ::= SET OF SignerInfo

Gdzie:

version - jest składnią numeru wersji. Powinien być 1 dla tej wersji standardu.

digestAlgorithms - jest zbiorem identyfikatorów algorytmu przetwarzania. Może zawierać każdy numer zbioru łącznie z zerem. Każdy element identyfikuje algorytm przetwarzania (oraz inne powiązane parametry) dla konkretnego podpisującego.

contentInfo - podpisywana treść. Może posiadać dowolny zdefiniowany typ treści.

certyficates - jest zbiorem certyfikatów określonych w PKCS#6 i X.509. W razie konieczności dopuszczalne są inne certyfikaty.

crls - zbiór list unieważniających certyfikaty (certificate-revocation lists). Sprawdza czy certyfikat podany w polu certyficates znajduje sie na liście (tzw. hot listed) ale nie jest to wymogiem

SignerInfos - zbiór informacji każdego z podpisujących. Może być dowolna liczba elementów łącznie z zerem.

Uwagi:

1. Fakt, że pole digestAlgorithms field występuje przed polem contentInfo a pole signerInfos występuje po nich stwarza możliwość wygenerowania SignedData w tzw. single-pass processing.

2. Różnice między wersją 1 a 0 SignedData (zdefiniowane w PKCS#7) są następujące:

• digestAlgorithms i signerInfors mogą przyjmować wartość zero w wersji 1 ale nie we wersji 0

• crls występuje w wersji 1 ale nie w 0

W szczególnym przypadku, gdy nie ma podpisującego, podpisana wartość ContentInfo staje się nieistotna.

1. SignerInfo type

Informacje o każdym podpisującym są reprezentowane właśnie w SignerInfo:

SignerInfo ::= SEQUENCE {
version Version,
issuerAndSerialNumber IssuerAndSerialNumber,
digestAlgorithm DigestAlgorithmIdentifier,
authenticatedAttributes
[0] IMPLICIT Attributes OPTIONAL,
digestEncryptionAlgorithm
DigestEncryptionAlgorithmIdentifier,
encryptedDigest EncryptedDigest,
unauthenticatedAttributes
[1] IMPLICIT Attributes OPTIONAL }

EncryptedDigest ::= OCTET STRING

Gdzie:

version - jest składnią numeru wersji. Dla wersji pierwszej (czyli dla tej wersji) będzie to wartość 1.

digestAlgorithms - jest zbiorem identyfikatorów algorytmu przetwarzania. Może zawierać każdy numer zbioru łącznie z zerem. Każdy element identyfikuje algorytm przetwarzania (oraz inne powiązane parametry) dla konkretnego podpisującego.

authenticatedAttributes - zbiór atrybutów, które zostały podpisane przez podpisującego. Jest to pole opcjonalne ale musi być ustawione gdy typem podpisywanej treści (content type) nie maja być dane (data). Gdy pole jest ustawione musi zawierać co najmniej dwa atrybuty:

• atrybut PKCS#9 content-type określający typ podpisanego ContentInfo

• atrybut PKCS#9 message-digest określający przetwarzaną treść

• inne przydatne atrybuty (np. tzw. znacznik czasu) opisane są również w PKCS#9

digestEncrypionAlgorithm - idnetyfikuje algorytm szyfrowania (i każdy skojarzony parametr), za pomocą którego informacja zostanie zaszyfrowana przy użyciu klucza prywatnego podpisującego

encryptedDigest - resultat procesu szyfrowania za pomocą klucza prywatnego podpisującego

unauthenticatedAttributes - zbiór atrybutów, które nie zostały podpisane przez podpisującego. Pole jest opcjonalne.

Uwagi:

1. Zalecane jest pominięcie pola authenticatedAttributes w celu zachowania kompatybilności z PEM

2. Różnica między wersją 1 a 0 SignerInfo (zdefiniowanej w PKCS#7) znajduje się w procesie szyfrowania informacji.

2. Message-digesting process

Określa proces przetwarzania informacji. Danymi wejściowymi do procesu przetwarzania stają się wartość treści podpisanej. Szczególnym impulsem jest treść złożona z ciągu ósemkowego kodowanego za pomocą algorytmu DER jako pole content w ContentInfo dla którego wysunięto żądanie podpisania. Tylko zawartość ciągu ósemkowego zostaje przetworzona - nie ich identyfikator czy długość.

3. Digest-encryption process

Parametrem wejściowym jest wartość przypisana do digestEncryptionAlgorithm podpisującego zawierająca wynik procesu przetwarzania (message-digesting process) i identyfikator algorytmu przetwarzającego lub identyfikator obiektu. Wynikiem procesu szyfrowania jest szyfrogram z kluczem prywatnym podpisującego.

DigestInfo ::= SEQUENCE {
digestAlgorithm DigestAlgorithmIdentifier,
digest Digest }

Digest ::= OCTET STRING

Gdzie:

DigestAlgorithm - identyfikuje algorytm przetwarzania (i każdy powiązany parametr) za pomocą którego treść(content) i atrybuty autentykacji są przetwarzane. Powinien być taki sam jak w polu DigestAlgorithm w SignerInfo.

Digest - rezultat procesu przetwarzania

Uwagi:

1. Jedyna różnicą pomiędzy podpisem zdefiniowany tutaj a algorytmami podpisów zdefiniowanych w PKCS#1 jest to, że tam podpisy reprezentowane są przez ciągi bitów (X.509 SIGNED) a tutaj przez ciągi ósemkowe.

2. Dane wejściowe procesu szyfrowania przeważnie będą zawierały 30 lub więcej ciągów ósemkowych. Jeżeli wykorzystałoby się algorytm rsaEncryption z PKCS#1 oznaczałoby to że dane wejściowe można zaszyfrować pojedynczym blokiem dopóki długość modułów RSA nie będzie miała 328 bitów co jest rozsądne i konsekwentne z zaleceniami bezpieczeństwa

3. Identyfikator algorytmu przetwarzającego dołączony jest do DigestInfo w celu określenia limitu strat podczas kompromisu przy wyborze jednego algorytmu przetwarzającego.

2. Compatibility with Privacy-Enhanced Mail

Kompatybilność z typami procesów MIC-ONLY I MIC-CLEAR w PEM występuje gdy typ podpisanej treści w ContentInfo jest „data”, nie ma atrybutów autentykacji, algorytmami przetwarzania są md2 lub md5 i algorytmem szyfrującym jest rsaEncyption (zdefiniowany w PKCS#1).

Pozostałe części signed-data content type (certificates, CRLs, algorithm identifiers, etc.) są łatwo konwertowane tak, by mogły korespondować z komponentami PEM.

5. Enveloped-data content type

Enveloped-data content type składa się z zaszyfrowanej treści dowolnego typu i zaszyfrowanej treści - zaszyfrowanych kluczy dla jednego lub wielu odbiorców. Kombinacja zaszyfrowanej treści - zaszyfrowanych kluczy jest dla odbiorcy „cyfrową (elektroniczną) kopertą” (digital envelope). Każdy typ treści może zostać „włożony do koperty” dowolną ilość razy równocześnie.

Proces tworzenia cyfrowej koperty wymaga następujących kroków:

1. Klucz szyfrujący treść dla konkretnego algorytmu szyfrującego jest generowany przypadkowo (random)

2. Dla każdego odbiorcy klucz szyfrujący treść jest zaszyfrowany kluczem publicznym danego odbiorcy.

3. Dla każdego odbiorcy zaszyfrowana treść - zaszyfrowany klucz przechowywane są w RecipienInfo.

4. Treść szyfrowana jest kluczem szyfrującym treść (content-encryption key).

5. RecipientInfo jest przechowywana wspólnie z treścią zaszyfrowaną dla każdego odbiorcy w EnwelopedData

1. EnvelopedData type

EnvelopedData type powinien posiadać typ EnvelopedData ASN.1 :

EnvelopedData ::= SEQUENCE {
version Version,
recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo }

RecipientInfos ::= SET OF RecipientInfo

EncryptedContentInfo ::= SEQUENCE {
contentType ContentType,
contentEncryptionAlgorithm
ContentEncryptionAlgorithmIdentifier,
encryptedContent
[0] IMPLICIT EncryptedContent OPTIONAL }

EncryptedContent ::= OCTET STRING

Gdzie:

version - składnia numeru wersji. W tej wersji standardu powinno być 0.

recipientInfo - zbiór informacji o każdym odbiorcy. Co najmniej jeden element z zbiorze.

encryptedContentInfo - informacje o zaszyfrowanej treści

2. RecipientInfo type

Informacje o każdym odbiorcy reprezentowane są w RecipientInfo:

RecipientInfo ::= SEQUENCE {
version Version,
issuerAndSerialNumber IssuerAndSerialNumber,
keyEncryptionAlgorithm
KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }

EncryptedKey ::= OCTET STRING

Gdzie :

Version - składnia numery wersji. Powinna być 0 dla tej wersji standardu.

IssuerAndSerialNumber - określa certyfikat odbiorcy za pomocą nadanej, unikalnej nazwy i unikalnego numeru.

KeyEncryptionAlgorithm - określa algorytm szyfrujący klucze, za pomocą którego klucz szyfrowany jest kluczem publicznym odbiorcy.

EncryptedKey - wynik szyfrowania treści kluczem publicznym odbiorcy.

3. Content-encryption process

Parametrem wejściowmy do procesu szyfrowania treści jest wartość treści, która została umieszczona w kopercie cyfrowej. Gdy treść(content) zostaje umieszczona w kopercie cyfrowej, posiada typ „data” , wtedy tylko wartość jest szyfrowana. Ma to tą zaletę, że długość treści, która jest szyfrowana nie musi być znana w procesie szyfrowania.

4. Key-encryption process

Parametrem wejściowym do tego procesu jest wartośc klucza, za pomocą którego szyfruje się treść(content).

6. Signed-and-enveloped-data content type

Składa się z zaszyfrowanej treści (content) dowolnego typu, zaszyfrowanej treści - zaszyfrowanych kluczy dla jednego lub wielu odbiorców i podwójnego szyfrowania dla jednego lub wielu podpisujących. Podwójne szyfrowanie składa się z szyfrowania kluczem prywatnym podpisującego i kluczem szyfrującym treść.

Proces konstruujący signed-and-enveloped data wymaga następujących kroków:

1. Klucz szyfrujący treść jest generowany przypadkowo (random).

2. Dla każdego odbiorcy, klucz szyfrujący treść jest szyfrowany jego kluczem publicznym.

3. Dla każdego odbiorcy, zaszyfrowana treść - zaszyfrowany klucz są przechowywane w RecipientInfo

4. Dla każdego podpisującego przetworzenie treści odbywa się za pomocą algorytmu przetwarzania podpisującego.

5. Dla każdego podpisującego, przetwarzanie jest szyfrowane za pomocą klucza prywatnego podpisującego a wynik jest szyfrowany kluczem szyfrowania treści.

6. Dla każdego podpisującego podwójne szyfrowanie i inne specyficzne informacje odbiorcy przechowywane są w SignerInfo

7. Treść jest szyfrowana za pomocą klucza szyfrującego treść (content-encryption key)

8. Algorytmy przetwarzania, wartości SignerInfo wszystkich podpisujących oraz wartości RecipientInfo wszystkich odbiorcó są przechowywane razem z zaszyfrowana treścia w SignedAndEnvelopedData.

Odbiorca otwiera kopertę i weryfikuje podpis w dwóch krokach :

1. Odszyfrowując zaszyfrowana treść - zaszyfrowane klucze za pomocą swojego klucza prywatnego otrzymuje klucz szyfrujący treść i za pomocą odszyfrowanego klucza odszyfrowuje treść(content).

2. Odszyfrowanym kluczem szyfrującym treść odszyfrowuje podwójnie zaszyfrowane przetworzenie a rezultat odszyfrowuje swoim kluczem prywatnym, a następnie porównuje odszyfrowane przetworzenie do niezależnego w celu uwierzytelnienia zgodności.

1. SignedAndEnvelopedData type

Signed-and-enveloped-data content type powinien byćtypu ASN.1 :

SignedAndEnvelopedData:

SignedAndEnvelopedData ::= SEQUENCE {
version Version,
recipientInfos RecipientInfos,
digestAlgorithms DigestAlgorithmIdentifiers,
encryptedContentInfo EncryptedContentInfo,
certificates
[0] IMPLICIT ExtendedCertificatesAndCertificates OPTIONAL,
crls
[1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos }

Gdzie:

Version - składnia numeru wersji. Powinna być 1 dla tej wersji tego standardu.

RecipientInfos - zbiór informacji o każdym odbiorcy. Musi być co najmniej jeden element zbioru.

DigestAlgorithms - zbiór identyfikatorów algorytmów przetwarzania.

EncryptedContentInfo - zaszyfrowana treść (content). Może mieć dowolny, zdefiniowany typ

Certificates - zbiór certyfikatów PKCS#6 i X.509

Crls - zbiór list unieważniających certyfikaty (certificate-revocation lists). Sprawdza czy certyfikat podany w polu certyficates znajduje sie na liście (tzw. hot listed) ale nie jest to wymogiem

SignerInfos - zbiór informacji każdego z podpisujących. Może być dowolna liczba elementów łącznie z zerem.

2. Digest-encryption process

Proces ten wymaga dwóch kroków :

1. Parametrem wejściowym jest algorytm szyfrujący podpisującego.

2. Wynik pierwszego kroku jest szyfrowany za pomocą klucza szyfrującego treść (content)

Pomiędzy tymi dwoma krokami nie ma kodowania DER. Parametr wyjsciowy (wynik) kroku1 jest bezpośrednim parametrem wejściowym kroku2.

Proces ten jest kompatybilny z zaszyfrowanym procesem w Privacy-Enhanded Mail (PEM).

7. Digested-data content type

Składa się z treści dowolnego typu i przetworzenia tej treści.

Proces wymaga następujących kroków :

1. Przetworzenie treści za pomocą algorytmu przetwarzania.

2. Algorytm przetwarzania i samo przetwarzanie są zlokalizowane razem z treścią w DigestedData.

Odbiorca weryfikuje przetworzenie poprzez porównanie odebranego przetworzenia z niezależnym.

Digested-data content type powinno być typu DigestedData ASN.1 :

DigestedData ::= SEQUENCE {
version Version,
digestAlgorithm DigestAlgorithmIdentifier,
contentInfo ContentInfo,
digest Digest }

Digest ::= OCTET STRING

Gdzie :

Version - składnia numeru wersji. Powinna być 1 dla tej wersji tego standardu.

DigestAlgorithms - zbiór identyfikatorów algorytmów przetwarzania.

ContentInfo - treść, która została przetworzona. Może mieć dowolny, zdefiniowany typ.

Digest - rezultat procesu przetwarzania

8. Encrypted-data content type

Składa się z zaszyfrowanej treści dowolnego typu. W przeciwieństwie do enveloped-data content type nie posiada ani odbiorców, ani zaszyfrowana treść - zaszyfrowane klucze (encrypted content-encryption keys). Klucze są przydzielane.

Oczekuje się od typowej aplikacji, w której zaimplementowano encrypted-data content type, że będzie szyfrowała data content type do lokalnej pamięci, być może gdy klucz szyfrujący jest hasłem.

Encrypted-data content type powinno zawierać typ EncryptedData ASN.1 :

EncryptedData ::= SEQUENCE {
version Version,
encryptedContentInfo EncryptedContentInfo }

Gdzie :

Version - składnia numeru wersji. Powinna być 0 dla tej wersji standardu.

EncryptedContentInfo - informacja o zaszyfrowanej treści.

9. Object identifiers

Standard ten definiuje 7 identyfikatorów obiektów :

1. PKCS#7

OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) US(840) rsadsi(113549)
pkcs(1) 7 }

2. data

OBJECT IDENTIFIER ::= { pkcs-7 1 }

3. signedData

OBJECT IDENTIFIER ::= { pkcs-7 2 }

4. envelopedData

OBJECT IDENTIFIER ::= { pkcs-7 3 }

5. signedAndEnvelopedData

OBJECT IDENTIFIER ::= { pkcs-7 4 }

6. digestedData

OBJECT IDENTIFIER ::= { pkcs-7 5 }

7. encrypteData

OBJECT IDENTIFIER ::= { pkcs-7 6 }

Identyfikatory tych obiektów, w założeniu, mają służyć jako wartość pola contentType w ContentInfo.

Pola treści (content), które mają składnie zdefiniowaną przez jeden z typów treści, będą miały typ ASN.1 odpowiednio Data, SignedData, EnvelopedData, SignedAndEnvelopedData, DigestedData, and EncryptedData .

---