Funkcje

Ta strona zawiera informacje o funkcjach kryptograficznych Android Keystore, które są udostępniane przez implementację KeyMint (lub Keymaster).

Elementy kryptograficzne

Keystore udostępnia te kategorie operacji:

  • Tworzenie kluczy, w wyniku czego powstaje materiał klucza prywatnego lub tajnego, który jest dostępny tylko w bezpiecznym środowisku. Klucze można tworzyć na te sposoby:
    • Generowanie nowych kluczy
    • Importowanie niezaszyfrowanego materiału klucza
    • Importowanie zaszyfrowanego materiału klucza
  • Atest klucza: tworzenie klucza asymetrycznego generuje certyfikat zawierający część publiczną pary kluczy. Ten certyfikat może też zawierać informacje o metadanych klucza i stanie urządzenia, a wszystkie te informacje są podpisane kluczem powiązanym z zaufanym katalogiem głównym.
  • Operacje kryptograficzne:
    • szyfrowanie i odszyfrowywanie symetryczne (AES, 3DES);
    • Odszyfrowywanie asymetryczne (RSA)
    • Podpisywanie asymetryczne (ECDSA, RSA)
    • Podpisywanie i weryfikacja symetryczna (HMAC)
    • Uzgadnianie kluczy asymetrycznych (ECDH)

Pamiętaj, że Keystore i KeyMint nie obsługują operacji na kluczach publicznych w przypadku kluczy asymetrycznych.

Elementy protokołu, takie jak cel, tryb i wypełnienie, a także ograniczenia kontroli dostępu są określane podczas generowania lub importowania kluczy i są trwale powiązane z kluczem, co zapewnia, że nie można go używać w żaden inny sposób.

Oprócz usług wymienionych powyżej implementacje KeyMint (wcześniej Keymaster) udostępniają jeszcze jedną usługę, która nie jest jednak udostępniana jako interfejs API: generowanie liczb losowych. Jest on używany wewnętrznie do generowania kluczy, wektorów inicjujących, losowego dopełniania i innych elementów bezpiecznych protokołów, które wymagają losowości.

Niezbędne elementy podstawowe

Wszystkie implementacje KeyMint zapewniają:

  • RSA
    • Obsługa kluczy 2048, 3072 i 4096-bitowych
    • Obsługa wykładnika publicznego F4 (2^16+1)
    • Tryby dopełniania w przypadku podpisywania RSA:
      • RSASSA-PSS (PaddingMode::RSA_PSS)
      • RSASSA-PKCS1-v1_5 (PaddingMode::RSA_PKCS1_1_5_SIGN)
    • Tryby skrótu do podpisywania RSA:
      • SHA-256
    • Tryby dopełniania w przypadku szyfrowania i odszyfrowywania RSA:
      • Bez wyściółki
      • RSAES-OAEP (PaddingMode::RSA_OAEP)
      • RSAES-PKCS1-v1_5 (PaddingMode::RSA_PKCS1_1_5_ENCRYPT)
  • ECDSA
    • Obsługiwane są klucze 224-, 256-, 384- i 521-bitowe, które wykorzystują odpowiednio krzywe NIST P-224, P-256, P-384 i P-521.
    • Tryby podsumowania dla ECDSA:
      • Brak podsumowania (wycofane, w przyszłości zostanie usunięte)
      • SHA-256
  • AES
    • Obsługiwane są klucze 128- i 256-bitowe.
    • CBC, CTR, ECB i GCM. Implementacja GCM nie zezwala na używanie tagów krótszych niż 96 bitów ani długości nonce innych niż 96 bitów.
    • Tryby dopełniania PaddingMode::NONE i PaddingMode::PKCS7 są obsługiwane w przypadku trybów CBC i ECB. Bez dopełnienia szyfrowanie w trybie CBC lub ECB nie powiedzie się, jeśli dane wejściowe nie są wielokrotnością rozmiaru bloku.
  • HMAC SHA-256, z dowolnym rozmiarem klucza do co najmniej 32 bajtów.

W przypadku implementacji KeyMint zdecydowanie zalecamy używanie algorytmu SHA1 i innych algorytmów z rodziny SHA2 (SHA-224, SHA384 i SHA512). Keystore udostępnia je w oprogramowaniu, jeśli sprzętowa implementacja KeyMint ich nie udostępnia.

