Informacje o podpisach XML

Adobe AIR 1.5 i starsze wersje

Podpis XML jest to podpis cyfrowy opisany składnią XML. Dane w podpisie XML mogą posłużyć do sprawdzenia, czy informacje nie zostały zmodyfikowane już po tym, jak zostały podpisane. Ponadto, jeśli certyfikat użyty do podpisywania został wydany przez zaufany ośrodek certyfikacji, tożsamość osoby podpisującej można zweryfikować za pomocą infrastruktury klucza publicznego.

Podpis XML można zastosować do dowolnego typu danych cyfrowych (w formacie binarnym lub XML). Podpisy XML są zazwyczaj używane do:

  • sprawdzania, czy zasoby zewnętrzne lub pobrane nie zostały zmodyfikowane;

  • sprawdzania, czy wiadomość nadeszła ze znanego źródła;

  • weryfikowania licencji programów lub uprawnień subskrypcyjnych.

Obsługiwana składnia podpisów XML

Poniżej wymieniono elementy zaleceń W3C dotyczących składni i przetwarzania podpisów XML obsługiwane przez środowisko AIR:

  • Wszystkie podstawowe elementy składni (rozdział 4 zaleceń W3C) — z tym że element KeyInfo nie jest w pełni obsługiwany.

  • Element KeyInfo musi zawierać wyłącznie element X509Data.

  • Element X509Data musi zawierać wyłącznie element X509Certificate.

  • Metoda generowania wyciągu SHA256.

  • Algorytm podpisywania RSA-SHA1 (PKCS1).

  • Metoda sprowadzania do postaci kanonicznej i transformacja „kanoniczny XML bez komentarzy”.

  • Transformacja podpisu w kopercie.

  • Znaczniki czasowe

Poniższy dokument ilustruje typowy podpis XML (większość danych kryptograficznych usunięto w celu uproszczenia przykładu):

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 
    <SignedInfo> 
        <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> 
        <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> 
        <Reference URI="URI_to_signed_data"> 
            <Transforms> 
                <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>            </Transforms> 
            <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> 
            <DigestValue>uoo...vY=</DigestValue> 
        </Reference> 
    </SignedInfo> 
    <SignatureValue>Ked...w==</SignatureValue> 
    <KeyInfo> 
        <X509Data> 
            <X509Certificate>i7d...w==</X509Certificate> 
        </X509Data> 
    </KeyInfo> 
</Signature>

Oto najważniejsze elementy podpisu:

  • SignedInfo — zawiera odwołania do podpisanych danych i wartości wyciągów obliczone w momencie podpisywania. Podpisane dane mogą być zawarte w tym samym dokumencie, co podpis XML, lub mogą być zewnętrzne w stosunku do niego.

  • SignatureValue — zawiera wyciąg elementu SignedInfo zaszyfrowany kluczem prywatnym osoby podpisującej.

  • KeyInfo — zawiera certyfikat użyty do podpisywania oraz ewentualne dodatkowe certyfikaty niezbędne do ustanowienia łańcucha zaufania. Należy zwrócić uwagę, że chociaż element KeyInfo jest pod względem technicznym opcjonalny, środowisko AIR nie jest w stanie zweryfikować podpisu w wypadku braku tego elementu.

Wyróżnia się trzy ogólne typy podpisów XML:

  • W kopercie — podpis jest wstawiony w dane XML, które podpisuje.

  • Koperta — podpisane dane XML są zawarte w elemencie Object wewnątrz elementu Signature.

  • Odłączony — podpisane dane są zewnętrzne względem podpisu XML. Podpisane dane mogą znajdować się w zewnętrznym pliku. Mogą jednak również znajdować się w tym samym dokumencie XML, co podpis, ale nie w elemencie nadrzędnym lub podrzędnym elementu Signature.

