Rozproszony system dostępu do informacji wraŜliwych

Transkrypt

Politechnika Łódzka
Instytut Informatyki
PRACA DYPLOMOWA MAGISTERSKA
Rozproszony system dostępu do informacji
wraŜliwych
Wydział Fizyki Technicznej, Informatyki i Matematyki Stosowanej
Promotor: dr Michał Morawski
Dyplomant: Tomasz Witkowski
Nr albumu: 127350
Kierunek: Informatyka
Specjalność: Sieci Komputerowe i Systemy Teleinformatyczne
Łódź 14.09.2009
Instytut Informatyki
90-924 Łódź, ul. Wólczańska 215, budynek B9
tel. 042 631 27 97, 042 632 97 57, fax 042 630 34 14 email: [email protected]
Spis treści
Wykaz skrótów i akronimów ................................................................................ 5
1
Wstęp ........................................................................................................... 6
2
Cel i zakres pracy ........................................................................................ 7
3
Infrastruktura klucza publicznego ................................................................. 7
3.1
4
Certyfikaty X.509 ........................................................................................ 10
4.1
Struktura i opis pól .............................................................................. 11
4.2
Rozszerzenia ...................................................................................... 15
4.2.1
UŜycie klucza (ang. Key usage) ................................................... 15
4.2.2
Polityki certyfikacji (ang. Certificate Policies) ................................ 16
4.2.3
Alternatywna nazwa posiadacza (ang. Subject alternative name) 16
4.2.4
Podstawowe ograniczenia (ang. Basic constraints)...................... 17
4.2.5
Ograniczenia nazw (ang. Name constraints) ................................ 17
4.2.6
Rozszerzone uŜycie klucza (ang. Extended key usage)............... 18
4.3
Odwoływanie certyfikatów ................................................................... 18
4.4
Weryfikacja certyfikatu ........................................................................ 19
4.4.1
Zawartość ..................................................................................... 19
4.4.2
ŚcieŜka certyfikacji ....................................................................... 20
4.5
5
Kryptografia klucza publicznego ......................................................... 10
Podsumowanie ................................................................................... 20
Certyfikaty Atrybutowe ................................................................................ 21
5.1
Struktura i opis pól .............................................................................. 22
5.2
Atrybuty i ich typy ................................................................................ 25
5.2.1
Informacje
uwierzytelniające
(ang.
Service
Authentication
Information) ............................................................................................... 26
5.2.2
ToŜsamość (ang. Access Identity) ................................................ 27
5.2.3
Podmiot odpowiedzialny (ang. Charging Identity)......................... 27
str. 2
5.2.4
Grupa - (ang. Group) .................................................................... 27
5.2.5
Rola (ang. Role) ........................................................................... 27
5.2.6
Poziom Dostępu (ang. Clearance)................................................ 28
5.3
Rozszerzenia ...................................................................................... 28
5.3.1
ToŜsamość audytowa (ang. Audit Identity) ................................... 29
5.3.2
Odbiorcy certyfikatu (ang. AC Targeting) ..................................... 29
5.3.3
Identyfikator klucza autoryzacyjnego (ang. Authority Key Identifier)
..................................................................................................... 29
5.3.4
Dostęp do danych wydawcy (ang. Authority Information Access) i
miejsca dystrybucji list CRL (ang. CRL Distribution Points) ....................... 30
5.3.5
5.4
Szyfrowanie atrybutów ........................................................................ 30
5.5
Weryfikacja certyfikatu ........................................................................ 31
5.6
Odwoływanie ....................................................................................... 32
5.6.1
Brak odwołań (ang. Never revoke) ............................................... 32
5.6.2
Wskaźnik na CRL w certyfikacie (ang. Pointer at AC) .................. 32
5.7
6
Brak informacji o odwołaniach (ang. No Revocation Available).... 30
Podsumowanie ................................................................................... 32
Przechowywanie kluczy. ............................................................................. 34
6.1
Depozyty kluczy .................................................................................. 34
6.2
Podział klucza ..................................................................................... 35
6.3
Schematy podziału sekretu ................................................................. 35
6.4
Schemat , .................................................................................... 35
6.5
Shamir’s secret sharing scheme ......................................................... 36
6.6
Zarządzanie fragmentami ................................................................... 38
6.6.1
Weryfikowalny podział sekretu ..................................................... 38
6.6.2
Verifiable Secret Sharing (VVS) ................................................... 39
6.6.3
Nieinteraktywna metoda weryfikacji fragmentów .......................... 41
6.6.4
Proaktywne metody zarządzania fragmentami ............................. 42
str. 3
6.6.5
Odnawianie fragmentów ............................................................... 43
6.6.6
Sprawdzanie fragmentów ............................................................. 43
6.6.7
Rekonstrukcja zniszczonych/ujawnionych fragmentów ................ 44
6.7
7
Opis systemu .............................................................................................. 46
7.1
ZałoŜenia projektu ............................................................................... 46
7.2
Narzędzia i technologie ....................................................................... 46
7.2.1
Technologie .................................................................................. 47
7.2.2
Narzędzia ..................................................................................... 48
7.3
Wymagania sprzętowe ........................................................................ 50
7.4
Opis implementacji .............................................................................. 50
7.4.1
Konfiguracja wstępna ................................................................... 53
7.4.2
Struktura bazy .............................................................................. 56
7.5
8
Podsumowanie ................................................................................... 45
Testy ................................................................................................... 59
Wnioski ....................................................................................................... 61
Wykaz rysunków ............................................................................................... 63
Bibliografia ........................................................................................................ 63
str. 4
Wykaz skrótów i akronimów
AA (Attribute authority) Podmiot wydający certyfikat atrybutowy.
AC (Attribute Certificate) Certyfikat atrybutowy jest dokumentem elektronicznym
pozwalającym na powiązanie między uŜytkownikiem a przyznanymi mu przez
AA prawami.
ASN.1 (Abstract Syntax Notation One) Notacja wykorzystywana do opisu
struktur danych wykorzystywana w telekomunikacji i sieciach komputerowych
CRL (Certificate revocation list) Lista odwołań certyfikatów to struktura danych
zawierająca listy numerów seryjnych certyfikatów, które zostały odwołane.
CSS (Cascading Style Sheets) zestaw znaczników pozwalających na
formatowanie wyglądu stron internetowych
ASN.1 DER (Distinguished Encoding Rules) Format opisujący strukturę na
podstawie wzorca znacznik – długość – wartość.
DN (Distinguished name) – unikalna nazwa. Jest to wpis uŜywany w serwerach
LDAP oraz certyfikatach X.509 pozwalający jednoznacznie zidentyfikować
zasób lub podmiot. Przykład dn: cn=Tomasz Witkowski,dc=2imagine,dc=pl
DNS (Domain name system) system serwerów oraz protokół pozwalający na
translację nazw kanonicznych na adresy IP.
Homomorfizm – definicja
HTML (HyperText Markup Language) język wykorzystywany do tworzenia stron
WWW
OID (Object Identifier) unikalny ciąg znaków identyfikujący obiekt danego typu.
PEM (Privacy Enhanced Mail) format wykorzystywany do przechowywania
certyfikatów X.509
PKC (Public Key Certificate) Document elektroniczny pozwalający na
powiązanie danych podmiotu z uŜywanym przez niego kluczem publicznym
str. 5
1 Wstęp
Rosnący nacisk ze strony instytucji takich jak Unia Europejska, propagujących
zachowania proekologiczne przyczynia się do szukania i wykorzystywania
sposobów, które umoŜliwią zmniejszenie zuŜycia papieru. Widoczny jest
ogólnoświatowy trend mający na celu zastąpienie tradycyjnych dokumentów
wykorzystywanych
w
administracji
publicznej
ich
elektronicznymi
odpowiednikami. Zmiany legislacyjne przeprowadzane w Polsce mają za
zadanie w coraz większym stopniu umoŜliwiać wykorzystanie kwalifikowanego
podpisu
elektronicznego
oraz
certyfikatów
klucza
publicznego
do
elektronicznego kontaktu z urzędami. Przykładem takiej zmiany jest poprawka
przyjęta przez Senat, która umoŜliwi od 1 października 2009 składanie
protestów oraz odwołań z wykorzystaniem e-podpisu [1]. Zastąpienie
tradycyjnych dokumentów elektronicznymi, poza ekologicznym ma równieŜ
wymiar finansowy i praktyczny - nakłady na archiwizację i przechowywanie
dokumentów mogą być znacznie niŜsze, a wyszukiwanie i dostęp do tak
składowanych danych łatwiejszy.
W dzisiejszym świecie konieczność szyfrowania lub podpisywania przesyłanych
danych
stała
się
codziennością.
Podczas
wykorzystywania
technologii
kryptograficznych bardzo często napotykany jest problem przechowywania
kluczy. MoŜliwość przechowywania ich we fragmentach w rozproszonych
lokalizacjach
pozwala
na
znaczne
zwiększenie
ich
bezpieczeństwa
i
dostępności. Schematy podziału , stają się niezwykle waŜnym narzędziem
archiwizacji i ochrony danych wraŜliwych.
Specyfika systemów takich jak systemy zarządza danymi w słuŜbie zdrowia,
korzystających z infrastruktury PKI, często opierają zakresy uprawnień nie o
toŜsamość danego uŜytkownika, lecz o jego przynaleŜność do pewnej grupy
bądź inne specyficzne cechy. Zastosowanie certyfikatów atrybutowych pozwala
na stworzenie wygodnego mechanizmu zarządzania przywilejami uŜytkownika
bez konieczności ingerencji w dane zawarte w jego certyfikacie PKC. Wraz z
rosnącą liczbą takich systemów odkrywane są coraz to nowe zastosowania tej
technologii.
str. 6
2 Cel i zakres pracy
Celem
pracy
jest
omówienie
zagadnień
związanych
z
certyfikatami
atrybutowymi X.509 – ich strukturą oraz zastosowaniami. Kolejnym z zagadnień
jest przedstawieniem metod bezpiecznego przechowywania kluczy prywatnych
przy uŜyciu schematów podziału, takich jak schemat Shamira. Część
praktyczna ma na celu stworzenie systemu zarządzania uprawnieniami
pracowników
pewnej
firmy,
w
oparciu
o
wykorzystanie
certyfikatów
atrybutowych.
Praca składa się z trzech części, z czego pierwsza – teoretyczna przedstawiona
została w rozdziałach do 3 do 6. Opis części praktycznej, został zamieszczony
w rozdziale 7, natomiast wnioski w rozdziale 8.
Zakres pracy obejmuje omówienie dwóch głównych zagadnień teoretycznych,
części praktyczniej oraz wniosków. Pierwsze z zagadnień dotyczy infrastruktury
klucza publicznego, ze zwróceniem szczególnej uwagi na przedstawienie
moŜliwości oferowanych przez certyfikaty klucza publicznego oraz certyfikaty
atrybutowe. Drugie z nich przedstawia polityki przechowywania danych
prywatnych, takie jak depozyty kluczy czy wykorzystanie schematów podziału
do przechowywania informacji niejawnej w rozproszeniu. W części praktycznej
przedstawiony zostanie projekt oraz opis implementacji systemu pozwalającego
na zarządzanie przywilejami pracowników firmy.
3 Infrastruktura klucza publicznego
Infrastruktura klucza publicznego PKI (ang. Public Key Infrastructure) jest
zestawem
procedur,
mechanizmów,
dokumentów
i
ról
uŜytkowników
pozwalających, w oparciu o kryptografie klucza publicznego PKC (ang. Public
Key Cryptography), na takie operacje jak: tworzenie cyfrowych podpisów
dokumentów, szyfrowanie danych, wydawanie certyfikatów oraz szeroko pojęte
zarządzanie nimi. Zawarty w pracy [2] przykład w bardzo przystępny sposób
obrazuje infrastrukturę PKI, porównując ją do sieci energetycznej. „Elektrownie,
linie przesyłowe wysokiego, średniego oraz niskiego napięcia oraz inne
str. 7
urządzenia składają się na całość infrastruktury energetycznej. Pozwala ona
odbiorcy w prosty sposób podłączyć urządzenie elektryczne, które korzystając z
energii dostarczonej przez sieć, będzie mogło wykonać określone zadanie.
Oznacza to, Ŝe infrastruktura udostępnia usługi, do których odbiorca moŜe
uzyskać dostęp i wykorzystać je we własnym celu.”
W przypadku PKI podstawowymi elementami – rolami wchodzącymi w skład
infrastruktury są:
•
Urząd rejestracji (RA) – jego zadaniem jest potwierdzenie autentyczności
danych jakie podaje podmiot ubiegający się o certyfikat.
•
Urząd certyfikacji (CA) – jest odpowiedzialny za wydawanie oraz
odwoływanie certyfikatów
•
Posiadacz certyfikatu – składa wniosek do RA, po wydaniu certyfikatu
moŜe go uŜywać do szyfrowania danych oraz podpisu cyfrowego
•
Podmiot weryfikujący certyfikat – jego zadaniem jest weryfikacja
poprawności certyfikatu
•
Repozytoria – słuŜą do publicznego przechowywania PKC oraz list
odwołań certyfikatów CRL (ang. Certificate Revocation List)
Poza elementami wymienionymi powyŜej, PKI opiera się takŜe na wyborze
pewnej liczby głównych urzędów certyfikacji (ang. Root CA), co do których
panuje powszechne przekonanie o ich uczciwości. Następnie urzędy te przy
pomocy własnych certyfikatów mogą wydawać certyfikaty niŜszego poziomu. W
ten sposób powstaje hierarchia certyfikatów.
str. 8
Rysunek 1 Przykład hierarchii certyfikatów
W protokole TCP/IP, z którego korzysta w dzisiejszych czasach znaczna
większość
uŜytkowników,
nie
zostały
zaimplementowane
mechanizmy
zabezpieczające przesyłane dane. Wykorzystanie moŜliwości oferowanych
przez
infrastrukturę
pozwala
na
uzyskania
bezpiecznych
metod
przechowywania oraz przesyłania danych przez publicznie dostępne sieci
komputerowe takie jak Internet.
Poufność
danych
zapewniona
jest
poprzez
szyfrowanie
wiadomości
wykorzystujące klucz publiczny odbiorcy – tylko on przy wykorzystaniu swojego
klucza prywatnego będzie w stanie otrzymane informacje odszyfrować.
Ochrona przed zagroŜeniem podmiany danych w trakcie przesyłania przez sieć
jest uzyskiwana poprzez wykorzystanie podpisu cyfrowego. Nadawca, przy
pomocy własnego klucza prywatnego, koduje tzw. skrót wiadomości ( ang.
str. 9
Message Digest lub hash), a następnie przesyła dane wraz ze skrótem do
odbiorcy. Ten po otrzymaniu wiadomości moŜe sprawdzić jej integralność,
samodzielnie tworząc jej skrót i porównując go z odkodowanym, przy
wykorzystaniu klucza publicznego nadawcy, skrótem, który otrzymał.
Niezaprzeczalność nadawcy wiadomości moŜe zostać potwierdzona poprzez
wykorzystanie certyfikatu klucza publicznego oraz opisanego powyŜej,
mechanizmu tworzenia podpisu cyfrowego.
3.1 Kryptografia klucza publicznego
PKC (ang. Public Key Cryptography) będące podstawą PKI, jest podejściem
kryptograficznym opartym na wykorzystywaniu pary kluczy – jeden z nich słuŜy
do szyfrowania, drugi do deszyfrowania. Rodzina algorytmów realizująca to
podejście korzysta z funkcji jednokierunkowych. Zaletą tych funkcji jest fakt, iŜ
w łatwy sposób moŜna uzyskać wartości funkcji - istnieje algorytm
wielomianowy, który ją oblicza, a bardzo kłopotliwe jest znalezienie jej
przeciwobrazu – Ŝaden wielomianowy algorytm probabilistyczny nie potrafi
odnaleźć
tego
elementu
w
prawdopodobieństwem
większym
niŜ
zaniedbywalne. Funkcję nazywamy zaniedbywalną gdy jej wartości dąŜą do
zera szybciej niŜ dla jakiegokolwiek wielomianu [3].
Więcej informacji na temat systemów kryptograficznych wykorzystujących
klucze publiczne moŜna znaleźć w pracach: [4], [5], [6], [7].
4 Certyfikaty X.509
Certyfikatem klucza publicznego PKC (ang. Public Key Certificate) nazywamy
zawarte w cyfrowo podpisanej strukturze, powiązanie pomiędzy toŜsamością
podmiotu z jego kluczem publicznym. Struktura podpisywana jest, po uprzedniej
weryfikacji danych podmiotu, przez centrum certyfikacji. W Polsce rolę
głównego CA pełni, prowadzony przez departament ochrony Narodowego
Banku Polskiego, Narodowe Centrum Certyfikacji.
str. 10
Standard X.509 do identyfikacji obiektów tego samego typu, takich jak na
przykład rodzaj atrybutu czy rozszerzenia, wykorzystuje identyfikatory OID (ang.
Object Identifier). OID jest unikalnym ciągiem
ci
znaków, w zaleŜności
zaleŜno
od przyjętej
notacji, złoŜonym ze znaków alfanumerycznych lub cyfr oraz kropek,
identyfikującym
dany
typ
obiektu
obiektu.
ZałoŜeniem
eniem
tego
mechanizmu
jest
dostarczenie globalnie unikalnych wartości dla kaŜdego
dego typu
typ
obiektu.
Identyfikatory są zorganizowane w strukturę
stru
drzewiastą,
ą, pozwalającą
pozwalaj
na
tworzenie podtypów poszczególnych gałęzi.
gał zi. Taka hierarchia pozwala na
logiczne usystematyzowanie zawartości
zawarto
drzewa.
Szczegółowy opis składni identyfikatorów OID moŜna
mo
znaleźć w [8].
Aktualne rekomendacje zalecają
zalecaj uŜycie certyfikatów PKC wersji 3.
3 Opis struktur
zawarty w poniŜszym
szym rozdziale został przygotowany w oparciu o dokumentację
dokumentacj
dotyczącą właśnie
nie tej wersji.
4.1 Struktura i opis pól
Pola w certyfikacie
ikacie zapisywane są
s w formacie ASN.1 DER [9]
Rysunek 2 Certyfikat klucza publicznego X.509 [10]
str. 11
Certificate ::= SEQUENCE {
tbsCertificate
TBSCertificate,
signatureAlgorithm
AlgorithmIdentifier,
signatureValue
BIT STRING }
TBSCertificate ::= SEQUENCE {
version
[0] EXPLICIT Version DEFAULT v1,
serialNumber
CertificateSerialNumber,
signature
issuer
Name,
validity
Validity,
subject
Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
extensions
[3] EXPLICIT Extensions OPTIONAL
-- If present, version MUST be v3
}
Algorytm podpisu (ang. Signature Algorithm) – zawiera identyfikator
algorytmu uŜytego przez CA do wygenerowania podpisu certyfikatu.
AlgorithmIdentifier
algorithm
parameters
::=
SEQUENCE {
OBJECT IDENTIFIER,
ANY DEFINED BY algorithm OPTIONAL
}
Zawartość Podpis (ang. Signature Value) – Zawiera podpis cyfrowy wydawcy
certyfikatu, obliczony dla struktury TBSCertificate
Wersja (ang. Version) – zawiera wartość liczbową reprezentującą wersje
certyfikatu klucza publicznego.
Version
::=
INTEGER
{
v1(0), v2(1), v3(2)
}
Numer Seryjny (ang. Serial number) – Wartość liczbowa, unikalna dla
kaŜdego certyfikatu podpisywanego przez tego samego wydawcę. Wartość
tego pola w połączeniu z informacjami zawartymi w polu DN (distinguished
name) pozwala na jednoznaczną identyfikację certyfikatu.
CertificateSerialNumber
::=
INTEGER
str. 12
Podpis (ang. Signature) – Pole to musi zawierać tę samą wartość, co pole
Signature Algorithm.
Wydawca (ang. Issuer) – zawiera informacje pozwalające na zidentyfikowanie
wydawcy certyfikatu. Struktura ta zawiera zestaw atrybutów zawierających
informacje o podmiocie, takich jak: Kraj (ang. country), Nazwa organizacji (ang.
organization), Jednostka organizacyjna (ang. organizational unit), kwalifikator
nazwy (ang. distinguished name qualifier), stan (ang. state), nazwa prowincji
(ang. province name), nazwa potoczna (ang. common name), numer seryjny
(ang. serial number). [11] zaleca równieŜ, aby systemy komputerowe
implementujące obsługę certyfikatów były w stanie obsłuŜyć dodatkowe
atrybuty: społeczność (ang. locality), tytuł (ang. title), nazwisko (ang. surname),
inicjały (ang. initials), pseudonim (ang. pseudonym), pokolenie (ang. generation
qualifier)
Name ::= CHOICE { -- only one possibility for now -rdnSequence RDNSequence }
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::=
SET SIZE (1..MAX) OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type
AttributeType,
value
AttributeValue }
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY -- DEFINED BY AttributeType
DirectoryString ::= CHOICE {
teletexString
printableString
universalString
utf8String
bmpString
TeletexString (SIZE (1..MAX)),
PrintableString (SIZE (1..MAX)),
UniversalString (SIZE (1..MAX)),
UTF8String (SIZE (1..MAX)),
BMPString (SIZE (1..MAX)) }
Termin waŜności (ang. Validity Period) – okres waŜności certyfikatu. Jest to
okres, w którym CA gwarantuje, Ŝe będzie utrzymywał informacje na temat
statusu danego certyfikatu [11]. Struktura przechowywana w tym polu składa
się z dwóch podstruktur zawierających daty, notBefore oraz notAfter,
str. 13
oznaczających odpowiednio datę początku i końca okresu, w którym certyfikat
uwaŜany będzie za aktualny. Daty mogą być zapisywane w jednym z dwóch
formatów - UTCTime lub GeneralizedTime – jednak pierwszy z nich, ze
względu na postać zapisu YYMMDDHHMMSSZ, pozwala na oznaczenie czasu
tylko do roku 2049. Wynika to z faktu, Ŝe dwie pierwsze cyfry (YY), gdy ich
wartość jest wieksza bądź równa 50, są interpretowane jako rok 19YY. W celu
zapewnienia certyfikatowi nieograniczonego okresu waŜności polu notAfter,
korzystając
ze
struktury
GeneralizedTime,
naleŜy
nadać
wartość
99991231235959Z
Validity ::= SEQUENCE {
notBefore
Time,
notAfter
Time }
Time ::= CHOICE {
utcTime
generalTime
UTCTime,
GeneralizedTime }
Podmiot (ang. Subject) – zawiera informacje dotyczące podmiotu, dla którego
certyfikat został wystawiony. Do opisu uŜywana jest identyczna struktura jak w
przypadku pola Issuer. Dodatkowo, jeŜeli zawartości tych dwóch pól są równe,
będzie to oznaczało ze certyfikat jest wystawiony przez jego posiadacza (ang.
self-issued)
Informacje o kluczu podmiotu (ang. Subject Public Key Info) - przechowuje
dane na temat klucza publicznego podmiotu oraz identyfikatora algorytmu,
którego uŜywa klucz.
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm
subjectPublicKey
BIT STRING }
Rozszerzenia (ang. Extensions) – lista rozszerzeń certyfikatu, Patrz 4.2
Extensions
::=
Extension ::=
extnID
critical
SEQUENCE SIZE (1..MAX) OF Extension
SEQUENCE {
OBJECT IDENTIFIER,
BOOLEAN DEFAULT FALSE,
str. 14
extnValue
OCTET STRING
-- contains the DER encoding of an ASN.1 value
-- corresponding to the extension type identified
-- by extnID
}
4.2 Rozszerzenia
Rozszerzenia zostały dodane do 3. wersji certyfikatu klucza publicznego.
Pozwalają
one
na
przypisywanie
dodatkowych
atrybutów
podmiotowi
posługującemu się certyfikatem, bądź jego kluczowi publicznemu. Format
umoŜliwia definiowanie własnych rozszerzeń, które pozwalają na dostosowanie
zawartości do unikalnych zastosowań. KaŜde z rozszerzeń zawiera pole
określające „krytyczność” rozszerzenia critical. W przypadku kiedy jego
wartość została ustawiona na TRUE system, który nie potrafi rozpoznać lub
obsłuŜyć danego rozszerzenia jest zobligowany do odrzucenia całości
certyfikatu. Poza polem określającym „krytyczność” rozszerzenie zawiera
równieŜ pole extnID przechowujące OID określające typ rozszerzenia oraz
przechowywaną w polu extnValue wartość. Certyfikat moŜe zawierać
wyłącznie jedną instancję rozszerzenia danego typu.
Do rozszerzeń, które muszą być obsługiwane, naleŜą:
4.2.1 UŜycie klucza (ang. Key usage)
Pozwala na określenie do jakich celów moŜe być wykorzystywany klucz
publiczny zamieszczony w certyfikacie zawierającym to rozszerzenie. Według
specyfikacji zawartej w [11] musi być ono dodane, jeŜeli klucz jest
wykorzystywany w celu podpisywania innych certyfikatów bądź list odwołań
certyfikatów CRL
id-ce-keyUsage OBJECT IDENTIFIER ::=
KeyUsage ::= BIT STRING {
digitalSignature
nonRepudiation
keyEncipherment
dataEncipherment
keyAgreement
keyCertSign
cRLSign
{ id-ce 15 }
(0),
(1), -- recent editions of X.509 have
-- renamed this bit to contentCommitment
(2),
(3),
(4),
(5),
(6),
str. 15
encipherOnly
decipherOnly
(7),
(8) }
4.2.2 Polityki certyfikacji (ang. Certificate Policies)
Definiuje warunki polityki, jakie zostały przypisane do certyfikatu. Określają one
zastosowania, do których moŜe być on uŜyty.
id-ce-certificatePolicies OBJECT IDENTIFIER ::=
{ id-ce 32 }
anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 }
certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
PolicyInformation ::= SEQUENCE {
policyIdentifier
CertPolicyId,
policyQualifiers
SEQUENCE SIZE (1..MAX) OF
PolicyQualifierInfo OPTIONAL }
4.2.3 Alternatywna nazwa posiadacza (ang. Subject alternative
name)
Rozszerzenie to musi zostać uŜyte w sytuacji, kiedy pole Subject jest
pozostawione przez CA puste. Pozwala ono na dołączenie dodatkowych
danych pozwalających na identyfikację podmiotu, takich jak adres email, nazwa
DNS, adres IP
id-ce-subjectAltName OBJECT IDENTIFIER ::=
{ id-ce 17 }
SubjectAltName ::= GeneralNames
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
GeneralName ::= CHOICE {
otherName
rfc822Name
dNSName
x400Address
directoryName
ediPartyName
uniformResourceIdentifier
iPAddress
registeredID
[0]
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
OtherName,
IA5String,
IA5String,
ORAddress,
Name,
EDIPartyName,
IA5String,
OCTET STRING,
OBJECT IDENTIFIER }
OtherName ::= SEQUENCE {
str. 16
type-id
value
OBJECT IDENTIFIER,
[0] EXPLICIT ANY DEFINED BY type-id }
EDIPartyName ::= SEQUENCE {
nameAssigner
partyName
[0]
[1]
DirectoryString OPTIONAL,
DirectoryString }
4.2.4 Podstawowe ograniczenia (ang. Basic constraints)
Rozszerzenie podstawowych warunków ograniczeń pozwala na określenie czy
właściciel danego certyfikatu moŜe być wydawcą oraz czy istnieją ograniczenia
względem długości ścieŜki certyfikacji (ang. Validation Path). Ograniczenia
zawarte w polu pathLenConstraint definiują maksymalną liczbę zagłębień w
strukturze certyfikatów pośrednich, które zostały wydane przez właściciela
certyfikatu. Wartość tego pola brana jest pod uwagę tylko i wyłącznie w
przypadku ustawienia w polu cA wartości TRUE.
id-ce-basicConstraints OBJECT IDENTIFIER ::=
{ id-ce 19 }
BasicConstraints ::= SEQUENCE {
cA
BOOLEAN DEFAULT FALSE,
pathLenConstraint
INTEGER (0..MAX) OPTIONAL }
4.2.5 Ograniczenia nazw (ang. Name constraints)
Ograniczenia nazw określają przestrzeń nazw jaka musi być uŜywana przez
certyfikaty podpisane przy pomocy certyfikatu zawierającego to rozszerzenie.
Ograniczenia te dotyczą zawartości pola Subject oraz, jeŜeli jest uŜywane,
rozszerzenia subjectAlternativeNames.
id-ce-nameConstraints OBJECT IDENTIFIER ::=
NameConstraints ::= SEQUENCE {
permittedSubtrees
[0]
excludedSubtrees
[1]
{ id-ce 30 }
GeneralSubtrees OPTIONAL,
GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
base
GeneralName,
str. 17
minimum
maximum
[0]
[1]
BaseDistance DEFAULT 0,
BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX)
4.2.6 Rozszerzone uŜycie klucza (ang. Extended key usage)
Podobnie jak Key usage umoŜliwia definiowanie celów, do których moŜe być
uŜywany zawarty w certyfikacie, klucz publiczny z tą róŜnicą, Ŝe pozwala na
definicje własnych zastosowań.
id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
KeyPurposeId ::= OBJECT IDENTIFIER
4.3 Odwoływanie certyfikatów
Kiedy certyfikat jest wydawany, ustawiana jest wartość pola Validity,
opisanego szczegółowo w punkcie 4.1 . Jednocześnie czynione jest załoŜenie,
Ŝe wydany dokument będzie mógł być uŜywany przez cały okres waŜności.
Zdarzają się jednak sytuacje, w których do odwołania certyfikatu musi dojść
przed wygaśnięciem jego natywnego okresu waŜności. Potrzeba taka moŜe być
spowodowana na przykład zmianą nazwy podmiotu, ujawnieniem lub
podejrzeniem ujawnienia odpowiadającego kluczowi publicznemu klucza
prywatnego.
Standard X.509 definiuje jedną metodę pozwalającą na odwołanie certyfikatu
[12]. Zakłada ona okresowe wydawanie przez CA, bądź podmiot autoryzowany
przez CA do tego celu,
podpisanych elektronicznie struktur danych
nazywanych Listami odwołań certyfikatów CRL (ang. Certificate revocation list).
Ta dostępna publicznie lista zawiera numery seryjne certyfikatów, które z
jakiegoś powodu utraciły waŜność. Systemy korzystające ze standardu X.509,
wraz ze sprawdzeniem pola Validity są zobligowane do sprawdzenia czy
certyfikat o danym numerze seryjnym nie został umieszczony na liście odwołań
publikowanej przez wydawcę certyfikatu lub podmiot uprawniony.
str. 18
Struktura CRL wersji 2.
CertificateList ::= SEQUENCE {
tbsCertList
TBSCertList,
signatureAlgorithm
signatureValue
BIT STRING }
TBSCertList ::=
version
SEQUENCE
{
Version OPTIONAL,
-- if present, MUST be v2
signature
issuer
Name,
thisUpdate
Time,
nextUpdate
Time OPTIONAL,
revokedCertificates
SEQUENCE OF SEQUENCE {
userCertificate
revocationDate
Time,
crlEntryExtensions
Extensions OPTIONAL
-- if present, version MUST be v2
} OPTIONAL,
crlExtensions
EXPLICIT Extensions OPTIONAL
-- if present, version MUST be v2
}
Szczegółowy opis wszystkich wymienionych pól i struktur został zawarty w [11]
oraz [13].
4.4 Weryfikacja certyfikatu
Walidacja jest procesem sprawdzania poprawności oraz wiarygodności danych
zawartych w certyfikacie cyfrowym. Pozwala on, uŜytkownikom weryfikującym
dany certyfikat, na uzyskanie potwierdzenia dotyczącego powiązania pomiędzy
posiadaczem certyfikatu, a uŜywanym przez niego kluczem publicznym.
Szczegółowy opis algorytmu zastał przedstawiony w [12].
4.4.1 Zawartość
Sprawdzenie poprawności zawartości składa się z następujących kroków:
•
Sprawdzenie poprawności podpisu wydawcy.
•
Porównanie pól zawartych w Validity Period z aktualną datą.
•
Upewnienie się czy numer certyfikatu nie znajduje się na liście odwołań
CRL.
str. 19
•
Sprawdzenie czy zawartość pola Issuer jest dokładnie taka sama jak
pola Subject w certyfikacie będącym jeden stopień wyŜej w hierarchii
ścieŜki certyfikacji.
•
Weryfikacja poprawności ograniczeń nazw, opisanych w 4.2.5, dla
wszystkich certyfikatów naleŜących do ścieŜki certyfikacji.
•
Sprawdzenie warunków rozszerzeń Polityki certyfikacji (ang. Certificate
Policie (4.2.2), Policy Constrains oraz Podstawowe ograniczenia (ang.
Basic constraints (4.2.4).
•
Sprawdzenie
czy
długości
ścieŜki
certyfikacji
nie
przekracza
maksymalnej ilości poziomów hierarchii określonej w sprawdzanym
certyfikacie lub PKC względem niego nadrzędnym.
•
Sprawdzenie rozszerzeń UŜycie klucza (ang. Key usage (4.2.1) oraz
Rozszerzone uŜycie klucza (ang. Extended key usage (4.2.6) ze
szczególnym uwzględnieniem moŜliwości uŜycia klucza do podpisywania
dokumentów.
•
Sprawdzenie przez system moŜliwości obsłuŜenia wszelkich rozszerzeń
określonych w certyfikacie jako krytyczne (ang. critical).
4.4.2 ŚcieŜka certyfikacji
Sprawdzanie ścieŜki certyfikacji rozpoczyna się od sprawdzenia certyfikatu,
zgodnie z procedurami opisanymi w punkcie 4.4.1. Kolejnym krokiem jest
sprawdzenie waŜności certyfikatów wydawców pośrednich, na kolejnych
poziomach zagłębienia hierarchii, aŜ do momentu dotarcia do zaufanego
centrum certyfikacji. JeŜeli podczas sprawdzania całej ścieŜki walidacji nie
dojdzie do błędu spowodowanego naruszeniem któregokolwiek z opisanych
powyŜej warunków, algorytm kończy się sukcesem. Oznacza on, Ŝe certyfikat
moŜe zostać uznany za poprawny i wiarygodny.
4.5 Podsumowanie
Przełom spowodowany publikacją [6], zaowocował powstaniem zupełnie
nowych metod w kryptografii. MoŜliwość wykorzystywania jednego klucza do
str. 20
szyfrowania, a innego do deszyfracji pozwoliła na przezwycięŜenie problemów
jakie stwarzało uŜycie kluczy symetrycznych – ten sam klucz uŜywany do
kodowania i dekodowania wiadomości – takich jak problem wstępnej wymiany
kluczy czy skalowalność ich liczby.
Certyfikaty PKC dzięki swoim właściwościom znalazły szerokie zastosowanie.
MoŜliwość szyfrowania danych oraz ich podpisu, przy jednoczesnej moŜliwości
weryfikacji stron stała się podstawą powstania między innymi takich protokołów
jak S/MIME, SSL, TLS, IPSEC.
Wykorzystanie
certyfikatów
klucza
publicznego
pozwala
na
budowę
elastycznych systemów autoryzujących, które nie wymagają pamiętania wielu
haseł. Niestety wykorzystanie ich do takiego celu w szerszej skali generuje
pewne problemy. W sytuacji kiedy podmiot jest uŜytkownikiem kilku systemów
wykorzystujących
PKC
do
przechowywania
danych
pozwalających
na
autoryzację w systemie, podczas wydawania certyfikatu CA musi zebrać
informacje ze wszystkich systemów w jakich podmiot uczestniczy. Takie
zadanie moŜe jednak w niektórych sytuacja być niemoŜliwe – na przykład jeśli
polityka bezpieczeństwa przyjęta w systemie nie pozwala na przekazanie takich
danych nawet zaufanej instytucji jaką jest CA. JeŜeli podmiot nie chce lub nie
moŜe mieć wszystkich danych w jednym certyfikacie zostaje zmuszony do
przechowywania ich w większej ilości. Takie podejście w znacznym stopniu
utrudnia korzystanie z infrastruktury. JeŜeli podmiot posługuje się kilkoma
certyfikatami
uŜytkownicy
mogą
napotkać
problemy
podczas
procesu
weryfikacji jego podpisu elektronicznego. Podmiot będzie zmuszony wraz z
wiadomością oraz podpisem wysyłać takŜe informacje pozwalające na
określenie
którego
certyfikatu
uŜył.
W
przeciwnym
wypadku
podmiot
weryfikujący będzie zmuszony znaleźć certyfikat który będzie odpowiadał
przesłanemu podpisowi cyfrowemu bądź po pierwszym wyborze złego
certyfikatu potraktować wiadomości jako niewiarygodna.
5 Certyfikaty Atrybutowe
Certyfikat atrybutowy jest podpisanym cyfrowo dokumentem elektronicznym,
podobnym do certyfikatu klucza publicznego. Pozwala on na przypisanie praw –
str. 21
atrybutów, określanych przez wydawcę certyfikatu, jego posiadaczowi. Główną
cechą róŜniącą oba typy certyfikatów jest fakt, iŜ certyfikat atrybutowy nie
zawiera klucza publicznego, co za tym idzie AC nie moŜe spełniać roli PKC –
wiązać toŜsamości podmiotu z jego kluczem. Jego zadaniem jest powiązanie,
dość szeroko rozumianej toŜsamości podmiotu z zestawem atrybutów. W
dokumencie RFC [14], będącym podstawą opisu tego rozdziału, pojawia się
przykład dobrze ilustrujący róŜnice pomiędzy wspomnianymi certyfikatami.
„Certyfikat PKC moŜe zostać porównany do paszportu - identyfikuje
posiadacza, jego termin waŜności jest dość długi oraz uzyskanie go nie jest
procedurą banalną. Certyfikat atrybutowy z kolei bardziej przypomina wizę,
która zazwyczaj wydawana jest przez inny organ władzy, na pewien okres
czasu. Okres ten jest zazwyczaj krótszy od terminu waŜności paszportu, a
procedura uzyskania prostsza. Do uzyskania wizy konieczne jest posiadanie
waŜnego paszportu.”
Certyfikat AC niekiedy określany jest mianem certyfikatu autoryzacyjnego.
Wynika to z faktu, iŜ przy jego pomocy, w dość prosty sposób, moŜna dokonać
delegacji takich uprawnień jak prawa dostępu do zasobów lub usług bądź
przynaleŜności do grupy uŜytkowników. Podobny efekt jest moŜliwy do
uzyskania przy wykorzystaniu standardowych certyfikatów PKC, poprzez
implementacje odpowiednich rozszerzeń. PrzewaŜnie jednak takie podejście
nie jest odpowiednie z dwóch powodów [14]. Pierwszym z nich jest czas, na
jaki podmiot otrzymuje uprawnienia. W przypadku umieszczenia np. danych
autoryzacyjnych w certyfikacie klucza publicznego, jego termin waŜności moŜe
być maksymalnie tak długi, jak długość okresu na który przyznano uprawnienia.
To zatem kłóci się z głównym przeznaczeniem PKC – tworzeniem powiązania
toŜsamości z kluczem publicznym. Drugim z powodów, tak jak w przytoczonym
powyŜej cytacie, jest sytuacja, kiedy wydawca PKC nie jest równocześnie
jednostką odpowiedzialną za autoryzację. Taki scenariusz wymaga od wydawcy
kontaktu z jednostka odpowiedzialną, w celu uzyskania danych potrzebnych do
uwierzytelnienia, tak by następnie móc je umieścić w certyfikacie.
5.1 Struktura i opis pól
Struktury wykorzystywane w tym punkcie pochodzą z dokumentu [14]
str. 22
AttributeCertificate ::= SEQUENCE {
acinfo
AttributeCertificateInfo,
signatureAlgorithm
signatureValue
BIT STRING
}
AttributeCertificateInfo ::= SEQUENCE {
version
AttCertVersion -- version is v2,
holder
Holder,
issuer
AttCertIssuer,
signature
serialNumber
attrCertValidityPeriod
AttCertValidityPeriod,
attributes
SEQUENCE OF Attribute,
issuerUniqueID
UniqueIdentifier OPTIONAL,
extensions
Extensions OPTIONAL
}
Wersja (ang. Version) Wartość tego pola musi zostać ustawiona na wartość
v2(1), poniewaŜ obecna struktura według standardu X.509-2000 nie jest
wstecznie kompatybilna ze struktura wersji v1 (X.509-1997)
AttCertVersion ::= INTEGER { v2(1) }
Posiadacz (ang. Holder) – Struktura ta pozwala na wykorzystanie jednego z
trzech równowaŜnych sposobów określenia podmiotu, dla którego AC został
wydany. Standard dopuszcza uŜywania więcej niŜ jednego z dopuszczalnych
sposobów, jednak w celu uniknięcia problemu z określeniem, który z nich jest
wiąŜący, a który jedynie wskazówką, rekomenduje się wybór tylko jednej z tych
opcji. JeŜeli AC jest uŜywany w celach autoryzacji w połączeniu z PKC zaleca
się wybór baseCertificateID . W takim przypadku pole Holder (Holder.
baseCertificateID.issuer)
umieszczonym
w
musi
zawierać
odpowiadającym
wartość
certyfikacie
identyczną
klucza
z
publicznego.
DN
W
przypadku uŜycia entityName wartość tego pola musi być identyczna z polem
Subject umieszczonym w PKC lub jedną z wartości rozszerzenia Subject
Alternative Name. W niektórych sytuacjach wymagane jest powiązane
certyfikatu z informacjami innymi niŜ dane podmiotu czy jego certyfikat PKC. W
takich przypadkach moŜliwe jest uŜycie opcji objectDigestInfo. Pozwala ona
na powiązanie certyfikatu AC ze skrótem ( ang. Hash ) obiektu dla którego
str. 23
zostaje wystawiony. Takie rozwiązanie umoŜliwia na przykład tworzenie AC
powiązanych wyłącznie z kluczem publicznym bądź przypisywanie uprawnień
plikom wykonywalnym.
Holder ::= SEQUENCE {
baseCertificateID
IssuerSerial OPTIONAL,
-- the issuer and serial number of
-- the holder's Public Key Certificate
entityName
GeneralNames OPTIONAL,
-- the name of the claimant or role
objectDigestInfo
ObjectDigestInfo OPTIONAL
-- used to directly authenticate the holder,
-- for example, an executable
}
IssuerSerial ::=
issuer
serial
issuerUID
}
SEQUENCE {
GeneralNames,
UniqueIdentifier OPTIONAL
ObjectDigestInfo ::= SEQUENCE {
digestedObjectType ENUMERATED {
publicKey
(0),
publicKeyCert
(1),
otherObjectTypes
(2) },
-- otherObjectTypes MUST NOT
-- be used in this profile
otherObjectTypeID
OBJECT IDENTIFIER OPTIONAL,
digestAlgorithm
objectDigest
BIT STRING
}
Wydawca (ang. Issuer) – musi zawierać tylko i wyłącznie jedną pozycje w
liście GeneralNames, określającą DN wydawcy certyfikatu.
AttCertIssuer ::= CHOICE {
v1Form
GeneralNames,
v2Form
V2Form
}
V2Form ::= SEQUENCE {
issuerName
baseCertificateID
objectDigestInfo
-- issuerName MUST
-- MUST NOT be used in this
-- profile
-- v2 only
IssuerSerial OPTIONAL,
be present in this profile
str. 24
-- baseCertificateID and objectDigestInfo MUST
-- NOT be present in this profile
}
Podpis (ang. Signature) – Struktura i znaczenie tego pola jest identyczne jak
w przypadku pola Signature Algorithm opisanego,
przy okazji PKC, w
punkcie 4.1
Numer seryjny (ang. Serial number) – Pole, jak w przypadku PKC, słuŜy do
stworzenia unikalnej pary wartości nazwa wydawcy – numer seryjny,
pozwalającej na jednoznaczną identyfikację certyfikatu AC.
Termin waŜności (ang. Attribute Certificate Validity Period) – W odróŜnieniu
od PKC wartości pola zawierającego termin waŜności certyfikatu mogą
korzystać wyłącznie ze struktury GeneralizedTime. Poza tą róŜnicą, znaczenie
i interpretacja tego pola jest identyczna jak opisana w punkcie 4.1
AttCertValidityPeriod ::= SEQUENCE {
notBeforeTime GeneralizedTime,
notAfterTime
GeneralizedTime
}
Atrybuty (ang. Attributes) – Patrz 5.2
Unikalny identyfikator wydawcy (ang. Issuer Unique ID) – Pole to moŜe
zawierać wartość tylko i wyłącznie w sytuacji, kiedy PKC wydawcy zawiera
powyŜszy parametr.
Rozszerzenia (ang. Extentions) – Patrz 5.3
5.2 Atrybuty i ich typy
Lista atrybutów słuŜy do przechowywania informacji, takich jak uprawnienia,
które przy pomocy AC są przypisywane jego posiadaczowi. KaŜda z pozycji
str. 25
figurujących na liście musi posiadać unikalny, w obrębie listy, identyfikator OID
(Object identifier), oraz przynajmniej jedną wartość.
Attribute ::= SEQUENCE {
type
AttributeType,
values
SET OF AttributeValue
-- at least one value is required
}
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY DEFINED BY AttributeType
IetfAttrSyntax ::= SEQUENCE {
policyAuthority GeneralNames
OPTIONAL,
values
SEQUENCE OF CHOICE {
octets
OCTET STRING,
oid
OBJECT IDENTIFIER,
string
UTF8String
}
}
Przykłady standardowych atrybutów, wraz z ich identyfikatorami i znaczeniem
opisano poniŜej. Opisy oraz struktury w nich opisane zostały przygotowane na
podstawie [14].
5.2.1 Informacje uwierzytelniające (ang. Service Authentication
Information)
Atrybut ten jest wykorzystywany do przekazywania systemom informacji
autentykujących posiadacza AC – na przykład pary wartości login-hasło. UŜycie
tego atrybutu pozwala na przechowywanie w polu authInfo zaszyfrowanych
wartości, o których mowa w sekcji 5.4
Name
OID
Syntax
values:
id-aca-authenticationInfo
{ id-aca 1 }
SvceAuthInfo
Multiple allowed
SvceAuthInfo ::=
SEQUENCE {
service
GeneralName,
ident
GeneralName,
authInfo OCTET STRING OPTIONAL
}
str. 26
5.2.2 ToŜsamość (ang. Access Identity)
Podobnie jak opisany powyŜej, ten atrybut słuŜy do autentykacji posiadacza w
systemie, z tą róŜnicą, Ŝe nie umoŜliwia przechowywania danych w postaci
niejawnej.
Name
OID
syntax
values:
id-aca-accessIdentity
{ id-aca 2 }
SvceAuthInfo
Multiple allowed
5.2.3 Podmiot odpowiedzialny (ang. Charging Identity)
W sytuacji, gdy AC pozwala na dostęp do zasobów czy usług podlegających
opłacie, ten atrybut moŜe być wykorzystywany do określenia podmiotu, który
ma zostać za niego obciąŜony.
name
id-aca-chargingIdentity
OID
{ id-aca 3 }
syntax
IetfAttrSyntax
values:
One Attribute value only; multiple values within the
IetfAttrSyntax
5.2.4 Grupa - (ang. Group)
Przechowuje informacje na temat przynaleŜności posiadacza do grup
uŜytkowników. Ich nazwy powinny być tworzone w sposób umoŜliwiający łatwą
identyfikację. [14] przedstawia sytuację, w której w firmach A i B istnieje grupa o
nazwie „administratorzy”. Zastosowanie wartości będącej wyłącznie nazwą
grupy moŜe prowadzić do wieloznaczności.
name
OID
syntax
values:
id-aca-group
{ id-aca 4 }
IetfAttrSyntax
One Attribute value only; multiple values within the
IetfAttrSyntax
5.2.5 Rola (ang. Role)
Pozwala na przypisanie ról pełnionych przez posiadacza certyfikatu. Podobnie
jak w przypadku grupy, nazwa roli powinna być tworzona w sposób pozwalający
na uniknięcie wieloznaczności.
str. 27
RoleSyntax ::= SEQUENCE {
roleAuthority
roleName
GeneralName
}
name
OID
syntax
values:
id-at-role
{ id-at 72 }
RoleSyntax
Multiple allowed
5.2.6 Poziom Dostępu (ang. Clearance)
Struktura zawarta w atrybucie umoŜliwia określenie poziomu dostępu do
informacji poufnych.
Clearance ::= SEQUENCE {
policyId OBJECT IDENTIFIER,
classList ClassList DEFAULT {unclassified},
securityCategories
SET OF SecurityCategory OPTIONAL
}
ClassList ::= BIT
unmarked
unclassified
restricted
confidential
secret
topSecret
}
STRING {
(0),
(1),
(2)
(3),
(4),
(5)
SecurityCategory ::= SEQUENCE {
type
IMPLICIT OBJECT IDENTIFIER,
value
ANY DEFINED BY type
}
5.3 Rozszerzenia
Podobnie jak w przypadku certyfikatu klucza publicznego, rozszerzenia
pozwalają na przypisywanie dodatkowych atrybutów posiadaczowi AC. Poprzez
moŜliwość dodawania własnych rozszerzeń, mechanizm ten umoŜliwia
dostosowanie zawartości certyfikatu do specyficznych wymagań korzystających
z nich systemów komputerowych.
str. 28
5.3.1 ToŜsamość audytowa (ang. Audit Identity)
Ideą tego rozszerzenia jest dostarczenie mechanizmu pozwalającego na
identyfikację posiadacza bez konieczności ujawniania jego toŜsamości.
Pozwala to na zachowanie anonimowości podczas rutynowej pracy, jednak w
przypadku wykrycia podejrzanego zachowania daje moŜliwość jednoznacznego
zidentyfikowania posiadacza certyfikatu.
name
OID
syntax
criticality
id-pe-ac-auditIdentity
{ id-pe 4 }
OCTET STRING
MUST be TRUE
5.3.2 Odbiorcy certyfikatu (ang. AC Targeting)
AC Targeting pozwala na określenie listy serwerów lub systemów, które mogą
wykorzystywać dany certyfikat. Dopuszczalne jest takŜe definiowanie grup
odbiorców, jednak sposób definiowania przynaleŜności nie jest określony przez
standard X.509. Przyjmowane jest załoŜenie, Ŝe serwer wie do jakich grup
naleŜy.
Targets ::= SEQUENCE OF Target
Target ::= CHOICE {
targetName
GeneralName,
targetGroup
GeneralName,
targetCert
TargetCert
}
TargetCert ::= SEQUENCE {
targetCertificate
IssuerSerial,
targetName
GeneralName OPTIONAL,
certDigestInfo
}
name
id-ce-targetInformation
OID
{ id-ce 55 }
syntax
SEQUENCE OF Targets
criticality
MUST be TRUE
5.3.3 Identyfikator klucza autoryzacyjnego (ang. Authority Key
Identifier)
UŜycie
tego
rozszerzenia
ma
za
zadanie
ułatwienie
systemowi,
sprawdzającemu dany certyfikat, weryfikacji podpisu wydawcy [14].
str. 29
name
OID
syntax
criticality
id-ce-authorityKeyIdentifier
{ id-ce 35 }
AuthorityKeyIdentifier
MUST be FALSE
5.3.4 Dostęp do danych wydawcy (ang. Authority Information
Access) i miejsca dystrybucji list CRL (ang. CRL Distribution
Points)
Moduły pozwalają na dodanie informacji na temat miejsca oraz sposobu
publikacji list odwołań certyfikatów. Szczegółowy opis sposobu stosowania oraz
róŜnic między tymi rozszerzeniami moŜna znaleźć w [14].
5.3.5 Brak informacji o odwołaniach (ang. No Revocation Available)
Rozszerzenie pozwala wydawcy na oświadczenie, iŜ dla danego AC nie będą
wydawane Ŝadne informacje na temat odwołań.
name
OID
syntax
criticality
id-ce-noRevAvail
{ id-ce 56 }
NULL (i.e. '0500'H is the DER encoding)
MUST be FALSE
5.4 Szyfrowanie atrybutów
Ze względu na charakter danych jakie mogą być zawarte w AC, moŜe niekiedy
zachodzić konieczność przechowywania ich w formie niejawnej. Standard
przedstawiony w
[14] opisuje moŜliwość szyfrowania atrybutów oraz
przedstawia dokładny algorytm postępowania przy ich dodawaniu. Zakłada on
zakodowanie zestawu atrybutów przeznaczonych dla określonej grupy
odbiorców. Do opisania kaŜdego z takich zestawów wykorzystywana jest
struktura, która po wypełnieniu poddawana jest szyfrowaniu.
ACClearAttrs ::= SEQUENCE {
acIssuer GeneralName,
acSerial INTEGER,
attrs
SEQUENCE OF Attribute
}
str. 30
Zawarcie w ACClearAttrs pól acIssuer oraz acSerial pozwala na
sprawdzenie czy niejawny atrybut został przypisany przez wydawcę AC,
uniemoŜliwiając w ten sposób nieuczciwemu wydawcy certyfikatu atrybutowego
skopiowanie zaszyfrowanej wartości atrybutu i przypisania jej do innego
certyfikatu.
Wykorzystanie kodowania atrybutów ogranicza grupę odbiorców certyfikatu
wyłącznie do podmiotów, które będą w stanie odkodować jego zawartość. W
przypadku kiedy podmiot nie potrafi tego uczynić jest równocześnie
zobligowany do odrzucenia całości AC.
name
OID
Syntax
values
id-aca-encAttrs
{ id-aca 6}
ContentInfo
Multiple Allowed
5.5 Weryfikacja certyfikatu
Proces sprawdzenia poprawności certyfikatu atrybutowego składa się z
następujących kroków:
•
JeŜeli certyfikat AC jest powiązany z certyfikatem PKC, to PKC musi być
poprawny w rozumieniu algorytmu opisanego w 4.4
•
Podpis wydawcy AC oraz jego PKC muszą być poprawne.
•
PKC wydawcy, jeŜeli zawiera rozszerzenie Key usage, musi w nim
zawierać informacje potwierdzające moŜliwość wykorzystania klucza
publicznego do podpisywania dokumentów cyfrowych.
•
Moment, w którym certyfikat został uŜyty musi zawierać się w przedziale
zamkniętym ograniczonym chwilami czasowymi, określonymi w polu
attrCertValidityPeriod. Czas uŜyty do weryfikacji certyfikatu nie
musi być
równy aktualnemu
czasowi,
w którym
operacja
jest
przeprowadzana.
•
W
przypadku
uŜycia
rozszerzenia
Targeting sprawdzający
musi
znajdować się na liście podmiotów, które mogą wykorzystywać dany AC.
str. 31
•
Sprawdzający musi być w stanie zinterpretować i obsłuŜyć wszelkie
rozszerzenia oznaczone jako krytyczne (critical
przeciwnym
przypadku
jest zobowiązany do
=
TRUE), w
odrzucenia takiego
certyfikatu.
Dodatkowe warunki sprawdzania certyfikatów mogą być definiowane w
poszczególnych systemach implementujących obsługę AC. Pozwala to na
dostosowanie AC do potrzeb systemu. Przykładem takiego warunku moŜe
być
odrzucanie
certyfikatów
nie
zawierających
któregokolwiek
z
wymaganych przez serwis atrybutu.
5.6 Odwoływanie
Ze
względu na charakterystykę zastosowań certyfikatów atrybutowych ich
termin waŜności moŜe być bardzo krótki. Często jest on krótszy niŜ czas
potrzebny na odwołanie AC. Wymaga to udostępnienia specyficznych metod
zarządzania odwołaniami certyfikatów.
5.6.1 Brak odwołań (ang. Never revoke)
Podejście to polega na poinformowaniu sprawdzającego certyfikat, przy
pomocy rozszerzenia, o którym mowa w 5.3.5, iŜ AA (ang. Attribute Authority)
nie będzie utrzymywał ani publikował Ŝadnych informacji na temat odwołań tego
certyfikatu.
5.6.2 Wskaźnik na CRL w certyfikacie (ang. Pointer at AC)
Podejście zakłada okresowe udostępnianie przez AA list odwołań, tak jak ma to
miejsce w przypadku PKC (opis w 4.3). Dodatkowo w AC, przy wykorzystaniu
rozszerzeń Authority Information Access i CRL Distribution Points, moŜe zostać
opublikowana informacja na temat miejsc, w których listy odwołań są dostępne.
5.7 Podsumowanie
Wykorzystanie certyfikatów atrybutowych pozwala na rozwiązanie problemu,
opisywanego w 4.5, dotyczącego posiadania przez podmiot kilku certyfikatów.
MoŜliwość oddzielenia informacji o toŜsamości posiadacza od jego uprawnień
sprawia, Ŝe budowa systemów opierających autoryzacje o wykorzystanie PKC i
str. 32
AC staje się łatwiejsza, a takŜe umoŜliwia podmiotowi wydającemu certyfikat
atrybutowy AA na pełną niezaleŜność od urzędu certyfikacji CA.
Certyfikaty atrybutowe mogą znaleźć zastosowanie w aplikacjach tworzonych
dla systemów operacyjnych urządzeń mobilnych, takich jak telefony komórkowe
wyposaŜone w Symbian OS czy SmartPhone [15]. KaŜdy z twórców
oprogramowania jest zobowiązany do posiadania własnego certyfikaty PKC.
Certyfikaty te wydawane są przez komercyjne CA bądź przez samych
producentów urządzeń jak na przykład Nokia. W celu uzyskania moŜliwości
dostępu do wybranych komponentów czy funkcji systemu aplikacja musi zostać
podpisana przez jej autora przy pomocy waŜnego certyfikatu PKC [16].
Informacje na temat praw jakie zostały przypisane aplikacji mogą być zawierane
w certyfikacie atrybutowym. Tak przygotowana aplikacja przed uruchomieniem i
przyznaniem zasobów jest weryfikowana przez system operacyjny. UŜycie
certyfikatów atrybutowych pozwala uniknąć przechowywania w urządzeniu
duŜych ilości informacji zawierających dane o zaufanych dostawcach
oprogramowania, których aplikacje mogą w sposób bezpieczny być instalowane
i uruchamiane w systemie.
Omawiane w tym rozdziale certyfikaty znalazły takŜe zastosowanie w systemie
DIMEDAC będącym implementacją systemu zarządzania przywilejami PMI
(ang. Privilege Management Infrastructure) przygotowanym na potrzeba
zarządzania rozproszonymi bazami danych zawierającymi dane medyczne [17].
W zastosowaniach medycznych bardzo często występuje sytuacja, w której
dane personalne lekarza w Ŝaden sposób nie są w stanie określić jego
kompetencji. Niezbędna jest informacja, na przykład na temat specjalizacji,
uprawnień do przeprowadzania zabiegów itp. Takie dane pozwalają na
sklasyfikowanie przynaleŜności do grupy np. chirurgów o to one, z punktu
widzenia uprawnień, są waŜniejsze od danych personalnych lekarza. Z tego
powodu stosowanie certyfikatów PKC byłoby niewygodne, gdyŜ wiązało by się z
potrzebą budowy całej infrastruktury zarządzającej powiązaniem między
toŜsamością a uprawnieniami lekarza. W takiej sytuacji zalety z wykorzystania
certyfikatów AC są oczywiste.
str. 33
Zastosowanie
certyfikatów
atrybutowych
daje
twórcom
systemów
informatycznych, bardzo elastyczny i wygodny w uŜyciu, mechanizm autoryzacji
oraz określania praw do zasobów. Pozwala to, poprzez wykorzystanie
infrastruktury PKI, na tworzenie bardziej bezpiecznych i często łatwiejszych w
utrzymaniu aplikacji. MoŜliwości oferowane przez ten mechanizm będą
najprawdopodobniej coraz powszechniej wykorzystywane.
6 Przechowywanie kluczy.
W
dobie
Internetu
potrzeba
zachowania
poufności
oraz
integralności
przesyłanych danych, powoduje konieczność stosowania mechanizmów
kryptograficznych.
Wykorzystywanie szyfrowania, bez względu na to czy
uŜywana jest kryptografia klucza symetrycznego czy asymetrycznego, pozwala
na
realizację
tych
celów.
Rodzą
się
jednak
problemy
związane
z
przechowywaniem kluczy. W większości przypadków istnieje tylko jeden klucz
kryptograficzny pozwalający na uzyskanie dostępu do zaszyfrowanych danych.
W sytuacji kiedy dochodzi do jego utraty – awaria nośnika pamięci na którym
był przechowywany, nieobecność osoby znającej klucz itp. – równocześnie
tracony jest dostęp do wszelkich informacji, które zostały zaszyfrowane z jego
pomocą. Równie istotnym zagroŜeniem co utrata klucza jest jego ujawnienie
bądź pozyskanie przez osoby trzecie. Takie sytuacje wymagają zastosowania
mechanizmów,
pozwalających
na
bezpieczne
przechowywanie
kopii
zapasowych klucza, które w przypadku uszkodzenia lub utraty oryginału
zapobiegną sytuacji, w której poufne dane staną się bezuŜyteczne.
6.1 Depozyty kluczy
Najprostszym sposobem zabezpieczenia klucza przed utratą, jest wykonanie
jego kopii i przekazanie jej innej osobie czy teŜ instytucji. Takie rozwiązanie jest
dopuszczalne,
jednak
wymaga od posiadacza pełnego zaufania wobec
powiernika, gdyŜ w sytuacji kiedy klucz prywatny wykorzystywany jest do
tworzenia podpisu cyfrowego, podwaŜona zostaje niezaprzeczalność źródła
podpisu [18]. Zwiększenie szansy na dostępność kopii zapasowej moŜe zostać
uzyskana poprzez zwiększenie ich liczby, jednak to rozwiązanie, z kaŜdą
str. 34
kolejną kopią, zwiększa ryzyko, ujawnienia klucza poprzez ujawnienie
którejkolwiek z jego kopii.
6.2 Podział klucza
W celu uniknięcia problemu opisanego powyŜej moŜna wprowadzić zasadę
ograniczonego zaufania w taki sposób, Ŝe dokonujemy podziału klucza, a
powstałe w ten sposób fragmenty rozdystrybuować, w celu przechowania do
grupy powierników. W tej sytuacji powiernik posiada jedynie fragment sekretu,
którego nie będzie w stanie wykorzystać. Główną wadą tego rozwiązania jest
konieczność posiadania wszystkich fragmentów w celu odtworzenia klucza, co
za tym idzie utworzona kopia naraŜona jest na zniszczenie w momencie kiedy
zniszczeniu ulegnie choćby jedna z jej części.
6.3 Schematy podziału sekretu
Schematy te polegają na podziale sekretu przez dystrybutora D(osoba lub
organizacja odpowiedzialna za podział) i rozdystrybuowania fragmentów pośród
grupy powierników o liczebności . Fragmenty tworzone są w taki sposób, Ŝe
kaŜdy podzbiór fragmentów liczniejszy od minimalnej liczby fragmentów ,
pozwala na odzyskanie sekretu. Jednocześnie jakikolwiek podzbiór uniemoŜliwia odzyskanie sekretu. Schemat taki w literaturze oznaczany jest
jako schemat progowy , (ang. , -threshold scheme).
6.4 Schemat , Podział, w którym wszystkie fragmenty są niezbędne w celu odzyskania
sekretu, opisany we wcześniejszym punkcie, jest najprostszym ze schematów.
MoŜe być on zrealizowany na wiele sposobów – dwa z nich, oparte o
dodawanie oraz o operacje XOR – zostaną przedstawione poniŜej
Sposób 1:
NaleŜy zamienić sekret na reprezentację liczbową , a następnie grupie
1
powierników przydzielić
dowolną
losową
liczbę
, 1. . .
Ostatniemu z powierników przydzielana jest liczba będąca wynikiem
działania … . Suma tak powstałych fragmentów
pozwoli na odzyskanie sekretu .
str. 35
Sposób 2:
Sekret jest przedstawiony w postaci binarnej. Grupie 1 powierników
przydzielane są losowe liczby ( 1. . ) w postaci binarnej, których
długość jest równa długości sekretu . Fragment p0 obliczany jest za
pomocą wzoru … . W celu odzyskania sekretu
naleŜy przeprowadzić operacje XOR na wszystkich fragmentach.
6.5 Shamir’s secret sharing scheme
Schemat Shamira jest przykładem nietrywialnego schematu podziału
klucza/sekretu,
opartym
na
interpolacji
wielomianowej.
W
pracy
[19],
przedstawiającej ten schemat, cytowany jest przykład zagadnienia, które leŜy u
podstaw powstania tej metody: „Jedenastu naukowców pracuje nad tajnym
projektem. Pragną schować dokumentacje w sejfie, tak by tylko sześciu, lub
więcej z nich, jednocześnie było w stanie ów sejf otworzyć. Ile zamków i ile
kluczy jest potrzebnych w celu realizacji takiego rozwiązania?” Przy takich
danych odpowiedzią jest 462 zamków oraz 252 kluczy dla kaŜdego naukowca.
Liczby te rosną w sposób wykładniczy wraz z rosnącą liczbą naukowców
pracujących przy projekcie. Jak widać w realnym świecie zastosowanie takiego
rozwiązania jest co najmniej trudne. Jak kaŜdy schemat, takŜe i schemat
Shamira, składa się z dwóch etapów:
Etap 1: Tworzenie fragmentów
1. Dystrybutor D wybiera dowolny wielomian stopnia 1 gdzie
sekret jest wyrazem wolnym [19]
. . . Wszystkie współczynniki … !
! !
wybierane są w sposób losowy.
2. Dystrybutor D wybiera róŜnych niezerowych wartości ", # 1. . dla których oblicza wartości wielomianu $" %. Po przeprowadzeniu
obliczeń
powiernikom
przekazana
jest
wartość &'" (" , $" %) [20]
Etap 2: Rekonstrukcja sekretu
str. 36
1. W
celu
odtworzenia
sekretu
potrzebujemy
przynajmniej
fragmentów
&'" (" , $" %)
2. UŜywamy interpolacji Lagrange’a w celu odnalezienia unikalnego
wielomianu , takiego Ŝe *'+$" % ,- $" % &'" 3. Sekret otrzymamy obliczając wartość wyrazu wolnego wielomianu
0 W aplikacji będącej częścią praktyczną niniejszej pracy zastosowano
następujące rozwiązanie [19]:
Etap 1: Tworzenie fragmentów
1. Mając podaną reprezentację liczbową sekretu wybierana jest liczba
pierwsza , taka Ŝe / ,- / współczynniki wielomianu wybierane są w sposób losowy spośród liczb naturalnych z przedziału
00, 11 (0 traktujemy jako liczbę naturalną)
2. Obliczamy
&'" $" , $" %mod p%
Rekonstrukcja sekretu odbywa się w sposób analogiczny
Właściwości schematu Shamira [19]:
•
Rozmiar fragmentu nie przekracza rozmiaru sekretu .
•
Przy zachowaniu niezmienionej liczby niezbędnych fragmentów dodawanie kolejnych fragmentów polega na obliczeniu
wartości
wielomianu w kolejnym unikalnym punkcie " .
•
Schemat pozwala na przypisanie wag poszczególnym powiernikom,
poprzez przypisanie im odpowiedniej liczby fragmentów. ZałóŜmy, Ŝe
istnieje firma, w której prezes ma dostęp do tajnych dokumentów. W
str. 37
firmie działa równieŜ rada nadzorcza, w której skład wchodzi 10
członków. W celu zapewnienia bezpieczeństwa poufnym danym, dostęp
do nich poza prezesem, moŜe uzyskać grupa przynajmniej 4 członków
rady nadzorczej. W takiej sytuacji moŜna zastosować schemat Shamira
(4,14) przypisując prezesowi 4 fragmenty, tak by samodzielnie był w
stanie uzyskać dostęp do dokumentów, oraz po jednym dla kaŜdego z
członków rady.
•
Podział Shamira ma właściwość homomorficzną , . Dowód tej
właściwości został opisany w [21]. Oznacza to, Ŝe jeŜeli dane są dwa
sekrety 6 i 7 oraz odpowiadające im fragmenty (1… ) oraz
(+1 … +) i kaŜdy z powierników dokona sumy fragmentów & + (gdzie i 8 01, 9 jest numerem powiernika) otrzyma w ten
sposób fragment sekretu 6 7 [20] .
Reasumując: suma fragmentów sekretów 6 i 7 jest równa fragmentowi
sumy sekretów 6 7 [21].
6.6 Zarządzanie fragmentami
6.6.1 Weryfikowalny podział sekretu
Schemat Shamira zakłada, Ŝe dystrybutor D jest godny zaufania, a tworzone
przez niego fragmenty są poprawne i jako efekt ich połączenia otrzymany
zostanie prawidłowy sekret . Jednak w niektórych sytuacjach powiernicy mogą
wymagać potwierdzenia takiego stanu rzeczy. Rozwiązaniem najprostszym jest
zebranie fragmentów i sprawdzenie czy dla tych punktów istnieje wielomian
stopnia co najwyŜej
1. Jednak takie rozwiązanie jest niedopuszczalne,
pomimo uzyskania przez powierników pewności co do poprawności ich
fragmentów, ze względu na fakt, Ŝe ujawniony zostaje sekret . Przedstawione
rozwiązania oparte są o homomorficzną właściwość podziału Shamira, oraz
korzystają z własności wielomianów mówiącej, Ŝe „JeŜeli stopień sumy
wielomianów jest stopnia t-1 to oba są stopnia maksymalnie 1 lub oba są
stopnia większego niŜ 1” [21]
str. 38
6.6.2 Verifiable Secret Sharing (VVS)
Wersja 1.
ZałoŜeniem tej operacji jest udowodnienie powiernikowi, bez ujawniania
sekretu, Ŝe wielomian uŜyty do stworzenia fragmentu jest co najwyŜej
stopnia 1
Przebieg procedury [20], [21]:
1. Dystrybutor D przy pomocy schematu Shamira generuje fragmenty
&'" (" , $" %)
sekretu , a następnie przesyła je do
powierników.
2. Dystrybutor D wybiera pewną liczbę wielomianów ( np. 100) stopnia co
najwyŜej 1: : … : a następnie przesyła powiernikowi 100
fragmentów, po jednym dla kaŜdego wielomianu : … : , 8 01, 9.
3. Powiernik losowo wybiera podzbiór otrzymanych fragmentów (np. 50)
;# , … , #< =
a
następnie
prosi
o
ujawnienie
odpowiadającym
im
wielomianów :" … :"< .
4. Dystrybutor D ujawnia powiernikowi wspomniane wielomiany, który
upewnia się Ŝe przedstawione wielomiany są stopnia co najwyŜej 1.
W ten sposób, bez ujawniania współczynników wielomianu ,
dystrybutor
D
jest
w
stanie
udowodnić,
z
duŜą
dozą
prawdopodobieństwa, Ŝe wszystkie wielomiany : … : są
stopnia co najwyŜej 1.
5. Dystrybutor sumuje niewybrane, losowe wielomiany z wielomianem : :"< … :" ,
wynik tej sumy przesyła powiernikowi.
6. Powiernik sprawdza czy wielomian powstały z sumy niewybranych,
losowych wielomianów jest stopnia co najwyŜej 1. Jednocześnie jest
w stanie sprawdzić czy : : , +*-' " jest
str. 39
argumentem, dla którego policzony został fragment sekretu , dla
kaŜdego 8 ;#< , … , # =.
Wersja 2.
Kolejna z metod weryfikacji poprawności posiadanego fragmentu nie
zakłada, tak jak wcześniejsza, uczciwości dystrybutora D ani powierników
[20], [21]. Wymaga ona jednak przyjęcia dodatkowych załoŜeń: Algorytm
szyfrujący powinien mieć własność homomorfizmu1 > ? > · >?
(np. algorytm Diffie-Hellmana)
1. Dystrybutor D przy pomocy schematu Shamira tworzy fragmenty, które
następnie szyfruje i przesyła do powierników.
2. Dystrybutor D wybiera losowy zbiór wielomianów stopnia co najwyŜej
1
(np.
100),
a
następnie
przesyła
powiernikom
po
100
zaszyfrowanych fragmentów.
>: 1 … >: 1
…
>: … >: 3. Powiernik w sposób losowy wybiera podzbiór otrzymanych wartości
;# , … , #< =, a następnie prosi o ujawnienie odpowiadającym im
wielomianów :" … :"< .
4. Powiernik sprawdza czy dla ujawnionych wielomianów zachodzi
równość:
+AB >:C dla kaŜdego D 8 ;#, … , #< = oraz 8 01, 9
5. Dystrybutor sumuje niewybrane, losowe wielomiany z wielomianem .
1
Homomorfizm to funkcja odwzorowująca jedną algebrę ogólną w drugą.
Def: Niech A= i B= będą algebrami ogólnymi tego samego typu, zaś h : A → B funkcją
przekształcającą zbiór A w zbiór B. Dla i=1,...,n niech a(i) będzie arnością operacji f(i) oraz g(i)
(arności te muszą być równe, bo algebry A i B mają ten sam typ). Wtedy h jest
homomorfizmem algebry A w algebrę B, jeśli dla kaŜdego i=1,...,n oraz ciągu (x(1),...,x(a(i)))
elementów zbioru A zachodzi równość h(f(i)(x(1),...,x(a(i))))=g(i)(h(x(1)),...,h(x(a(i)))). Oznacza
to, Ŝe dla kaŜdego i=1,...,n odwzorowanie h przeprowadza operację f(i) w operację
g(i).Homomorfizm, który jest odwzorowaniem wzajemnie jednoznacznym nazywamy
izomorfizmem. [40]
str. 40
: :"< … :" ,
a wynik tej sumy przesyła powiernikowi.
6. KaŜdy powiernik sprawdza czy dla jego wartości i zachodzi równość:
+ EFGAHF > · >: dla kaŜdego 8 ;# , … , #< =
Przedstawione powyŜej metody weryfikowania poprawności fragmentów naleŜą
do metod interaktywnych. Oznacza to, Ŝe wymagają współpracy powierników i
tylko ci z nich, którzy będą brali udział w wyborze podzbioru wielomianów,
mogą uznać wyniki powyŜszych procedur za wiarygodne. Dla osób postronnych
metody
te
nie
dają
Ŝadnej
moŜliwości
zweryfikowania
poprawności
wygenerowanych fragmentów.
6.6.3 Nieinteraktywna metoda weryfikacji fragmentów
W tej procedurze dystrybutor D wraz z przygotowanymi fragmentami przesyła
równieŜ dodatkowe informacje, które pozwalają powiernikowi podjąć decyzję
czy powinien zaakceptować przekazany mu fragment.
Algorytm wymaga by funkcja szyfrujący posiadał następujące własności [20],
[22]:
•
> ? >I>?
•
> · ? >J>?
1. Dystrybutor D przy pomocy schematu Shamira tworzy fragmenty
(1… )
sekretu , następnie szyfruje współczynniki wielomianu
. . . > , > , … , >
! .
! !
, uŜytego do stworzenia fragmentów
Tak przygotowany zestaw danych przekazuje
powiernikom.
2. KaŜdy -ty powiernik sprawdza równość
>$% ? > I$> J> %I … I>
! J>
! str. 41
JeŜeli równość jest zachowana, powiernik ogłasza dystrybutorowi D oraz
pozostałym powiernikom, Ŝe jego fragment jest poprawny. W sytuacji, gdy
równość nie jest zachowana, ta informacja równieŜ jest rozgłaszana. W takim
przypadku pozostali powiernicy muszą podjąć decyzję, która ze stron próbuje
oszukiwać – dystrybutor D czy powiernik zgłaszający błąd.
6.6.4 Proaktywne metody zarządzania fragmentami
Ideą schematów podziału, takich jak schemat Shamira, jest przechowywanie
fragmentów sekretu w rozproszeniu, przez cały czas Ŝycia sekretu. Jednak
takie załoŜenie stwarza zagroŜenie, Ŝe przy dostatecznie długim czasie,
serwery przechowujące fragmenty mogą zostać zaatakowane w celu uzyskania
niezbędnej,
do
odtworzenia
sekretu,
ilości
fragmentów.
Dodatkowym
czynnikiem wpływającym na bezpieczeństwo sekretu są awarie systemów lub
nośników, w których fragmenty są przechowywane. Chęć uchronienia danych
wraŜliwych przed ujawnieniem lub zniszczeniem, w skutek jednego z
powyŜszych scenariuszy, stała się podstawą do prac nad kolejnymi metodami
zarządzania fragmentami sekretu .
ZałoŜenia metod proaktywnych
[20], [23]
•
W kaŜdym okresie czasu 7 musi być dostępne co najmniej prawidłowych fragmentów pozwalających na odtworzenie sekretu .
•
Istnieje, wymagający uwierzytelnienia, system rozgłaszania komunikatów
do wszystkich powierników.
•
Pomiędzy kaŜdymi dwoma powiernikami istnieje bezpieczny kanał
komunikacyjny.
•
Systemy przechowujące fragmenty muszą być w stanie dokonać
synchronizacji czasu.
•
Powiernik, w razie zagroŜenia uzyskania dostępu, moŜe usunąć swój
fragment .
str. 42
6.6.5 Odnawianie fragmentów
Metody proaktywne zakładaną cykliczne zmiany fragmentów, bez zmiany
sekretu , w celu zabezpieczenia przed ich zniszczeniem. Oznacza to, Ŝe w
danym okresie czasu 7 istnieje zestaw fragmentów, pozwalający na
odtworzenie danych, z chwilą nastania okresu 7 1 fragmenty te są
zastępowane nowymi - stają się przez to bezuŜyteczne. Taka zmiana
fragmentów moŜe odbywać się bez obecności dystrybutora D.
Procedura
wstępna
wymaga
przygotowania
fragmentów
dla
kaŜdego
powiernika oraz określenia przedziału czasu 7 po którym procedura odnowy
fragmentów zostaje uruchomiona. Przebiega ona w sposób następujący [20],
[23]:
1. KaŜdy
-ty
powiernik
: wybiera
wielomianu : . . . 1
! !
współczynników( … ! , 0.
2. KaŜdy -ty powiernik : rozsyła do pozostałych powierników :" fragmenty
: j uŜywając przy tym mechanizmu nieinteraktywnej weryfikacji
fragmentów.
3. Powiernik : otrzymuje fragmenty : … : , przy pomocy tworzy nowy
fragment sekretu przy pomocy wzoru & ∑NO :N , a
następnie usuwa starą wersje fragmentu .
6.6.6 Sprawdzanie fragmentów
Ten mechanizm pozwala powiernikowi na sprawdzenie czy fragmenty
posiadane przez pozostałych powierników są poprawne, bądź nie uległy
zniszczeniu. ZałoŜeniem jest umieszczenie we wszystkich fragmentach,
wspólnego znacznika, który pozwoli na kresowe porównywanie fragmentów.
Procedura wstępna wymaga zastosowania, opisanej powyŜej, procedury
odnawiania
fragmentów
przechowywania
wraz
zaszyfrowanych
z
nieinteraktywna
fragmentów.
weryfikacją
RóŜnica
polega
oraz
na
str. 43
zastosowaniu w punkcie 2. metody odnawiania fragmentów przesyłania
zaszyfrowanych fragmentów >: j
KaŜdy -ty powiernik uaktualnia swój zestaw otrzymanych fragmentów
korzystając ze wzoru >& > · ∏NO >:N Przy pomocy tej wartości powiernicy mogą dokonać sprawdzenia poprawności
fragmentów posiadanych przez pozostałych uczestników protokołu.
6.6.7 Rekonstrukcja zniszczonych/ujawnionych fragmentów
MoŜliwość dokonania rekonstrukcji zniszczonych fragmentów jest podstawową
własnością umoŜliwiającą schematowi poprawne działanie [23]. W sytuacji
braku takiego mechanizmu osoba atakująca system mogłaby stopniowo
uszkadzać kolejne serwery przechowujące dane, aŜ do momentu uszkodzenia z nich, co skutkowałoby zniszczeniem informacji wraŜliwej . ZałoŜeniem
takiego mechanizmu jest dostarczenie uczestnikowi protokołu Q informacji
pozwalających na odtworzenie fragmentu. Najprostszą metodą, która niestety
ujawni tajną informację , byłoby przesłanie przez wszystkich uczestników
protokołu ich fragmentów, przy pomocy których powiernik Q mógłby obliczyć
wartość wielomianu a następnie dla dowolnej, unikalnej wartości odtworzyć
swój fragment. W celu zachowania sekretu w tajemnicy, naleŜy uŜyć innego
mechanizmu.
PoniŜsza procedura zastała opisana w pracy [24]
1. KaŜdy -ty powiernik( 8 01, Q9 R 0Q, 9 ) w sposób losowy wybiera
wielomian : stopnia 1, dla którego : Q 0 oraz : 0 0.
2. KaŜdy -ty powiernik, poza m-tym, przesyła fragmenty do pozostałych
uczestników protokołu, wykorzystując przy tym VVS.
3. -ty powiernik otrzymuje wielomiany : … :S! , :SG … : , a
następnie oblicza nowy fragment dla uŜytkownika Q jako: & ∑NO,NTS :N . Wynik tego obliczenia przesyła w sposób bezpieczny do
powiernika Q.
str. 44
4. UŜytkownik
, wykorzystując
wykorzystuj c interpolacje uzyskuje wielomian
.
6.7 Podsumowanie
Wraz z rosnącym
cym upowszechnianiem się
si wykorzystania kryptografii w
zabezpieczaniu
eczaniu danych przed dostępem
dost pem osób niepowołanych, problem
bezpiecznego przechowywania klucz staje się
si coraz bardziej istotny. Poprzez
zastosowanie opisanych w tym rozdziale rozwiązań
rozwi
moŜna
na w znacznym stopniu
podnieść stopień bezpieczeństwa
bezpiecze
jak i dostępnościi danych kryptograficznych.
Poza przedstawionym schematem Shamira istnieje wiele innych schematów
podziału sekret
. W tym miejscu naleŜy
nale wspomnieć o schemacie Blakleya,
zaprezentowanym w pracy [25] opublikowanej w tym samym czasie co praca A.
Shamira, prezentującą
ącą alternatywne rozwiązanie
zanie zagadnienia.
Rysunek 3 Schemat Shamira (2, n) [18]
Rysunek 4 Schemat Blakleya (2,n) [18]
str. 45
Schematy podziału informacji poufnej znalazły zastosowanie przy projektowaniu
systemów pozwalających na przeprowadzanie głosowania. Więcej informacji na
ten temat moŜna odnaleźć w pracach [26], [27], [28]
7 Opis systemu
Jako część praktyczna niniejszej pracy została stworzona aplikacja o nazwie
CMS (ang. Certificates Management System)
7.1 ZałoŜenia projektu
Projekt
zakłada
stworzenie
rozproszonego
systemu
pozwalającego
na
przyznawanie uprawnień pracownikom pewnej firmy. Przyznanie uprawnienia
uŜytkownikowi polega na wydaniu certyfikatu atrybutowego określającego
zakres uprawnień. Certyfikat podpisywany jest przez grupę uprawnioną do
podejmowania takiej decyzji – rada nadzorcza, prezes itp. MoŜe on zostać
wydany wyłącznie po uzyskaniu określonej liczby potwierdzonych decyzji
aprobujących
przyznanie
uprawnienia.
Klucz
prywatny
odpowiadający
certyfikatowi PKC grupy, dzielony jest przy wykorzystaniu schematu Shamira i
przechowywany w rozproszeniu na róŜnych serwerach. Komunikacja między
systemami odbywa się poprzez przesyłanie, zaszyfrowanych przy pomocy
kluczy uzyskanych z certyfikatów serwerów, wiadomości przy pomocy protokołu
http. Kiedy ilość decyzji akceptujących osiągnie wymaganą liczbę, system
pobiera z repozytoriów fragmenty klucza grupy, a następnie rekonstruuje go w
celu wykorzystania do podpisania certyfikatu AC. Po wydaniu certyfikatu
tymczasowa kopia klucza jest niszczona.
7.2 Narzędzia i technologie
Do realizacji głównej, z punktu widzenia uŜytkownika, części systemu został
wykorzystany, napisany w języku PHP, framework CakePHP wraz z bazą
danych MySQL. Zastosowanie tej technologii wiąŜe się z charakterem
wykonywanej przez autora pracy. Z powodu braku
dostępnych dla PHP
bibliotek pozwalających na przeprowadzania obliczeń na duŜych liczbach
naturalnych konieczne było zbudowanie aplikacji hybrydowej
str. 46
W Internecie moŜna odnaleźć kilka bibliotek kryptograficznych pozwalających
na
realizację poszczególnych części funkcjonalności systemu opisanego
powyŜej. Wśród nich naleŜy wymienić uŜywane Bouncy Castle, OpenSSL,
Crypto++®, Java Cryptography Extension (JCE – oficjalna biblioteka dołączana
do dystrybucji SDK). Języki takie jak C# czy Python równieŜ posiadają
wbudowane
biblioteki
pozwalające
na
przeprowadzanie
operacji
kryptograficznych, jednak z powodu preferencji autora do języka JAVA nie
zostały one wybrane. Spośród pozostałych, ze względu na bardzo dobrą
dokumentację oraz oferowane moŜliwości do generowania certyfikatów
atrybutowych wybrana została biblioteka BouncyCastle. Spośród pakietów
implementujących podział klucza przy uŜyciu schematu Shamira, we względu
na przyzwoitą dokumentację oraz dostarczone wraz z dystrybucją przykłady,
wybrano Logi.crypto. Inne biblioteki realizujące powyŜszy cel to Tontine, JSS,
jSecretSharing, Crypto++®, Sass.
7.2.1 Technologie
Niniejszy punkt opisuje technologie, jakie zostały uŜyte do budowy systemu
CMS.
7.2.1.1 PHP
PHP jest popularnym językiem programowania. Jego głównym przeznaczeniem
jest tworzenie dynamicznych stron internetowych. Skrypty napisane w tym
języku maja składnie podobną jak w Perl-u i podobnie jak on są interpretowane
przez parser.
Więcej informacji moŜna odnaleźć tutaj: [29]
7.2.1.2 MySQL
Do realizacji zadań związanych z przechowywaniem danych zastosowany
został serwer MySQL w wersji 5. Jest to bardzo popularny, darmowy serwer
relacyjnych baz danych. MySQL posiada wersje dla większości, obecnych na
rynku, systemów operacyjnych.
str. 47
7.2.1.3 OpenSSL
OpenSSL jest otwartą implementacją protokołów SSL oraz TLS, zawierającą
wiele bibliotek oraz narzędzi kryptograficznych. Pozwala na tworzenie oraz
zarządzanie certyfikatami PKC.
7.2.1.4 Java
Bardzo popularny, obiektowy język programowania stworzony przez firmę Sun
Microsystems. Kod napisany w tym języku jest
kompilowany a następnie
uruchamiany w maszynie wirtualnej. Zastosowanie takiego mechanizmu
pozwala na oddzielenie kodu od jądra systemu, w którym jest on uruchamiany.
Pozwala to na uzyskanie niezaleŜności od sprzętu, co w znacznym stopniu
zwiększa moŜliwości przenoszenia programów miedzy systemami.
7.2.2 Narzędzia
Opisane poniŜej środowiska programistyczne zostały wybrane ze względu na
bardzo duŜe moŜliwości konfiguracyjne oraz przyzwyczajenia autora.
7.2.2.1 Eclipse
Eclipse jest środowiskiem programistycznym IDE (ang. integrated development
environments) stworzonym przez firmę IBM, którego kod następnie został
udostępniony publicznie. Pozwoliło to na dynamiczny rozwój tej platformy.
Zdaniem autora jest to jedno z najbardziej przyjaznych środowisk wspierających
tworzenie
aplikacji
w
języku
JAVA.
Opublikowanie
źródeł
programu
zaowocowało powstaniem wielu dodatków pozwalających na obsługę róŜnych
języków programowania, przyczyniając się do jeszcze większego wzrostu
popularności tej platformy.
7.2.2.2 Zend Studio
Jest to komercyjne środowisko programistyczne przeznaczone do tworzenia
skryptów w języku PHP. Oprogramowanie to w znacznym stopniu ułatwia
tworzenie oraz testowanie aplikacji, poprzez zastosowanie kolorowania oraz
str. 48
automatycznego uzupełniania składni, moŜliwość przeprowadzania testów we
wbudowanym serwerze www oraz dość rozbudowaną bibliotekę gotowych
fragmentów kodu. Nowsze wersje środowiska, od wersji 5.5, zostały
zbudowane na bazie silnika Eclipse, przez co wcześniejsza funkcjonalność
aplikacji została wzbogacona w moŜliwości dołączenia wszelkich wtyczek
stworzonych dla tego silnika.
7.2.2.3 Logi
Pakiet Logi.crypto jest biblioteką kryptograficzną przeznaczoną dla języka
JAVA. Biblioteka ta jest dla celów niekomercyjnych dystrybuowana na
zasadach licencji GPL.
7.2.2.4 Bouncy Castle
Bouncy Castle jest aktywnie rozwijanym, zestawem bibliotek kryptograficznych
przeznaczonych dla języków JAVA oraz C#. Udostępnia API do tworzenia i
zarządzania protokołami/standardami, takimi jak: Certyfikaty X.509 w wersjach
v1 oraz v3, certyfikaty atrybutowe, listy odwołań CRL, S/MIME, TLS, OpenPGP
i inne.
7.2.2.5 CakePHP
CakePHP jest zestawem skryptów ( Framework ) przeznaczonym do tworzenia
dynamicznych stron internetowych. Został on w całości napisany w PHP w
oparciu i model MVC (Model View Controller). Zastosowana architektura
pozwala na bardzo wygodne rozdzielenie poszczególnych warstw aplikacji,
pozwalając przez to na ich niezaleŜne tworzenie. W CakePHP został
wbudowany mechanizm automatycznego tworzenia szkieletu aplikacji (ang.
scaffolding), który w znaczący sposób przyspiesza proces budowania aplikacji.
Pozwala on na wygenerowanie podstawowych metod manipulacji danymi,
takimi jak dodawanie, edycja, usuwanie, tworzenie listy oraz wyświetlanie.
str. 49
Framework posiada wbudowaną obsługę ACL (Access Control List) jak i wielu
innych komponentów odpowiedzialnych za takie aspekty jak autoryzacja,
bezpieczeństwo czy obsługę wielojęzyczności aplikacji. Wykorzystanie modelu
MVC pozwala na prostą i intuicyjną rozbudowę funkcjonalności poprzez
tworzenie własnych, integralnych komponentów, które mogą być wielokrotnie
uŜywane. Wiele z gotowych rozwiązań jest udostępnianych przez członków
społeczności współtworzącej Cake, czyniąc tworzenie aplikacji internetowych
szybszym i wygodniejszym.
7.3 Wymagania sprzętowe
Aplikacja będąca załącznikiem
niniejszej pracy jest
przeznaczona
do
uruchomienia w systemie Linux. Wymaga instalacji serwera WWW (np.
APACHE) obsługującego PHP i mod_rewrite oraz serwera baz danych MySQL.
Dodatkowo konieczna jest obecność w systemie biblioteki OpenSSL oraz
maszyny wirtualnej JAVA. Konfiguracja PHP musi umoŜliwiać wywoływanie
poleceń z poziomu linii komend systemu Linux.
7.4 Opis implementacji
System CMS (ang. Certificates Management System) implementuje realizację
następującego scenariusza. Zakładamy istnienie Grupy A której członkami są
osoby składające wnioski oraz Grupy B, której członkowie owe wnioski
rozpatrują. W aplikacji przyjęto następujące nazewnictwo: Grupa A – Sekretarki
(ang. Secretaries), Grupa B – Rada nadzorcza ( ang. Chairmans).
1. Członek grupy A składa wniosek o wydanie pełnomocnictwa do realizacji
zadania, którego opis dołącza do wniosku.
2. KaŜdy z członków grypy B moŜe zaaprobować prośbę zawartą w
zgłoszeniu.
3. Procedura z punktu 2 trwa do momentu uzyskania wymaganej ilości
podpisów. Wraz z chwilą osiągnięcia tej liczby, z fragmentów klucza
grupy B, będących w posiadaniu kaŜdego z jej członków, odtwarzany jest
klucz prywatny.
str. 50
4. Przy pomocy klucza prywatnego tworzony jest podpis cyfrowy pod
certyfikatem atrybutowym wydawanym wnioskodawcy z grupy A.
Aplikacja została zrealizowana jako serwis WWW implementowany przy
wykorzystaniu frameworka CakePHP. Przygotowany projekt został zbudowany
poprzez stworzenie kilku kontrolerów (ang. controllers) realizujących logikę
biznesową aplikacji. Wygląd panelu uŜytkownika (kod HTML wraz z CSS oraz
danymi przekazywanymi z kontrolera) przechowywany jest w widokach (ang.
view), natomiast informacje dotyczące struktur danych, takich jak relacje
pomiędzy poszczególnymi tabelami bazy danych, określane są w modelach.
W implementacji wykorzystywane są, wraz z odpowiadającymi im widokami
oraz kontrolerami, następujące modele:
•
Atrybuty
•
Grupy
•
Zgłoszenia
•
Podpisy
•
UŜytkownicy
KaŜdemu z tych modeli odpowiada w bazie danych, tabela o tej samej nazwie.
Opis tabel wraz z zastosowaniem zawartych w nich pól został umieszczony w
punkcie 7.4.2.
KaŜdej grupie oraz uŜytkownikowi, podczas dodawania go do systemu
wydawany jest osobisty certyfikat PKC, do którego podpisu wykorzystywany
jest główny certyfikat aplikacji. Realizacja tego zadania została wykonana przy
wykorzystaniu wbudowanych w PHP funkcji obsługi biblioteki OpenSSL.
Interfejs do realizacji wszystkich operacji związanych z tą biblioteką został
zawarty
w
niezaleŜnym
komponencie
Cert
(cms/controllers/components/cert.php). W przypadku grup klucz prywatny,
odpowiadający kluczowi publicznemu zawartemu w jej certyfikacie, poddawany
jest procedurze podziału przy wykorzystaniu schematu Shamira , . Dla
str. 51
potrzeb aplikacji przyjęto, iŜ U/12X1, gdzie U1·X1 jest funkcją sufit. Z tego wzoru
wynika, iŜ kaŜda zmiana liczebności grupy wiąŜe się z koniecznością
przeprowadzenia procedury podziału na podstawie nowej liczby fragmentów,
niezbędnych w trakcie operacji odzyskiwania klucza. Z powodu braku
dostępnych bibliotek realizujących wymagane obliczenia na duŜych liczbach
naturalnych dla języka PHP, system korzysta z niezaleŜnych aplikacji
napisanych w języku JAVA. Obliczenia wartości fragmentów klucza zostały
zaimplementowane,
przy
wykorzystaniu
biblioteki
Logi.crypto,
w
pliku
ShareSecret.java. Funkcje systemu odpowiedzialne za tworzenie interfejsu do
realizacji funkcjonalności związanych z wydawaniem certyfikatów atrybutowych
zawiera komponent Cert. Z tego samego powodu co w przypadku
ShareSecret.java,
Certificates.java
JAVA
została
napisanej
w
wykorzystywana
oparciu
o
do
bibliotekę
stworzenia
Bouncy
klasy
Castle,
implementującej proces wydawania AC.
W celu uruchomienia programu SecretShare.java naleŜy go skompilować:
/cms/webroot$ javac org/logi/crypto/demo/ShareSecret.java
A następnie uruchomić
/cms/webroot$ java org.logi.crypto.demo.ShareSecret T N
Program przyjmuje dwa parametry uruchomieniowe
T – ilość fragmentów niezbędnych do odtworzenia klucza
N – ilość wszystkich fragmentów
W celu kompilacji i uruchomienia Certificates.java, w ścieŜce klasy (ang.
classpath) konieczne jest zawarcie providera BouncyCastle.
/cms/webroot$
javac
–cp
.:./bcprov-jdk16-143.jar
Certificates.java
/cms/webroot$ java –cp .:./bcprov-jdk16-143.jar Certificates
<file1> <file2> <file3> <file4> <attribs>
str. 52
Aplikacja wymaga pięciu parametrów
1. File1 – certyfikat PKC wydawcy
2. File2 – klucz prywatny wydawcy ( w standardzie PEM)
3. File3 – certyfikat PKC przyszłego posiadacza certyfikatu
4. File4 – nazwa pliku pod jaką zapisany zostanie wygenerowany AC
5. Attribs – Zestaw atrybutów do zamieszczenia w AC, przekazywane w
postaci ciągu znaków oid1-wartość,oid2-wartość…
7.4.1 Konfiguracja wstępna
W celu wdroŜenia aplikacji na serwerze wymagane jest podjęcie kroków, które
maja
na
celu
konfigurację
poszczególnych
komponentów.
PoniŜej
zamieszczono punkty zawierające opis, koniecznych do przeprowadzenia
czynności.
7.4.1.1 Struktura katalogów
Aplikacja korzysta z następującej struktury katalogów.
Katalog główny
drwxrwxr-x 5 4096 2009-09-10 14:09 cake_core
--przechowuje aktualną wersje jądra CakePHP
drwxrwxr-x 13 4096 2009-09-10 14:09 cms
--główny katalog aplikacji, będący jednocześnie korzeniem systemu
wyświetlania domeny serwera WWW
drwxrwxr-x 5 4096 2009-09-10 14:10 cmspkeys
--katalog przechowujący klucze prywatne użytkowników aplikacji
Ze względów bezpieczeństwa katalog cmspkeys został utworzony poniŜej
korzenia (ang. Root) struktury katalogowej serwera WWW. Korzeń powinien
wskazywać na zawartość katalogu cms.
Katalog cmspkeys
drwxrwxr-x 2 4096 2009-09-10 14:10 groups
drwxrwxr-x 2 4096 2009-09-10 14:10 root
str. 53
drwxrwxr-x 2 4096 2009-09-10 14:10 users
Katalog cms
-rwxr-xr-x 1 141 2009-09-10 14:09 .htaccess
--plik odpowiedzialny za konfiguracje modulu mod_rewrite – przy
wykorzystywanej konfiguracji niezbędny do poprawnego jej działania
-rwxr-xr-x 1 2453 2009-09-10 14:09 app_controller.php
-rwxr-xr-x 1 1357 2009-09-10 14:09 app_helper.php
-rwxr-xr-x 1 1273 2009-09-10 14:09 app_model.php
--Trzy powyższe pliki są klasami po których dziedziczą wszystkie,
odpowiednio, kontrolery, komponenty wspierające widoki oraz modele
drwxr-xr-x 4 4096 2009-09-10 14:09 config
--Zawiera pliki konfiguracyjne CakePHP, w tym plik w którym
definiowane jest połączenie z bazą danych
drwxr-xr-x 4 4096 2009-09-10 14:09 controllers
--Kontorolery
-rwxr-xr-x 1 963 2009-09-10 14:09 index.php
drwxr-xr-x 4 4096 2009-09-10 14:09 locale
drwxr-xr-x 5 4096 2009-09-10 14:09 models
--Modele
drwxr-xr-x 3 4096 2009-09-10 14:09 plugins
drwxr-xr-x 6 4096 2009-09-10 14:09 tests
drwxrwxr-x 7 4096 2009-09-10 14:09 tmp
--Pliki tymczasowe (katalog musi dawać prawo do zapisu użytkownikowi
uruchamiającemu serwer www)
drwxr-xr-x 6 4096 2009-09-10 14:09 vendors
--Katalog dodatkowych rozszerzeń
drwxr-xr-x 17 4096 2009-09-10 14:09 views
--Widoki
drwxr-xr-x 12 4096 2009-09-10 14:09 webroot
--główny katalog aplikacji z punktu widzenia serwera WWW
Katalog cms/controllers/
-rw-rw-r-drwxr-xr-x
-rw-rw-r--rw-rw-r--rw-rw-r--rw-rw-r--
1 2369
3 4096
1 3103
1 2626
1 6538
1 10201
2009-09-10
2009-09-10
2009-09-10
2009-09-10
2009-09-10
2009-09-10
14:09
14:09
14:09
14:09
14:09
14:09
attributes_controller.php
components
groups_controller.php
requests_controller.php
signatures_controller.php
users_controller.php
Katalog cms/controllers/components
-rw-r--r-- 1 10069 2009-09-10 14:09 cert.php
-rw-r--r-- 1 2397 2009-09-10 14:09 curl.php
-rw-r--r-- 1 4947 2009-09-10 14:09 shamir.php
str. 54
Katalog cms/webroot
-rwxr-xr-x 1
185 2009-09-10 14:09 .htaccess
-- konfiguracja mod_rewrite
-rw-rw-r-- 1
12476 2009-09-10 14:09 Certificates.class
-rw-r--r-- 1
16519 2009-09-10 14:09 Certificates.java
--kod
aplikacji
odpowiedzialnej
za
wydawanie
certyfikatów
wtrybutowych
-rw-rw-r-- 1
6337 2009-09-10 14:09 ValidateCertificate.class
-rw-r--r-- 1
7374 2009-09-10 14:09 ValidateCertificate.java
--kod aplikacji wyświetlającej właściwości AC
-rw-r--r-- 1 1688340 2009-09-10 14:09 bcprov-jdk16-143.jar
--Bouncy Castle crtyptographic provider
drwxr-xr-x 7
4096 2009-09-10 14:09 certs
--Katalog odpowiedzialny za przechowywanie certykifatów
drwxr-xr-x 3
4096 2009-09-10 14:09 css
-rwxr-xr-x 1
2984 2009-09-10 14:09 css.php
drwxr-xr-x 3
4096 2009-09-10 14:09 img
-rwxr-xr-x 1
3043 2009-09-10 14:09 index.php
drwxr-xr-x 4
4096 2009-09-10 14:09 js
drwxr-xr-x 4
4096 2009-09-10 14:09 org
--katalog zawiera pakiet Logi.crypto implementujący schemat Shamira
Katalog cms/webroot/certs
drwxrwxr-x
drwxrwxr-x
drwxrwxr-x
drwxrwxr-x
2
3
3
3
4096
4096
4096
4096
2009-09-10
2009-09-10
2009-09-10
2009-09-10
14:09
14:09
14:09
14:09
attrCerts
groups
root
users
7.4.1.2 Baza danych
Zrzut danych oraz struktur tabel, opisanych w punkcie 7.4.2, został
umieszczony w pliku: cms/config/database.sql
7.4.1.3 CakePHP
W celu konfiguracji Cake konieczna jest modyfikacja dwóch plików.
W pliku cms/webroot/index.php w linii 58 naleŜy zdefiniować lokalizację źródeł
jądra
frameworka,
CAKE_CORE_INCLUDE_PATH
poprzez
wartości
przypisanie
będącej
absolutną
zmiennej
ścieŜką
do
katalogu jądra. W przypadku zmiany w hierarchii katalogów naleŜy równieŜ
zmodyfikować wartości zmiennych ROOT oraz APP_DIR.
str. 55
W pliku cms/config/database.php naleŜy wypełnić pola pozwalające na
uzyskanie połączenia z bazą danych. Dokładny opis znaczenia poszczególnych
pól znajduje się w komentarzu zamieszczonym w tym pliku.
7.4.1.4 Component OpenSSL
W pliku cms/vendors/OpenSSL.php w linii 171 naleŜy podać poprawną ścieŜkę
dostępu do pliku konfiguracyjnego biblioteki OpenSSL.
7.4.2 Struktura bazy
Baza danych została stworzona przy uŜyciu serwera MySQL. Tabele w bazie
zostały zoptymalizowane do trzeciej postaci normalnej.
Pola created oraz modified, występujące w kaŜdej z tabel, są automatycznie
uzupełniane przez mechanizm obsługi pochodzący z CakePHP. Do działania
systemu
wymagane
są
równieŜ
tabele
odpowiedzialne
za
realizację
mechanizmu ACL – aros, acos, oraz aros_acos. Ich struktura oraz znaczenia
poszczególnych pól zostały opisane w dokumentacji projektu [38].
7.4.2.1 Relacje między tabelami
Rysunek 5 Relacje między tabelami uŜywanymi przez komponent ACL w CakePHP
str. 56
Rysunek 6 Relacje między tabelami systemu
7.4.2.2 UŜytkownicy
Tabela słuŜy do przechowywania informacji na temat uŜytkowników systemu.
Pola username i password wykorzystywane są do autentykacji.
Group_id definiuje przynaleŜność do grupy uŜytkowników.
Share słuŜy do przechowywania fragmentów klucza prywatnego grupy, do
której naleŜy dany uŜytkownik.
CREATE TABLE users (
id int(11) NOT NULL auto_increment,
username varchar(255) NOT NULL,
`password` char(40) NOT NULL,
group_id int(11) NOT NULL,
`share` blob NOT NULL,
created datetime default NULL,
modified datetime default NULL,
PRIMARY KEY (id),
UNIQUE KEY username (username)
)
str. 57
7.4.2.3 Grupy uŜytkowników
Tabela ta słuŜy do przechowywania informacji, na temat istniejących w
systemie grup, których nazwy zawarte są w polu name.
CREATE TABLE groups (
`name` varchar(100) NOT NULL,
created datetime default NULL,
modified datetime default NULL,
PRIMARY KEY (id)
)
7.4.2.4 Zgłoszenia
Tabela przechowuje dane dotyczące próśb wydania certyfikatu atrybutowego
składanych przez uŜytkownika, którego id znajdzie się w polu user_id. Opis
zamieszczonego zgłoszenia umieszczany jest w polu desc, a grupa, której
członkowie je zaakceptują, identyfikowana jest przez klucz obcy group_id. W
momencie zatwierdzenia zgłoszenia przez wymaganą liczbę uŜytkowników
wartość pola complete zostaje ustawiona na 1.
CREATE TABLE requests (
user_id int(11) NOT NULL,
group_id int(11) NOT NULL,
`desc` text NOT NULL,
complete tinyint(4) default '0' COMMENT '1=complete',
created timestamp NOT NULL default CURRENT_TIMESTAMP,
modified timestamp NOT NULL default '0000-00-00 00:00:00',
PRIMARY KEY (id)
)
7.4.2.5 Podpisy
Struktura przechowuje informacje na temat akceptacji przez uŜytkownika
user_id zgłoszenia request_id. W czasie akceptacji, generowany jest losowa
wartość umieszczana w text, która uŜytkownik, przy pomocy swojego klucza
prywatnego szyfruje (signature).
CREATE TABLE signatures (
request_id int(11) NOT NULL,
`text` text NOT NULL,
str. 58
signature text NOT NULL,
created timestamp NOT NULL default CURRENT_TIMESTAMP,
modified timestamp NOT NULL default '0000-00-00 00:00:00',
PRIMARY KEY (id)
)
7.4.2.6 Atrybuty certyfikatu
UŜytkownik user_id moŜe przed akceptacja request_id dodać ograniczenia
określane przy uŜyciu oid oraz name nadając mu wartość value
CREATE TABLE attributes (
id int(11) unsigned NOT NULL auto_increment,
request_id int(11) NOT NULL,
`name` varchar(255) NOT NULL,
oid varchar(255) NOT NULL,
`value` varchar(255) NOT NULL,
created timestamp NULL default CURRENT_TIMESTAMP,
modified timestamp NULL default '0000-00-00 00:00:00',
PRIMARY KEY (id)
)
7.5 Testy
Dla stworzonej aplikacji CMS przeprowadzono testy mające na celu
sprawdzenie działania poszczególnych modułów systemu oraz interakcji między
nimi.
Wystawianie certyfikatów.
Sprawdzenie tego modułu polegało na wielokrotnym dodawaniu do systemu
nowych uŜytkowników oraz grup, a następnie weryfikacji danych zawartych w
certyfikacie ( pola Subject, Validity Period, Issuer ) poprzez wykorzystanie
biblioteki OpenSSL (openssl
x509
-text
-in
cert.pem).
Kolejnym
krokiem było sprawdzenie czy wygenerowany klucz publiczny odpowiada
prywatnemu poprzez zakodowanie i odkodowanie pewnego losowego tekstu.
Wyniki sprawdzenia nie wykazywały jakichkolwiek błędów występujących w tej
procedurze.
str. 59
Dzielenie kluczy.
Procedura polega na zachowaniu oryginalnego klucza, następnie poddaniu go
procedurze podziału, odtworzeniu za pomocą podzbioru fragmentów, a
następnie porównaniu z wartością sprzed operacji. Ze względu na czas trwania
operacji zostało wykonanych jedynie kilkanaście testów, z których większość
zakończyła
się
otrzymaniem
oczekiwanych
wyników.
W
pozostałych
przypadkach błędy związane były ze złym przekazaniem argumentów do
procedury podziału i nie wynikały z jej błędnego działania.
Generowanie certyfikatu atrybutowego.
Testy polegały na sprawdzeniu wygenerowanego certyfikatu poprzez audyt
zawartości poszczególnych pól oraz poprawności podpisu pod certyfikatem.
Procedura sprawdzała zachowanie mechanizmu pozwalającego na przypisanie
dowolnego atrybutu poprzez podanie go jako argumentu procedury.
Otrzymane rezultaty, po naprawie początkowych błędów implementacyjnych,
wypadły pozytywnie.
Test Systemu
Testy systemu jako całości zostały kilkukrotnie przeprowadzone zgodnie ze
scenariuszem opisanym w punkcie 7.4. Otrzymane rezultaty wskazują na
poprawną realizacje przez system załoŜeń implementacji.
System poprawnie realizował funkcjonalności:
•
Dodawanie uŜytkownika do systemu – bazy danych
•
Generowanie osobistego certyfikatu uŜytkownika
•
Obliczania fragmenu klucza grupy, gdy uŜytkownik został dodany do
grupy Chairmans
•
Dodawanie zgłoszenia przez uŜytkownika grupy Secretaries
•
Akceptacja zgłoszenia przez uŜytkownika z grupy Chairams
•
Odtwarzanie klucza i generowanie certyfikatu atrybutowego.
str. 60
8 Wnioski
Z powodu braku bibliotek dla języka PHP system musiał zostać zbudowany w
technologii hybrydowej – korzystającej z PHP oraz JAVA. Generowało to pewne
trudności w trakcie testowania aplikacji wynikające z konieczności określenia w
pierwszej kolejności modułu generującego błędne wyniki, a dopiero kolejnym
krokiem było jego naprawienie.
Ilość
bibliotek
pozwalających
na
implementację
mechanizmów obsługi
certyfikatów atrybutowych jest dość niewielka. Co więcej, Ŝadna ze znanych i
dostępnych autorowi nie obsługuje w pełni standardu opisanego w dokumencie
[14]. Wybrana do realizacji aplikacji CMS biblioteka Bouncy Castle pozwala na
generowanie
AC zawierających
jedynie
wybrane
typy atrybutów oraz
rozszerzeń, a obsługa OID ogranicza się tylko do notacji liczbowo-kropkowej.
Ze względu na brak centralnego repozytorium zawierającego numery OID oraz
niepowodzenia podczas próby rejestracji gałęzi na stronie http://www.oidinfo.com/ w systemie zastosowano gałąź 2.25 przeznaczoną dla uniwersalnych
unikatowych identyfikatorów (UUID - Universally Unique Identifiers). Brak
bibliotek moŜe wynikać z faktu stosunkowo niewielkiej popularności uŜycia
takiego typu certyfikatów. Według autora mogłaby ona ulec zmianie w
momencie dołączenia tego standardu do biblioteki OpenSSL.
W przypadku schematu Shamira zasób bibliotek był szerszy co pozwalało na
wygodną implementację. Problemem okazał się czas obliczeń fragmentów
klucza, który w najgorszym przypadku osiągnął wynik prawie 40 minut. Fakt ten
moŜe być spowodowany ograniczonym dostępem do pamięci i zasobów dla
procesów uruchamianych przez funkcję system() języka PHP, na serwerze, na
którym aplikacja była tworzona i testowana. Na szczęście taka procedura
wykonywana
jest
w
systemie
stosunkowo
rzadko,
co
pozwoliło
na
zaakceptowanie takiego wyniku.
Ze względu na swoją popularność i ilość dostępnych interfejsów implementacja
mechanizmów zarządzania certyfikatami PKC okazała się bardzo przyjemna i
wygodna. Wbudowana obsługa biblioteki OpenSSL dla języka PHP pozwoliła
uniknąć konieczności korzystania z zewnętrznych modułów.
str. 61
Bardzo wygodne okazało się wykorzystanie modułu ACL dla CakePHP
odpowiedzialnego za zarządzanie prawami dostępu grup do zasobów na
poziomie aplikacji.
W
stworzonym
systemie
zbudowano
jedynie
fragment
funkcjonalności
przedstawionej w załoŜeniach systemu - nie udało się zrealizować rozproszenia
repozytoriów
przechowujących
fragmenty
klucza,
ani
mechanizmów
komunikacji między nimi. Niemniej jednak w obecnej postaci system stanowi
integralną całość będącą podstawą do dalszego rozwoju aplikacji.
str. 62
Wykaz rysunków
Rysunek 1 Przykład hierarchii certyfikatów ........................................................ 9
Rysunek 2 Certyfikat klucza publicznego X.509 [10]........................................ 11
Rysunek 3 Schemat Shamira (2, n) [18] .......................................................... 45
Rysunek 4 Schemat Blakleya (2,n) [18] ........................................................... 45
Rysunek 5 Relacje między tabelami uŜywanymi przez komponent ACL w
CakePHP ......................................................................................................... 56
Rysunek 6 Relacje między tabelami systemu .................................................. 57
Bibliografia
[1] Wkrotce protesty i odwolania z e-podpisem. [Online]
http://www.podpis.infor.pl/inne-zastosowania/81408,Wkrotce-protesty-i-odwolania-z-epodpisem.html.
[2] Sinn, Richard. Understanding the Public Key Infrastructure. : Oblix Inc., 2001.
[3] Funkcja jednokierunkowa. [Online]
http://pl.wikipedia.org/wiki/Funkcja_jednokierunkowa.
[4] ElGamal, T. A public key cryptosystem and a signature scheme based on discrete
logarithms. IEEE Transactions on Information Theory, 1985.
5] Ford, W. Advances in Public-Key Certificate Standards. ACM SIGSAC Security
Audit & Control Review. 1995, Tom 13, 3.
[6] Diffie, W. Hellman, M. E. New directions in cryptography. IEEE Transactions on
Information Theory, 1976.
[7] Ford, W. and Baum, M. Secure Electronic Commerce: Building the Infrastructure
for Digital Signatures and Encryption. Prentice Hall : 1997.
[8] Howes T., Kille S., Yeong W., Robbins C. The String Representation of Standard
Attribute Syntaxes.: rfc-editor.org, 1995.
[9] Telecommunication Standarization Sector of ITU. ITU-T Recommendation
X.690. : Intenational Telecommunication Union.
str. 63
[10]
Public-key
certificates.
[Online]
www.x500standard.com/index.php?n=X509.X509PKC.
[11] Cooper D., Santesson S., Farrell S., Boeyen S., Housley R., Polk W. RFC5280
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List
(CRL) Profile. : rfc-editor.org, 2008.
[12] Housley R., Polk W., Ford W., Solo D. RFC 3280 Internet X.509 Public Key
Infrastructure Certificate. rfc-editor.org, 2002.
[13] R. Housley, W. Polk, W. Ford, D. Solo. RFC3280 Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List (CRL) Profile, 2002.
[14] Farrell S., Housley R. RFC3281 An Internet Attribute Certificate Profile for
Authorization. : RFC-editor.org, 2002.
[15]
Authorization
certificate.
[Online]
http://en.wikipedia.org/wiki/Authorization_certificate.
[16] Vinti Doshi, Amgad Fayad, Sushil Jajodia, Roswitha MacLean. Using Attribute
Certificates with Mobile Policies in Electronic Commerce Applications. McLean, Virginia
22102 : The MITRE Corporation.
[17] Ioannis, Mavridis, i inni. Access Control based on Attribute Certificates for
Medical
Intranet
Applications.
Thessaloniki,
Greece :
Informatics
Laboratory,
Computers Division, Faculty of Technology, Aristotle University of Thessaloniki, 2001.
[18]
Arendt
D.,
Krasiukianis
R.,
Lichy
R.
ARCHIWIZACJA
KLUCZY
SZYFRUJĄCYCH I ODMIANA METODY DZIELENIA SEKETU. XVI Konferencja „Sieci
i Systemy Informatyczne”. 2008.
[19] Shamir, A. How to share a sceret. 1979.
[20] Malkhi, Dahli. Secret Sharing. 2002.
[21] Benaloh, J.C. Secret Sharing homomorphism: Keeping shares of a secret secret.
1986.
[22] Blum M., Feldman P., Mical S. Proceedings of the Twentieth Annual ACM
Symposium on Theory of Computing. 1988.
[23] Nikova, V. Nikov S. On Proactive Secret Sharing Schemes.
str. 64
[24] Yung, A. Herzberg S.Jarecki H. Krawczyk M. Proactive Secret Sharing Or: How
to cope with perpetual leakage. IBM T.J. Watson Research Center, 1995.
[25] Blakley, G. R. Safeguarding cryptographic keys. 1979.
[26] J., Cohen. Improving Privacy in Cryptographic Elections. Technical Report. Yale
University Department of Computer Science, 1985. 372.
[27] Killian, K. Sako J. Receipt-free mix-type voting scheme: A practical solution to the
implementation of a voting booth. Advances in Cryptology -- EUROCRYPT '95. 1995.
[28] DuRette, Brandon William. Multiple Administrators for Electronic Voting.
Massachusetts Institute of Technology, 1999. .
[29] What is PHP? [Online] www.php.net.
[30]
What-is-MySQL.
http://dev.mysql.com/doc/refman/5.0/en/what-is-mysql.html.
[Online]
[31] About the OpenSSL Project. [Online] http://openssl.org/about/.
[32]
Java
SE
Technologies
at
a
Glance.
[Online]
http://java.sun.com/javase/technologies/.
[33] FAQ What is Eclipse. [Online] http://wiki.eclipse.org/FAQ_What_is_Eclipse%3F.
[34] Zend Studio. [Online] http://www.zend.com/en/products/studio/.
[35] The logi.crypto Java Package, version 1.1.2. [Online]
http://logi.org/logi.crypto/devel/.
[36] Bouncy Castle Homepage. [Online] http://www.bouncycastle.org/index.html.
[37] What is CakePHP? Why Use it. [Online] http://book.cakephp.org/view/8/What-isCakePHP-Why-Use-it.
[38] Access Control Lists. [Online] http://book.cakephp.org/view/171/Access-ControlLists.
[39] Francis C., Pinkas D. RFC4476 - Attribute Certificate (AC) Policies Extension.
2006.
str. 65

Rozproszony system dostępu do informacji wraŜliwych

Transkrypt

Podobne dokumenty

jak liczono dawniej? - Gimnazjum w Skórzewie

Hej! Kolęda! Kolęda!