Niektóre typy proste są też zalecane ze względu na interoperacyjność z innymi systemami:

  • Mniejsze rozmiary kluczy RSA
  • Dowolne wykładniki publiczne w algorytmie RSA

Kontrola dostępu do klucza

Klucze sprzętowe, których nie można wyodrębnić z urządzenia, nie zapewniają zbyt dużego bezpieczeństwa, jeśli atakujący może ich dowolnie używać (chociaż są bezpieczniejsze niż klucze, które można wykradać). Dlatego kluczowe jest, aby Keystore wymuszał kontrolę dostępu.

Kontrola dostępu jest zdefiniowana jako „lista autoryzacji” par tag/wartość. Tagi autoryzacji to 32-bitowe liczby całkowite, a ich wartości są różnych typów. Niektóre tagi można powtarzać, aby określić wiele wartości. Informacje o tym, czy tag może być powtarzany, są podane w interfejsie HAL KeyMint. Gdy klucz jest tworzony, wywołujący określa listę autoryzacji. Implementacja KeyMint, która jest podstawą usługi Keystore, modyfikuje listę, aby podać dodatkowe informacje, np. czy klucz jest chroniony przed wycofaniem, i zwraca „ostateczną” listę autoryzacji zakodowaną w zwróconym obiekcie klucza. Każda próba użycia klucza do dowolnej operacji kryptograficznej zakończy się niepowodzeniem, jeśli ostateczna lista autoryzacji zostanie zmodyfikowana.

W przypadku Keymastera 2 i starszych wersji zestaw możliwych tagów jest zdefiniowany w wyliczeniu keymaster_authorization_tag_t i jest na stałe ustalony (chociaż można go rozszerzyć). Nazwy zostały poprzedzone prefiksem KM_TAG. Do określania typu służą 4 najwyższe bity identyfikatorów tagów.

Użytkownik Keymaster 3 zmienił prefiks KM_TAG na Tag::.

Możliwe typy:

ENUM: wartości wielu tagów są zdefiniowane w wyliczeniach. Na przykład możliwe wartości TAG::PURPOSE są zdefiniowane w wyliczeniu keymaster_purpose_t.

ENUM_REP: to samo co ENUM, z tym że tag może się powtarzać na liście autoryzacji. Powtórzenie oznacza wiele autoryzowanych wartości. Na przykład klucz szyfrowania prawdopodobnie ma wartości KeyPurpose::ENCRYPT i KeyPurpose::DECRYPT.

Gdy KeyMint tworzy klucz, wywołujący określa listę autoryzacji dla klucza. Ta lista jest modyfikowana przez Keystore i KeyMint w celu dodania dodatkowych ograniczeń, a podstawowa implementacja KeyMint koduje ostateczną listę autoryzacji w zwracanym pliku klucza. Zakodowana lista autoryzacji jest kryptograficznie powiązana z obiektem klucza, więc każda próba zmodyfikowania listy autoryzacji (w tym kolejności) powoduje, że obiekt klucza staje się nieprawidłowy i nie można go używać do operacji kryptograficznych.

Wymuszanie zasad na poziomie sprzętu i oprogramowania

Nie wszystkie implementacje bezpiecznego sprzętu zawierają te same funkcje. Aby obsługiwać różne podejścia, Keymaster rozróżnia egzekwowanie kontroli dostępu do bezpiecznego i niebezpiecznego środowiska (lub egzekwowanie sprzętowe i programowe).

Jest to udostępniane w interfejsie KeyMint API za pomocą pola securityLevel typu KeyCharacteristics. Bezpieczny sprzęt odpowiada za umieszczanie autoryzacji w KeyCharacteristics na odpowiednim poziomie bezpieczeństwa na podstawie tego, co może wymusić. Te informacje są też dostępne w rekordach atestu kluczy asymetrycznych: charakterystyka kluczy SecurityLevel::TRUSTED_ENVIRONMENT lub SecurityLevel::STRONGBOX pojawia się na liście hardwareEnforced, a charakterystyka kluczy SecurityLevel::SOFTWARE lub SecurityLevel::KEYSTORE – na liście softwareEnforced.

