Polityka kluczy i rotacji (PT/PS, CRL/ARL) — AJ
Power
Wersja: 1.0
Status: Referencyjna / Normatywna
Autorzy: Antzedek & Eliasz (AJ Power)
Powiązania: Spec. LSIG, Proc. 1–7 (Anchor, Ochrona, Rollback, LSIG Repair, Audyt, Safe Mode, Migracja)
Dokument definiuje zarządzanie kluczami PT (Twórca) i PS (System), zasady rotacji,
publikacji fingerprintów, unieważnień CRL oraz rejestru rewizji ARL (Anchor Record Log).
Używa słów MUSI/POWINNO/ZABRONIONE w sensie normatywnym.
1. Cele i zakres
Zapewnić ciągłość zaufania do Anchora (SR+LSIG) poprzez właściwe zarządzanie kluczami i
podpisami.
Zdefiniować cykl życia kluczy PT/PS, rotacje, unieważnienia i ceremonie.
Ustanowić transparentność (fingerprinty, raporty) bez ujawniania materiału prywatnego.
Zakres: wszystkie instancje AJ Power, które tworzą/weryfikują LSIG i/lub podpisują audyty/ARL.
2. Role i odpowiedzialności
Właściciel Klucza Twórcy (PT Owner): utrzymuje parę PT (HSM/air‑gap), autoryzuje aktywację
Anchora.
Custodian Systemowy (PS Custodian): utrzymuje parę PS w TEE/TPM, odpowiada za podpisy
systemowe.
Oficer Bezpieczeństwa (SecOps): nadzór nad CRL/ARL, audyt, incydenty.
Audytor (Internal/External): okresowe przeglądy polityk i logów.
3. Typy kluczy i zastosowania
PT (Twórca): Ed25519 (domyślnie) / Dilithium3 (PQ).
Zastosowania: dual‑sign dla LSIG, podpis raportów audytu i polityk, wpisy ARL (opcjonalnie
współpodpis).
Przechowywanie: HSM/air‑gap; ZABRONIONE na hostach produkcyjnych.
PS (System): Ed25519 (domyślnie) / Dilithium3 (PQ).
Zastosowania: podpis podstawowy dla LSIG, podpisy logów łańcuchowych, raportów.
Przechowywanie: TPM/TEE, klucz nieeksportowalny.
POWINNO: dla wysokiego profilu ryzyka używać hybrydowego podpisu (Ed25519 +
Dilithium3) oraz podwójnego podpisu PT+PS dla aktywacji Anchora.
•
•
•
•
•
•
•
•
•
•
•
•
•
1
4. Generowanie i przechowywanie
PT: generowany podczas Ceremonii Klucza w trybie offline (HSM). Backup fragmentowany
(M‑z‑N, np. 2/3) w sejfach.
PS: generowany wewnątrz TPM/TEE (nieeksportowalny). Uwierzytelnienie dostępu przez politykę
TEE (PCR, attestation, mTLS).
MUSI: 1. Rejestrować fingerprinty kluczy w /docs/keys/ (publicznie dostępne).
2. Prowadzić Key Inventory (wew., RO): ID, alg, data, status, właściciel, lokalizacja, polityka wygasania.
5. Publikacja fingerprintów i transparentność
Fingerprint = Base64URL(SHA3‑512(pub_key_bytes)) .
Publikować: PS_pub_fp , PT_pub_fp (opc.), algorytmy, daty ważności.
Raporty audytu i hash SR publikować w /docs/ wraz z podpisem PS i (opc.) PT.
ZABRONIONE: publikowanie materiału prywatnego, plików *_priv i danych HSM/TPM.
6. Rotacja kluczy (PT/PS)
6.1 Triggery rotacji
Czasowe: T_max (np. 24 miesiące dla PT, 12 miesięcy dla PS).
Zdarzeniowe: podejrzenie kompromitacji, zmiana algorytmu, migracja TEE/HSM, zmiana polityk.
Wolumenowe: liczba podpisów/logów powyżej progu.
6.2 Procedura rotacji — ogólny przebieg
Przygotuj nową parę kluczy (PT lub PS) w właściwym module (HSM/TPM).
Zarejestruj nowy fingerprint i zaktualizuj Key Inventory.
Zaktualizuj SIG.json.policy_ver oraz konfigurację weryfikatorów.
Odnowienie LSIG:
jeśli SR bez zmian → LSIG Repair (Proc. 4) nowymi kluczami; stary podpis w CRL/chain_prev.
jeśli SR się zmienia → Migracja Anchora (Proc. 7).
CRL: unieważnij stary klucz (stan = retired / revoked z przyczyną).
ARL: dodaj wpis łańcuchowy, jeśli rotacja powoduje nową rewizję podpisu/anchora.
Komunikat do interesariuszy (hashy, fingerprintów, dat).
MUSI: każda rotacja kończyć się testem weryfikacji (T0) i raportem audytu.
7. CRL — Key Revocation List (schemat)
CRL.json (min.):
{
"version": "1.0",
•
•
•
•
•
•
•
•
1.
2.
3.
4.
5.
6.
7.
8.
9.
2
"updated_at": "2025-09-08T12:00:00Z",
"revocations": [
{
"key_id": "PS-2024-11",
"fingerprint": "b64u...",
"alg": "ed25519",
"reason": "retired|compromise|policy-change",
"effective_at": "2025-09-08T12:00:00Z",
"replaced_by": "PS-2025-09"
}
],
"signature": {
"ps_sig_b64u": "...",
"pt_sig_b64u": "...optional..."
}
}
MUSI: publikować CRL w /docs/keys/CRL.json i podpisywać PS (opc. PT).
8. ARL — Anchor Record Log (schemat)
ARL.log (append‑only, łańcuch hashy):
# version: 1.0
# fields: ts | prev_hash | anchor_hash | action | meta_b64u | sig_ps |
sig_pt?
2025-06-01T00:00:00Z | 0000 | H_v1 | CREATE | eyJ2ZXIiOiIxLjAifQ | SIG... | -
2025-09-08T10:00:00Z | HASH1 | H_v2 | MIGRATE | eyJ2ZXIiOiIxLjEifQ | SIG... |
SIG...
MUSI: każdy wpis zawierać prev_hash dla łańcuchowej integralności; podpis PS (opc. PT).
POWINNO: udostępniać publiczny hash ARL (np. w /docs/keys/ARL.hash ).
9. Ceremonia Klucza (PT)
Miejsce/tryb: offline, sala kontrolowana, bez elektroniki zewnętrznej; uczestnicy: PT Owner,
SecOps, Audytor.
Kroki: generacja w HSM, wydruk i podpis protokołu, podział sekretu (M‑z‑N), depozyt sejfów, test
podpisu na wzorcowym SR.hash .
Artefakty: protokół PDF (podpis PS + opc. PT), hash protokołu opublikowany w /docs/keys/ .
10. Incydenty i tryb awaryjny
Podejrzenie kompromitacji: natychmiastowa rotacja i wpis w CRL, powiadomienie, weryfikacja
wszystkich ostatnich podpisów.
•
•
•
•
3
Awaria TEE/TPM: przejście do Safe Mode, wstrzymanie operacji wymagających podpisu PS,
odtworzenie w zapasowym TEE, atest.
Błąd weryfikatora: blokada aktywacji Anchora do czasu aktualizacji weryfikatora (alg/FP/CRL).
Desynchronizacja repo: użyj kopii RO (WORM), porównaj hash, odtwórz łańcuch ARL.
11. Polityka wygasania i M‑z‑N
Wygasanie: PT T_max 24–36 mies., PS 6–12 mies. (profil ryzyka).
M‑z‑N: dla PT zalecane 2/3 (lub 3/5) do odtworzenia klucza w HSM; ewidencja fragmentów i
depozytariuszy.
12. Zgodność post‑quantum (PQ)
Dla środowisk PQ POWINNO stosować się hybrydę podpisów (Ed25519 + Dilithium3).
Polityka algorytmów zapisana w policy_ver i publikowana w /docs/keys/
ALG_POLICY.json .
13. Telemetria i audyt
Zdarzenia: KEY_GEN , KEY_ROTATE , KEY_REVOKE , CRL_UPDATE , ARL_APPEND ,
ATTEST_OK/FAIL .
Raporty: miesięczne PDF/JSON podpisane PS (+opc. PT) z hashami, fingerprintami, zmianami.
14. Testy zgodności (Conformance)
CONF‑K1: fingerprinty publicznie dostępne i zgodne z kluczami.
CONF‑K2: CRL podpisany, aktualny i używany przez weryfikatory.
CONF‑K3: każda rotacja → LSIG Repair lub Migracja; log ARL_APPEND obecny.
CONF‑K4: klucze prywatne nie opuszczają HSM/TPM, egzekwowane politykami.
15. Przykładowe komendy (CLI)
# Generacja fingerprintu z klucza publicznego
cat PS.pub | openssl sha3-512 -binary | base64 | tr '+/' '-_' | tr -d '='
# Podpis CRL nowym PS
sign-json --key PS.priv --in CRL.json --out CRL.signed.json
# Aktualizacja weryfikatora po rotacji
verifier update --ps-pub PS2.pub --crl /docs/keys/CRL.json --policy
ALG_POLICY.json
•
•
•
•
•
•
•
•
•
•
•
•
•
4
16. Noty końcowe
Polityka kluczy jest żywym kontraktem zaufania. Bez niej Anchor traci wymiar techniczny i
duchowy (ładu).
Publikowana transparentność (fingerprinty, ARL, audyty) to „świadectwo” porządku —
sprawdzalne, nieopowiadane.