Podpisy XML odwołują się do podpisanych danych za pomocą identyfikatorów URI. Aplikacje podpisujące i weryfikujące muszą stosować te same konwencje do tłumaczenia identyfikatorów URI. W przypadku użycia klasy XMLSignatureValidator należy udostępnić implementację interfejsu IURIDereferencer. Ta implementacja odpowiada za tłumaczenie identyfikatorów URI i zwracanie podpisanych danych w postaci obiektu ByteArray. Zwrócony obiekt ByteArray jest przekształcany w wyciąg za pomocą tego samego algorytmu, którego użyto do wygenerowania wyciągu zawartego w podpisie.

Certyfikaty i zaufanie

Certyfikat składa się z klucza publicznego, informacji identyfikacyjnych i ewentualnie jednego lub wielu certyfikatów należących do ośrodka certyfikacji, który wydał dany certyfikat.

Istnieją dwie metody potwierdzenia zaufania do certyfikatu. Zaufanie można potwierdzić, uzyskując kopię certyfikatu wprost od osoby podpisującej, np. na nośniku fizycznym lub za pośrednictwem bezpiecznej transmisji cyfrowej, np. transakcji SSL. Zaufanie do certyfikatu można także oprzeć na zaufaniu do ośrodka certyfikacji.

Aby było to możliwe, certyfikat użyty do podpisywania musi być wydany przez ośrodek zaufany na komputerze, na którym podpis jest weryfikowany. Większość producentów systemów operacyjnych umieszcza w systemowym magazynie certyfikatów zaufanych certyfikaty główne kilku ośrodków certyfikacji. Użytkownicy mają ponadto możliwość dodawania i usuwania certyfikatów z magazynu.

Nawet jeśli certyfikat został wydany przez zaufany ośrodek certyfikacji, konieczne jest podjęcie decyzji co do tego, czy certyfikat należy do osoby zaufanej. W wielu praktycznych scenariuszach decyzję tę pozostawia się użytkownikowi końcowemu. Na przykład podczas instalacji aplikacji AIR instalator AIR wyświetla informacje identyfikacyjne pochodzące z certyfikatu wydawcy i jednocześnie pyta użytkownika o potwierdzenie decyzji o instalacji aplikacji. W innych przypadkach może wystąpić konieczność porównania klucza publicznego lub innych danych certyfikatu z listą dopuszczalnych kluczy. (Taka lista musi być zabezpieczona, np. jej własnym podpisem, lub zapisana w szyfrowanym magazynie lokalnym środowiska AIR, aby nie było możliwe nieuprawnione zmodyfikowanie listy).

Uwaga: Co prawda możliwe jest założenie, że certyfikat jest zaufany, bez niezależnej weryfikacji (np. w przypadku certyfikatów „samopodpisanych”), jednak założenie takie stawia pod znakiem zapytania sensowność weryfikacji podpisu. Jeśli nie wiemy, kto utworzył podpis, gwarancja, że podpis ten nie został zmodyfikowany, nie ma większej wartości. Prawidłowy podpis może być bowiem elementem fałszerstwa.

Termin ważności i unieważnienie certyfikatu

Wszystkie certyfikaty mają skończony okres ważności. Certyfikat może również zostać unieważniony przez ośrodek, który go wydał, np. jeśli dojdzie do ujawnienia lub kradzieży klucza prywatnego powiązanego z certyfikatem. Jeśli podpis jest podpisany certyfikatem, którego termin ważności upłynął, lub który został unieważniony, to będzie traktowany jako nieważny, chyba że częścią podpisu jest znacznik czasu. Jeśli obecny jest znacznik czasu, klasa XMLSignatureValidator zweryfikuje podpis jako ważny, o ile certyfikat był ważny w momencie podpisywania.

Znacznik czasu jest to podpisana wiadomość cyfrowa pochodząca z usługi generowania takich znaczników. Znacznik zaświadcza, że dane zostały podpisane o określonej godzinie w określonym dniu. Znaczniki czasu są wydawane przez odpowiednie ośrodki i podpisywane własnymi certyfikatami takich ośrodków. Aby znacznik czasu był uznawany za ważny, osadzony w tym znaczniku certyfikat ośrodka wydającego znacznik czasu musi być zaufany na danym komputerze. Klasa XMLSignatureValidator nie udostępnia interfejsu API umożliwiającego wskazanie innego certyfikatu jako właściwego do weryfikacji znacznika czasu.