Na przykład ograniczenia dotyczące przedziału daty i godziny, w którym można używać klucza, nie są zwykle egzekwowane przez bezpieczne środowisko, ponieważ nie ma ono wiarygodnego dostępu do informacji o dacie i godzinie. W związku z tym autoryzacje takie jak Tag::ORIGINATION_EXPIRE_DATETIME są wymuszane przez magazyn kluczy w Androidzie i mają wartość SecurityLevel::KEYSTORE.

Więcej informacji o tym, jak sprawdzić, czy klucze i ich autoryzacje są obsługiwane przez sprzęt, znajdziesz w artykule Atestowanie kluczy.

Uprawnienia do tworzenia wiadomości kryptograficznych

Te tagi służą do określania charakterystyki kryptograficznej operacji wykonywanych przy użyciu powiązanego klucza:

  • Tag::ALGORITHM
  • Tag::KEY_SIZE
  • Tag::BLOCK_MODE
  • Tag::PADDING
  • Tag::CALLER_NONCE
  • Tag::DIGEST
  • Tag::MGF_DIGEST

Te tagi można powtarzać, co oznacza, że z jednym kluczem można powiązać wiele wartości:

  • Tag::BLOCK_MODE
  • Tag::PADDING
  • Tag::DIGEST
  • Tag::MGF_DIGEST

Wartość, która ma być użyta, jest określana w momencie wykonywania operacji.

Cel

Klucze mają powiązany zestaw celów, wyrażony jako co najmniej jeden wpis autoryzacji z tagiem Tag::PURPOSE, który określa, jak można ich używać. Cele są zdefiniowane w KeyPurpose.aidl.

Pamiętaj, że niektóre kombinacje wartości celu mogą powodować problemy z bezpieczeństwem. Na przykład klucz RSA, którego można używać zarówno do szyfrowania, jak i do podpisywania, umożliwia atakującemu, który może przekonać system do odszyfrowania dowolnych danych, generowanie podpisów.

Importowanie klucza

Keymaster obsługuje tylko eksportowanie kluczy publicznych w formacie X.509 i importowanie:

  • Pary kluczy asymetrycznych w formacie PKCS#8 z kodowaniem DER (bez szyfrowania opartego na haśle)
  • Klucze symetryczne jako nieprzetworzone bajty

Aby można było odróżnić zaimportowane klucze od bezpiecznie wygenerowanych kluczy, symbol Tag::ORIGIN jest uwzględniany na odpowiedniej liście autoryzacji kluczy. Jeśli na przykład klucz został wygenerowany w bezpiecznym sprzęcie, w hw_enforced – liście cech klucza – znajdziesz Tag::ORIGIN z wartością KeyOrigin::GENERATED, a klucz zaimportowany do bezpiecznego sprzętu ma wartość KeyOrigin::IMPORTED.

Uwierzytelnianie użytkowników

Bezpieczne implementacje KeyMint nie implementują uwierzytelniania użytkownika, ale zależą od innych zaufanych aplikacji, które to robią. Interfejs, który implementują te aplikacje, znajdziesz na stronie Gatekeeper.

Wymagania dotyczące uwierzytelniania użytkownika są określane za pomocą 2 zestawów tagów. Pierwszy zbiór wskazuje, które metody uwierzytelniania umożliwiają użycie klucza:

  • Tag::USER_SECURE_ID ma 64-bitową wartość liczbową określającą bezpieczny identyfikator użytkownika, który jest podawany w bezpiecznym tokenie uwierzytelniania, aby odblokować korzystanie z klucza. Jeśli klucz jest powtarzany, można go użyć, jeśli w tokenie bezpiecznego uwierzytelniania podano którąkolwiek z wartości.

Drugi zestaw wskazuje, czy i kiedy użytkownik musi zostać uwierzytelniony. Jeśli żadnego z tych tagów nie ma, ale jest tag Tag::USER_SECURE_ID, uwierzytelnianie jest wymagane przy każdym użyciu klucza.

  • Tag::NO_AUTHENTICATION_REQUIRED oznacza, że nie jest wymagane uwierzytelnianie użytkownika, chociaż dostęp do klucza jest nadal ograniczony do aplikacji będącej jego właścicielem (i wszystkich aplikacji, którym przyznaje ona dostęp).
  • Tag::AUTH_TIMEOUT to wartość liczbowa określająca w sekundach, jak świeże musi być uwierzytelnienie użytkownika, aby autoryzować użycie klucza. Limity czasu nie są resetowane po ponownym uruchomieniu. Po ponownym uruchomieniu wszystkie uwierzytelnienia są unieważniane. Limit czasu można ustawić na dużą wartość, aby wskazać, że uwierzytelnianie jest wymagane raz na uruchomienie (2^32 sekund to około 136 lat; urządzenia z Androidem są prawdopodobnie uruchamiane ponownie częściej).

Wymagaj odblokowanego urządzenia

Klucze oznaczone symbolem Tag::UNLOCKED_DEVICE_REQUIRED są dostępne tylko wtedy, gdy urządzenie jest odblokowane. Szczegółowe informacje znajdziesz w sekcji KeyProtection.Builder#setUnlockedDeviceRequired(boolean).

UNLOCKED_DEVICE_REQUIRED jest wymuszane przez Keystore, a nie przez KeyMint. Jednak w Androidzie 12 i nowszych wersjach Keystore kryptograficznie chroni klucze UNLOCKED_DEVICE_REQUIRED, gdy urządzenie jest zablokowane. Dzięki temu w większości przypadków nie można ich używać, nawet jeśli Keystore zostanie naruszony, gdy urządzenie jest zablokowane.

Aby to osiągnąć, Keystore „superszyfruje” wszystkie kluczeUNLOCKED_DEVICE_REQUIRED przed zapisaniem ich w swojej bazie danych. W miarę możliwości chroni też klucze superszyfrowania (superklucze), gdy urządzenie jest zablokowane, w taki sposób, że można je odzyskać tylko po pomyślnym odblokowaniu urządzenia. (Termin „superszyfrowanie” jest używany, ponieważ ta warstwa szyfrowania jest stosowana dodatkowo do warstwy szyfrowania, którą KeyMint stosuje już do wszystkich kluczy).

Każdy użytkownik (w tym profile) ma 2 klucze superużytkownika powiązane z UNLOCKED_DEVICE_REQUIRED:

  • Symetryczny klucz główny UnlockedDeviceRequired. Jest to klucz AES‑256‑GCM. Szyfruje klucze UNLOCKED_DEVICE_REQUIRED importowane lub generowaneUNLOCKED_DEVICE_REQUIRED, gdy urządzenie jest odblokowane dla użytkownika.
  • Klucz asymetryczny UnlockedDeviceRequired. Jest to para kluczy ECDH P-521. Szyfruje klucze UNLOCKED_DEVICE_REQUIRED importowane lub generowane, gdy urządzenie jest zablokowane dla użytkownika. Klucze zaszyfrowane tym kluczem asymetrycznym są ponownie szyfrowane kluczem symetrycznym przy pierwszym użyciu (co może nastąpić tylko wtedy, gdy urządzenie jest odblokowane).

Keystore generuje te superklucze podczas tworzenia użytkownika i przechowuje je w swojej bazie danych, zaszyfrowane syntetycznym hasłem użytkownika. Dzięki temu można je odzyskać za pomocą kodu PIN, wzoru lub hasła.

Keystore buforuje też te superklucze w pamięci, co umożliwia mu działanie na kluczach.UNLOCKED_DEVICE_REQUIRED Próbuje jednak buforować tajne części tych kluczy tylko wtedy, gdy urządzenie jest odblokowane dla użytkownika. Gdy urządzenie jest zablokowane dla użytkownika, Keystore zeruje swoją kopię w pamięci podręcznej tajnych części tych superkluczy, jeśli to możliwe. Gdy urządzenie jest zablokowane dla użytkownika, Keystore wybiera i stosuje jeden z 3 poziomów ochrony w przypadku superkluczy UnlockedDeviceRequired użytkownika:

  • Jeśli użytkownik ma włączony tylko kod PIN, wzór lub hasło, Keystore wymazuje tajne części buforowanych superkluczy. Dzięki temu klucze główne można odzyskać tylko za pomocą zaszyfrowanej kopii w bazie danych, którą można odszyfrować tylko za pomocą kodu PIN, wzoru lub równoważnego hasła.
  • Jeśli użytkownik ma włączone tylko dane biometryczne klasy 3 („silne”) oraz kod PIN, wzór lub hasło, usługa Keystore umożliwia odzyskanie kluczy nadrzędnych za pomocą dowolnych zarejestrowanych danych biometrycznych klasy 3 (zwykle odcisków palców) zamiast kodu PIN, wzoru lub hasła. W tym celu generuje nowy klucz AES-256-GCM, szyfruje nim tajne części superkluczy, importuje klucz AES-256-GCM do KeyMint jako klucz powiązany z danymi biometrycznymi, który wymaga uwierzytelnienia biometrycznego w ciągu ostatnich 15 sekund, i zeruje kopie wszystkich tych kluczy w postaci zwykłego tekstu.
  • Jeśli użytkownik ma włączoną biometrię klasy 1 („wygodną”), biometrię klasy 2 („słabą”) lub aktywnego agenta zaufania odblokowywania, Keystore przechowuje superklucze w pamięci podręcznej w postaci zwykłego tekstu. W takim przypadku nie jest zapewnione zabezpieczenie kryptograficzne kluczy UNLOCKED_DEVICE_REQUIRED. Użytkownicy mogą uniknąć tego mniej bezpiecznego rozwiązania, nie włączając tych metod odblokowywania. Najpopularniejsze metody odblokowywania, które należą do tych kategorii, to rozpoznawanie twarzy na wielu urządzeniach i odblokowywanie za pomocą sparowanego smartwatcha.

Gdy urządzenie zostanie odblokowane dla użytkownika, Keystore odzyska klucze główne UnlockedDeviceRequired użytkownika, jeśli to możliwe. W przypadku odblokowywania za pomocą kodu PIN, wzoru lub hasła odszyfrowuje kopię tych kluczy przechowywaną w bazie danych. W przeciwnym razie sprawdza, czy zapisała kopię tych kluczy zaszyfrowaną kluczem powiązanym z danymi biometrycznymi, a jeśli tak, próbuje ją odszyfrować. Ta operacja powiedzie się tylko wtedy, gdy użytkownik w ciągu ostatnich 15 sekund pomyślnie uwierzytelnił się za pomocą biometrii klasy 3, co jest wymuszane przez KeyMint (nie Keystore).

Powiązanie klienta

Powiązanie klienta, czyli powiązanie klucza z konkretną aplikacją klienta, odbywa się za pomocą opcjonalnego identyfikatora klienta i opcjonalnych danych klienta (Tag::APPLICATION_ID i Tag::APPLICATION_DATA). Keystore traktuje te wartości jako nieprzezroczyste obiekty blob, zapewniając jedynie, że te same obiekty blob przedstawione podczas generowania lub importowania klucza są przedstawiane przy każdym użyciu i są identyczne pod względem bajtowym. KeyMint nie zwraca danych powiązania klienta. Dzwoniący musi go znać, aby móc użyć klucza.

Ta funkcja nie jest udostępniana aplikacjom.

Wygaśnięcie

Keystore obsługuje ograniczanie użycia klucza według daty. Początek okresu ważności klucza i jego wygaśnięcie można powiązać z kluczem. Keymaster odmawia wykonania operacji na kluczu, jeśli bieżąca data lub godzina wykracza poza prawidłowy zakres. Zakres ważności klucza jest określony za pomocą tagów Tag::ACTIVE_DATETIME, Tag::ORIGINATION_EXPIRE_DATETIME i Tag::USAGE_EXPIRE_DATETIME. Rozróżnienie między „tworzeniem” a „używaniem” polega na tym, czy klucz jest używany do „tworzenia” nowego tekstu zaszyfrowanego lub podpisu itp., czy do „używania” istniejącego tekstu zaszyfrowanego lub podpisu itp. Pamiętaj, że to rozróżnienie nie jest widoczne dla aplikacji.

Tagi Tag::ACTIVE_DATETIME, Tag::ORIGINATION_EXPIRE_DATETIME i Tag::USAGE_EXPIRE_DATETIME są opcjonalne. Jeśli tagi są nieobecne, zakłada się, że dany klucz może być zawsze używany do odszyfrowywania lub weryfikowania wiadomości.

Ponieważ czas zegarowy jest dostarczany przez niezabezpieczony świat, tagi związane z wygasaniem znajdują się na liście wymuszanej przez oprogramowanie.

Powiązanie źródła zaufania

Keystore wymaga powiązania kluczy z głównym źródłem zaufania, czyli ciągiem bitów dostarczanym do bezpiecznego sprzętu KeyMint podczas uruchamiania, najlepiej przez program rozruchowy. Ten ciąg bitów jest kryptograficznie powiązany z każdym kluczem zarządzanym przez KeyMint.

Punkt zaufania obejmuje klucz publiczny używany do weryfikacji podpisu na obrazie rozruchowym i stan blokady urządzenia. Jeśli klucz publiczny zostanie zmieniony, aby umożliwić użycie innego obrazu systemu, lub jeśli zmieni się stan blokady, żadne klucze chronione przez KeyMint utworzone przez poprzedni system nie będą użyteczne, chyba że zostanie przywrócony poprzedni główny punkt zaufania i uruchomiony system podpisany tym kluczem. Celem jest zwiększenie wartości kontroli dostępu do kluczy wymuszanych przez oprogramowanie poprzez uniemożliwienie używania kluczy KeyMint przez system operacyjny zainstalowany przez atakującego.

Klucze samodzielne

Niektóre bezpieczne urządzenia KeyMint mogą przechowywać materiał klucza wewnętrznie i zwracać uchwyty zamiast zaszyfrowanego materiału klucza. Mogą też wystąpić inne przypadki, w których kluczy nie można używać, dopóki nie będzie dostępny inny składnik systemu niezabezpieczonego lub zabezpieczonego. Warstwa HAL KeyMint umożliwia wywołującemu zażądanie, aby klucz był „samodzielny” za pomocą tagu TAG::STANDALONE, co oznacza, że nie są wymagane żadne zasoby poza obiektem blob i działającym systemem KeyMint. Tagi powiązane z kluczem można sprawdzić, aby dowiedzieć się, czy klucz jest samodzielny. Obecnie zdefiniowane są tylko 2 wartości:

  • KeyBlobUsageRequirements::STANDALONE
  • KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

Ta funkcja nie jest udostępniana aplikacjom.

Velocity

Podczas tworzenia można określić maksymalną szybkość wykorzystania za pomocą parametru TAG::MIN_SECONDS_BETWEEN_OPS. Implementacje TrustZone odmawiają wykonywania operacji kryptograficznych za pomocą tego klucza, jeśli operacja została wykonana mniej niż TAG::MIN_SECONDS_BETWEEN_OPS sekund wcześniej.

Proste podejście do wdrażania limitów szybkości to tabela z identyfikatorami kluczy i sygnaturami czasowymi ostatniego użycia. Ta tabela ma ograniczony rozmiar, ale mieści co najmniej 16 pozycji. Jeśli tabela jest pełna i nie można zaktualizować ani odrzucić żadnych wpisów, bezpieczne implementacje sprzętowe „fail safe” (zawodzą w bezpieczny sposób), odmawiając wszystkich operacji na kluczach z ograniczeniem szybkości, dopóki nie wygaśnie jeden z wpisów. Wszystkie wpisy mogą wygasnąć po ponownym uruchomieniu.

Klucze można też ograniczyć do n użyć podczas uruchamiania z TAG::MAX_USES_PER_BOOT. Wymaga to również tabeli śledzenia, która mieści co najmniej 4 klucze i jest odporna na awarie. Pamiętaj, że aplikacje nie mogą tworzyć kluczy ograniczonych do jednego uruchomienia. Ta funkcja nie jest udostępniana przez Keystore i jest zarezerwowana na potrzeby operacji systemowych.

Ta funkcja nie jest udostępniana aplikacjom.

Ponowne inicjowanie generatora liczb losowych

Ponieważ bezpieczny sprzęt generuje liczby losowe na potrzeby materiału klucza i wektorów inicjujących (IV), a generatory liczb losowych w sprzęcie nie zawsze są w pełni wiarygodne, interfejs HAL KeyMint udostępnia interfejs, który umożliwia klientowi dostarczanie dodatkowej entropii mieszanej z generowanymi liczbami losowymi.

Używaj sprzętowego generatora liczb losowych jako głównego źródła wartości początkowej. Dane początkowe przekazywane przez zewnętrzny interfejs API nie mogą być jedynym źródłem losowości używanym do generowania liczb. Ponadto operacja mieszania musi zapewniać, że losowe dane wyjściowe są nieprzewidywalne, jeśli którekolwiek ze źródeł wartości początkowych jest nieprzewidywalne.